After conducting over a hundred technical interviews for platform engineering and DevOps roles, I’ve started to see the same patterns repeat. The strongest candidates don’t demonstrate depth in every tool. They demonstrate how they think when they hit a boundary they haven’t crossed before.
That’s not the intuition most hiring processes are built around, and it costs teams.
What the job description measures and what the job requires
Most job descriptions for platform roles are a list: Kubernetes, Terraform, CI/CD, observability, one or two cloud providers, maybe a scripting language. Those are reasonable filters for minimum viable candidates. They don’t predict whether someone will be effective in production.
The work that matters on a platform — the outage diagnosis, the migration that’s two weeks from cutover and has a dependency no one documented, the security audit remediation that has to ship without disrupting the pipelines running on top of it — requires reasoning across layers. The Kubernetes layer has a symptom. The CNI has a different story. The storage class is silent but guilty. The person you need is the one who knows how to hold all of that at once and not anchor on the first plausible explanation.
That’s not something a list of tools tells you. It’s something you hear in an interview.
The three signals I listen for
How they decompose a problem they haven’t seen before. I’ll give a candidate a scenario: a pod can’t reach a service it reached yesterday, nothing changed, all the Kubernetes-layer checks look clean. Then I listen. The candidates worth hiring will start splitting it into smaller problems: is this one pod or any pod on that node? Is the node the issue or the path? They reach for tools they’d actually run — not in the right order necessarily, but with a logic. By the end of the conversation, they’ve narrowed the problem, not just described it.
The candidates who don’t make it will list things they’d check without decomposing. They’ll name five correct tools. They won’t say what a clean result on any of them would rule out. The difference isn’t knowledge — both candidates might have the same certifications. It’s thinking style.
Whether they say “I don’t know that layer” while still reasoning forward. This is a strong positive signal and I look for it actively. A candidate who hits the edge of their knowledge and says “I’ve never gone deep on the CNI side, but if I were following the packet path I’d start by checking…” is showing you something important. They know where their knowledge ends. They have a method that works past it.
Candidates who don’t make this turn tend to either bluff — narrating a general investigation without the specifics — or stall. Both are worse than the honest acknowledgement.
How they describe a failure they caused. I ask for a specific story: something went wrong, they owned the system, what happened. I’m not looking for a drama. I’m looking for the quality of the retrospective.
The best answers name a specific failure mode, attribute it honestly, and explain what the system would need to look like to catch it earlier. The answer shows a person who has metabolised the failure and thought about the class of problem, not just the incident.
The red flags are subtler: “we” without personal accountability, a narrative that ends at the fix without the learning, or — the most telling — a story where nothing went wrong on their programs. A decade in infrastructure with no production incidents is not a track record. It’s a sign someone wasn’t close enough to production to own the failures.
What I’ve stopped looking for in the CV
Certifications are a coarser signal than most hiring managers think. They confirm exposure and a baseline of vocabulary. They don’t confirm that someone has worked through a hard production failure or understood a platform deeply enough to own its failure modes.
“Designed and implemented X at Y” is useful only when the interview can verify it. I’ve had plenty of candidates who listed full platform builds and, in the conversation, couldn’t describe why they made one architectural choice over another. The job description line was accurate — they were part of the project. But they weren’t the person who held the design.
What I look for instead: specificity. Candidates who say “I built the base image pipeline using Kaniko because we had a rootless cluster and Docker-in-Docker wouldn’t work without privilege escalation, and here’s what broke on the first try” are showing me something real. The detail and the friction are both evidence.
On team composition
Something I’ve thought about more since moving into a leadership role: depth and breadth distribute across a team, and a team needs both. Not every engineer needs to be able to cross every layer. Some of the strongest platform work I’ve seen comes from someone who goes very deep on one thing — networking, storage, security hardening — and a team that’s built around using that depth well.
The hiring problem isn’t finding unicorns who know everything. It’s building a team where the people who go deep on their layer have the vocabulary to hand a problem to the next layer, and receive one back. That’s the skill worth hiring for at any level: the ability to hold a problem at the boundary and not lose it there.
If you’re hiring for that, the interview that surfaces it is a problem that requires crossing a boundary. Listen for the decomposition. Listen for the honest gap. Listen for the failure story with the retrospective. The right answer to a problem they haven’t seen before tells you more than the right answer to every tool on the list.