How to spot depth in an answer you cannot verify

A candidate is describing how they moved a payments service onto Kubernetes. They are fluent, organised, and they use the right words in the right order. You are the recruiter on the call and you are not a platform engineer. You genuinely cannot tell whether this person led that migration, sat next to it, or read a good writeup of one.

The usual advice is to go and learn the technology. That advice puts a decade of study between you and this afternoon's screening call, so it is not really advice.

There is a better move, and it is to stop trying to evaluate the technical content at all. You are not the judge of whether the architecture was correct. An engineer will do that later. Your job on a screening call is narrower and more useful: work out whether this person is remembering something or reconstructing it.

Those two things sound different. Hearing the difference does not require knowing Kubernetes.

Five signals that a memory is first hand

1. Detail that costs nothing to be true

Real memories arrive with incidental furniture. It was a Friday. The alert fired at two in the morning. The dashboard had been showing stale data the whole time. Two people were on leave that week.

None of those facts make the candidate look good, and none of them are load bearing for the story. That is exactly why they are there. Nobody rehearses the irrelevant parts.

A reconstructed answer contains only the parts that matter. It is efficient, and the efficiency is the tell.

2. They remember the boring parts

Anyone can describe the interesting decision. Only someone who was actually there remembers the administration around it: who had to sign off, which team pushed back and why, how long the change window was, what the rollback plan looked like, how many attempts it took before one held.

Ask about the process rather than the technology. You can evaluate a process answer with no domain knowledge whatsoever, and it is the part almost nobody thinks to prepare.

3. Numbers with a shape

“We reduced latency by forty percent” is a claim. “The ninety ninth percentile sat around eight hundred milliseconds and we got it to roughly three hundred, but the median barely moved” has a shape.

The most useful question here is the inverted one. Ask what did not improve. People who ran the project know exactly which metric stayed stubborn, because it irritated them for weeks. People who did not will hand you another success.

4. Trade offs they resent

Anyone who has operated a system has grievances about it. Ask what they would build differently and listen to the temperature of the answer, not its content.

A reconstructed answer offers something balanced and diplomatic. A first hand answer usually has an edge on it, because the person is remembering an argument they lost or a constraint they had to live inside for a year.

Specific irritation is very hard to fake and very easy to hear.

5. Fluency that drops as depth increases

This is the counterintuitive one, and it is the most reliable.

Genuine recall is effortful. As a person goes deeper into a real memory they slow down, qualify things, correct themselves, and tell you they would have to check. That is what accurate memory sounds like under load.

An answer that stays perfectly smooth at every level of depth, where the fifth answer is as polished as the first, is being produced rather than retrieved. Watch the shape of the fluency across the whole conversation, not the quality of any single answer.

The one technique worth practising

You do not need a question list. You need one move, repeated.

Take the last specific thing the candidate said, a named tool, a number, a decision, a person, and ask about that. Then do it again with whatever specific thing turns up in their next answer. Then once more.

• “You said the cache fleet failed first. How did you find that out?”
• “You said the dashboard was stale. What were you looking at instead?”
• “You said you failed reads over before writes. Who made that call?”

Three descents is usually enough.

Notice that you did not need to know anything about caching to ask any of those. You only needed to listen and reuse their own words. That is the whole skill, and it is the one thing a fixed question list can never do, because those questions did not exist until the candidate spoke.

What is not a signal

This technique fails badly if you read the wrong things as shallowness, so be strict about the exclusions.

• Nervousness is not shallowness. A stressed candidate sounds vague for reasons that have nothing to do with competence.
• Non native fluency is not shallowness. Someone working in their second or third language will sound less polished while describing something they built entirely themselves.
• Forgetting a number from two years ago is not shallowness. It is normal. Certainty about every figure is more suspicious than uncertainty about one.
• Saying “we” instead of “I” is not shallowness. Serious infrastructure is built by teams, and the people who claim sole credit are frequently the ones who contributed least.

Penalise those four and you are no longer filtering for ability. You are filtering for confident, native speaking, self promoting candidates, and you will lose good engineers to every one of them.

What to hand over

You are not deciding whether the candidate can do the job. You are deciding whether the claim on the résumé is first hand, and whether an engineer's next hour is well spent.

So write down the line that convinced you, word for word, and pass it to the hiring manager alongside your recommendation.

“Strong on incident response” is an opinion. “Said the regional cache fleet failed first, and that they failed reads over before writes, then explained why that order mattered” is evidence.

Evidence lets the engineer pick up exactly where you left off. That habit, quoting the specific line instead of summarising your impression, is the highest leverage change most screening processes could make this quarter.

None of this needs software

It is a listening discipline. A good screener can run it on a phone call with a notepad, and the best ones already do.

It is also, more or less, what we automated. Rio generates each follow up from the candidate's previous answer, keeps descending until the specifics run out, and links every score back to the transcript line that earned it. You can read how that works on the interview engine page.

The technique came first, though. If you take one thing from this, take the descent. Follow their words, three times, and see whether it holds.