The résumé probe table: one layer deeper than they prepared for

A candidate writes “Ran Kubernetes in production” on a résumé. That sentence might describe someone who took a fifteen-node cluster through three version upgrades and a live incident at two in the morning. It might describe someone who watched a teammate do it once and wrote down what they saw. The sentence itself carries no information about which.

Most screeners resolve that ambiguity one of two ways. They take the line at face value, because challenging a résumé this early feels adversarial. Or they reject on a hunch, because something about the phrasing felt thin. Neither is a test. A test has a method, and the method here is not complicated: pick the claim, go one layer deeper than the candidate prepared for, and listen to what comes back.

One layer deeper, not domain mastery

Candidates over-prepare the headline and under-prepare everything beneath it. The résumé line gets rehearsed, tightened, run past a friend. The layer underneath it, the node count, who signed off, what broke at two in the morning, almost never does, because it doesn't fit on a résumé and was never the story anyone told them to have ready.

You are not judging whether their architecture was correct. You are listening for whether the second-order detail exists at all, and whether it arrives the way lived experience arrives: specific, sometimes hesitant, occasionally an admission that they'd have to check. How to spot depth in an answer you cannot verify goes deeper into why that hesitation is a good sign rather than a bad one. Here, the job is narrower: the actual questions, organized by claim.

Six claims, six probe chains

Six of the claims that show up on almost every DevOps résumé, and the chain that tests each one.

“Ran Kubernetes in prod”

• Managed or self-managed?
• Which service or distro?
• Node count?
• CNI plugin?
• Ingress controller?
• Upgrade strategy?
• A real incident they debugged?

Someone who actually ran this names the CNI plugin without reaching for it, and the incident story has weather in it: what the alert said, what they tried first, what didn't work before something did.

“Built CI/CD pipelines”

• Which tool?
• What are the pipeline stages?
• How are secrets handled?
• What's the deployment strategy?
• What's the rollback mechanism?
• How did they speed up a slow pipeline?

The rollback question is the sharpest one here. Everyone can describe deploying. Far fewer have actually had to reverse one under pressure, and it shows.

“Managed infrastructure as code”

• Module structure?
• Remote state backend?
• How do they handle drift?
• Plan and apply discipline?
• A time state got locked or corrupted?

State corruption is the kind of detail nobody invents. Someone who's hit it remembers exactly what they did next.

“Containerized apps”

• Multi-stage builds?
• How do they keep images small?
• Base-image choices?
• A security concern they handled?

“Worked on AWS, GCP, or Azure”

• Which services, specifically?
• IAM model?
• Networking: VPC, subnets, routing?
• A cost issue they investigated?

“Set up monitoring”

• Which stack?
• What metrics or SLIs?
• How did they design alerts to avoid noise?
• An alert that caught something real?

The pattern repeats across all six. The first two or three questions confirm they know the terrain. The last one or two ask for a specific memory, and that's the one a shallow answer can't produce on demand.

Reading the answer, not just the words

Three reads, and they take attention more than domain expertise. Genuine sounds specific and occasionally uncertain; admitting a number they'd have to check is a stronger signal than confidence about all of them. Shallow sounds accurate but generic, true of any cluster and attached to none in particular. Fabricated contradicts itself, or gets a term wrong in a way nobody who'd actually configured it would.

The gate, not the verdict

What the read produces changes the outcome, but it never decides it alone. A genuine answer earns full marks on that claim, no flag. A shallow answer earns partial marks and gets flagged as a risk for whoever reads the report next. A fabricated answer trips the authenticity gate: the overall recommendation caps at Borderline regardless of how strong the rest of the interview was, and the case gets flagged for a person to look at directly. Severe or repeated fabrication caps it lower, at No Hire.

The gate caps a score. It does not reject a candidate. Every fabrication flag is a case for a person to review, not a decision made on their behalf, and that's the difference between running a gate and running a filter.

Where this sits in the total score shifts with seniority. Verification carries 10% of the score at 0–2 years, down to 5% at 8–12. That's not because a fabrication matters less at senior level; if anything it's a worse sign. It's because everything else, architecture thinking, scenario judgment, has more room to carry the weight as the role does.

This is Resume Verification, step four of Recio's interview flow, scored on its own dimension before the technical assessment even starts. The chains above are the same ones the engine runs, adapted here for a screening call you're running yourself. More on how the full flow fits together is on the interview engine page.

The résumé line was never the test. What's underneath it always was.