Kubernetes on a CV vs. Kubernetes in production

Almost every DevOps CV I see today has the same line: Kubernetes. Sometimes with five stars next to it. Sometimes with three certifications.

And that’s fine. But after years of running platforms inside a bank, I know that “I’ve used Kubernetes” can mean anything from “I deployed a Helm chart in a tutorial” to “I kept a payments cluster alive through a botched upgrade on a Friday night”.

Those are very different people. A keyword search can’t tell them apart. A good conversation can.

Why keyword matching fails

Traditional screening asks “Do you have Kubernetes?” and ticks a box. The problem is that tools are the easy part. What a bank really pays for is judgement: knowing what breaks, why it breaks, and what to do when it does, while an auditor, a release manager and a nervous product owner are all watching.

You don’t find judgement in a skills list. You find it in stories.

The questions I actually ask

I don’t run quizzes, and I won’t ask anyone to recite the difference between a Deployment and a StatefulSet. Instead I ask questions like these:

• “Tell me about the last incident you were part of.” What happened, what did you do, and what changed afterwards?
• “Walk me through your last cluster upgrade.” What did you check first? What went wrong? How did you roll back, or why didn’t you have to?
• “Where did your secrets live, and who could read them?” In a regulated environment this one says a lot.
• “What would you build differently if you started that platform again?”
• “How did a change get from a developer’s laptop to production?” Every step, including the approvals.

What I listen for

The technical detail matters, but so do the signals around it:

• Specifics. Real experience comes with numbers, names of components, error messages and timelines. “It was slow” is a red flag. “p99 latency jumped from 80 to 900 ms after the ingress controller restarted” is not.
• Trade-offs. People who have run systems in production talk about why they chose something and what it cost them.
• “I” vs. “we”. Teamwork is great, but I want to know which part was yours.
• Honest mistakes. The strongest engineers I know can tell me exactly what they broke and what they learned. Nobody with real production experience has a spotless record.

What this means if you’re a candidate

You don’t need to know everything. You need to be able to explain what you’ve done, clearly and honestly. Before an interview, pick two or three real situations (an incident, a migration, a hard design decision) and practise telling them from start to finish.

That will do more for you than another badge on your LinkedIn.

What this means if you’re hiring

When I send you a shortlist, every person on it has already had this conversation with me. You get my notes on what they’ve really done, where they’re strong, and where they’d need support. That way your engineers spend their interview time going deeper, not finding out that “Kubernetes” meant one weekend tutorial.

If that sounds like the kind of screening you’d like for your next hire, let’s talk.