The interviewer’s probe sheet
The claim you cannot verify
A four-layer method for the interviewer
Every technical résumé contains at least one claim that decides the hire and cannot be checked. “Led the Kubernetes migration.” “Owned the CI/CD platform.” “Built the RAG pipeline.” A background check will confirm the person worked there. It will not tell you whether they did the thing.
This is the method for finding out in about six minutes. It works on any claim, on any résumé, in any stack, and it needs no tooling. Take it into your next first round.
Pick the claim that carries the role
Not the longest bullet, and not the most impressive one. The claim the job depends on.
If you are hiring someone to own a delivery pipeline, the line about the pipeline is the claim. The Kafka bullet is interesting and is not the claim. Choosing wrong is the most common way this method fails, and it fails silently — you get a beautifully detailed answer about something that does not matter.
Pick one. Two at most. The depth is the point; coverage is not.
The four layers
You descend one layer at a time and you stop at the first layer that comes back thin. That stopping point is the finding. Most interviewers ask a layer-1 question, get a competent answer, and move on to a different topic — which is why so many first rounds return “seemed strong” and nothing else.
Layer 1 — Scope.Establish the shape of the thing.
How many clusters, how many services, what size team, managed or self-hosted, who else was on the rota, over what period.
Everyone clears this layer, including people who were adjacent to the work rather than inside it. Its job is not to discriminate. Its job is to fix the boundaries of the claim so that layers 2 to 4 have something specific to attach to, and so that a later vague answer cannot retreat into a different scope.
Listen for: a scope that grows as the conversation gets harder. That is a tell.
Layer 2 — Mechanism.Which one, and why that one.
Which CNI, and what made that the choice. How ingress was terminated. How a secret reached a pod. Where state lived and who could write to it.
People who operated a system answer in the specific and volunteer the constraint that drove the decision. People who read about one answer in the general, correctly, and in the vocabulary of documentation.
This is where a model in a second tab stops helping much, because the useful part of the answer is not the fact — it is the reason your organisation picked that fact over the alternative, which is not in the documentation.
Listen for: the named alternative they rejected. Its presence is the strongest single positive signal at this layer.
Layer 3 — Decision.What did it cost, and who paid.
Walk me through an upgrade you planned. What was the rollback. What did you decide not to do. What surprised you. Who had to agree.
A decision has a cost attached, and the cost is the part nobody can invent convincingly. A candidate who was in the room remembers who objected. A candidate who was not remembers the best-practice answer.
Listen for: trade-offs described from both sides. Someone who only tells you why the decision was right is describing a decision they read about.
Layer 4 — Failure.The 2am version.
The worst thing that system did to you. What the symptom looked like before anyone knew what it was. What you tried first that was wrong.
Ask for the first wrong hypothesis specifically. Rehearsed incident stories are told from the resolution backwards and arrive tidy. Real ones start in the wrong place, and the person telling you remembers the wrong place vividly because it cost them ninety minutes.
Listen for: the timeline. Genuine incidents have a texture of confusion in the middle.
How to read the descent
The finding is not any single answer. It is the layer where the language changes.
Depth ends where the specifics stop. A candidate who is precise at layers 1 and 2 and general at layer 3 has operated the system without owning decisions about it — which is a completely legitimate profile, and exactly the right hire for some roles and the wrong one for others. That is the judgment the sheet is for. It does not produce a pass or a fail. It produces a defensible statement about where this person’s experience actually ends.
Write it down in that form. “Precise through mechanism, general on trade-offs, no first-hand incident” is a note a hiring manager can act on. “Seemed strong” is not.
Two traps
Do not reward vocabulary.
Fluent use of the right nouns is now free and tells you nothing. The signal is the reason behind the choice, not the name of the thing chosen.
Do not punish a different stack.
A candidate who ran the equivalent system on a different cloud, or on hardware, is not weaker — they are differently indexed. Ask them to map it: “what is the equivalent of that in what you used, and where does the analogy break?” The mapping answer is usually more informative than the original question would have been, and it is the single best question in this sheet for an interviewer who is more senior in the stack than the candidate.
Two worked descents
Neither is a script. Both show the shape.
“Led the migration from EC2 to EKS.”
- L1How many services moved, over how long, and who else was on it?
- L2What did you use for ingress, and what did you rule out?
- L3What moved last, and why did that one go last?
- L4What broke in the first month that you did not predict?
The layer that usually decides it is L3. “What went last” is a question about organisational reality — the service nobody wanted to touch, the team that would not give up their load balancer — and someone who ran the migration has an opinion about it immediately.
“Built and shipped a RAG pipeline in production.”
- L1What was it answering, for whom, at what volume?
- L2How did you chunk, and what did you try before that?
- L3How did you know retrieval had got worse?
- L4What was the first thing users complained about?
L3 is the discriminator in this family. A candidate who built the tutorial version evaluates by reading a few answers and forming an impression. A candidate who shipped it has an eval set, or a painful story about not having one.
What this sheet deliberately does not contain
No lab briefs. No scenario prompts. No question bank, and no model answers.
Those things exist on our side and stay there, for a reason that is easy to state: a screening task published as preparation material stops being a screening task. Anything we put in front of candidates has to remain something you cannot study for, or it is worth nothing to the people paying for it.
What is publishable is the method, because the method is not the advantage. Reading the descent well is a skill, and a candidate cannot acquire the interviewer’s half of it by reading the sheet.
Six minutes, in practice
Pick the claim. Say which one you are going to dig into, so it does not feel like an ambush.
Layer 1. Fix the scope. Do not evaluate anything yet.
Layer 2. Ask “which one, and why that one” twice.
Layer 3. One decision, and its cost.
Layer 4. One failure, and the first wrong hypothesis.
Write the descent line before you move on. Not later. Later is never.
This sheet is the manual version of something we automate.
Recio is an AI first-round technical interviewer. It generates the descent from the candidate’s own résumé and their own answers, runs it against a fixed rubric for their experience band, and returns a report with the evidence attached to each score — the transcript excerpt next to the lab trace, and the divergence between what was said and what was done. Your team reads it and your team decides.
We are pre-launch. Cloud and DevOps role families are built; AI families are in draft. We are taking a small number of design partners: teams hiring technical roles at volume who will run this next to their existing process and tell us where it is wrong.