How to interview a DevOps engineer

A DevOps résumé is the least reliable document in cloud hiring, and not because the people writing them are dishonest.

The job is defined by a toolchain, and a toolchain is a list. Terraform, Kubernetes, Jenkins or GitHub Actions, Docker, Prometheus, one of the three big clouds. Anyone who has been near a delivery pipeline can name all of it correctly, in the right order, with the right relationships between the parts. None of that separates the engineer who has upgraded a production cluster from the one who has watched a course about upgrading a production cluster. The vocabulary is identical. Only the scar tissue differs.

So the interview has one job: get underneath the list. What follows is a first-round structure for doing that, built on the general argument for what AI technical screening has to measure now.

Pin the cloud before you ask anything

The first decision is not a question, it is a scope choice, and getting it wrong invalidates a third of the interview.

DevOps is cloud-agnostic in principle and never in practice. A candidate has spent their career inside one provider's identity model, one provider's networking, one provider's managed Kubernetes. Establish which one before you ask anything cloud-specific, then hold two rules.

• Only cloud-specific content specialises: managed services, the IAM model, cloud networking, cloud architecture and security. Everything cloud-agnostic stays identical for every candidate. Linux, Git, containers, CI/CD concepts and IaC discipline do not move.
• The weighting never changes with the cloud. Only which questions appear.

The case that trips people up is a mismatch. The candidate knows Azure and the role requires AWS. The instinct is either to fail them on the spot or to quietly excuse the gap, and both are wrong. Do not specialise the interview to Azure, because that measures something you are not hiring for. Probe instead whether the underlying reasoning transfers: how they think about identity boundaries, network segmentation, the managed versus self-managed trade-off. Then flag the gap explicitly as a fit risk with a ramp cost attached and let the hiring manager price it. That is a different output from a fail, and it is usually the more accurate one.

Where a candidate has no real cloud depth in any provider, cap the cloud portion of the score rather than scoring it zero, and say so in the writeup. A capped sub-score is information. A zero is a guess.

Probe the claims before you test the knowledge

Résumé verification comes before the technical assessment, not after it, because what you find changes what is worth asking. A claim that survives probing does not need re-testing. A claim that collapses tells you where to spend the rest of the hour.

The method is one layer deeper than the candidate prepared for. Not harder questions, more specific ones, each taking a noun from the previous answer and asking what it cost. Three outcomes: specific and lived-in means genuine, textbook but vague means shallow, wrong or self-contradictory means fabricated. The probe table method generalises this to any role. Below is the DevOps set.

“Ran Kubernetes in production”

• Managed or self-managed?
• Which service or distribution?
• How many nodes?
• Which CNI plugin?
• Which ingress controller?
• What was the upgrade strategy?
• Talk me through a real incident you debugged.

“Built CI/CD pipelines”

• Which tool?
• What were the stages?
• How were secrets handled?
• Which deployment strategy?
• What was the rollback mechanism?
• Tell me about a slow pipeline you sped up.

“Managed infrastructure as code”

• How were the modules structured?
• Which remote state backend?
• How do you handle drift?
• What is your plan and apply discipline?
• Has state ever been locked or corrupted? What happened?

“Containerised applications”

• Multi-stage builds?
• How do you keep images small?
• How do you choose a base image?
• What security concern have you had to handle?

“Worked on AWS, GCP or Azure”

• Which services specifically?
• How does that provider's IAM model work?
• How was the networking laid out: VPCs, subnets, routing?
• Tell me about a cost issue you investigated.

“Set up monitoring”

• Which stack?
• What metrics or SLIs?
• How did you design the alerts to avoid noise?
• Tell me about an alert that caught something real.

The last item in each chain is the one that matters most. A real incident you debugged, an alert that caught something real, a cost issue you investigated: none of these can be answered from documentation, because documentation does not contain anyone's Tuesday.

What a weak candidate says that sounds strong

Three answers, in ascending order of how convincing they sound and descending order of what they are worth.

The genuine answer is cluttered. It contains a version number that turns out to matter, a decision that was made badly and then fixed, a constraint that came from somewhere unreasonable like procurement. It often opens with it depends and then actually says what it depends on. It is frequently the least articulate of the three.

The shallow answer is clean. Textbook-correct, well organised, describing the general case rather than any particular case. Ask how they did it and you are told how it is done. This is the answer that passes conversation-only screens, and it is the reason to compare what someone says against what they do: it is indistinguishable from expertise right up until you hand the person the task.

The fabricated answer contradicts itself, usually two or three questions in, and usually on scale or timeline. The node count does not fit the team size. The upgrade cadence does not fit the cluster version they named. A migration ran across a period that overlaps a job they held somewhere else. You do not catch this by challenging the claim. You catch it by continuing to descend politely while the details fail to line up.

The version specific to this role, and the highest-frequency false positive in DevOps hiring: fluent Kubernetes vocabulary attached to no operational memory. The candidate explains control-plane components accurately and cannot tell you what happens on the night one of them stops responding.

Four bands, four different interviews

Scenarios do the work probes cannot. Probes test what someone did; scenarios test what they would do. One per band, with what you are listening for. Why four bands are four different interviews covers the general principle.

0–2 years, a single fault, guided. A pod is stuck in CrashLoopBackOff; walk me through finding out why. You are not grading the answer, you are grading the order of operations. Do they reach for logs and events before they start theorising about resource limits? A junior who says they would check the events first has done this. One who opens with a confident diagnosis has read about it.

2–5 years, multi-step and production-flavoured. A rolling deploy has left roughly 20 per cent of requests returning 502s; how do you respond, and how do you decide whether to roll back? The second clause is the whole question. Anyone can say roll back. What you want is the decision rule: what would make them hold and diagnose instead, what they need to know in the first two minutes, and whether they notice that 20 per cent maps suspiciously well onto the proportion of pods already updated.

5–8 years, ambiguous and trade-off heavy. The cloud bill has doubled month over month with nothing obvious launched; how do you investigate? There is no correct answer, only a correct approach, which is to partition before theorising. Strong candidates go to cost allocation by service and by tag before naming a suspect. Weak ones pick a cause and start defending it. Listen for whether they ask about tagging discipline, because anyone who has actually done this knows the investigation usually fails there first.

8–12 years, design and strategy. A Sev1 took six hours to resolve; design the process and tooling changes that make the next one thirty minutes. This is not a technical question. It is a question about where the six hours went, and the strong answer begins by asking. Detection, escalation, diagnosis and remediation time have entirely different fixes, and a staff-level candidate who proposes a solution before establishing which one dominated has just told you how they run incidents.

How to weight it

These weightings hold across the DevOps family. Each band sums to 100.

0–2 years. Technical assessment 40 per cent. Labs 20 per cent, one lab. Scenarios 15. Behavioural 15. Résumé verification 10. No architecture component.

2–5 years. Technical assessment 25 per cent. Scenarios 25. Labs 25, two labs. Behavioural 15. Résumé verification 10. Still no architecture.

5–8 years. Scenarios 25 per cent. Labs 25, three labs. Technical assessment 15. Architecture and system design 15. Behavioural 15. Résumé verification 5.

8–12 years. Architecture and system design 25 per cent. Labs 25, four labs. Scenarios 20. Technical assessment 10. Behavioural 15. Résumé verification 5.

Four things move across those bands, and the reasoning behind each is the part worth arguing with.

Technical recall falls from 40 per cent to 10. At two years, knowing how things work is most of what there is to know, because there has not been time for judgement to form. At ten, a candidate who still scores primarily on recall has been standing still.

Architecture appears at five years and doubles by eight. Not because juniors cannot think structurally, but because assessing it requires them to have owned something large enough to have failed interestingly. Scoring architecture at two years measures reading.

Labs scale in count rather than weight. They hold at a quarter of the score from 2–5 onward while the number rises from one to four. More surface area at the same proportion, because what changes with seniority is the breadth of situations someone should handle, not how much hands-on ability matters.

Résumé authenticity de-emphasises with seniority, from 10 per cent to 5. This one is counterintuitive and worth saying plainly: it is not that senior candidates lie less. It is that at senior level the other components catch it anyway. You cannot fake an architecture discussion or a four-lab set, so authenticity stops needing its own weight and becomes a gate instead.

What a hands-on task shows that an answer cannot

Three tasks carry most of the signal for this family. Naming them is easy; the value is in what each exposes.

A container build. For juniors, the fastest read available. Multi-stage or not, base image choice, whether anything runs as root, whether the image is 1.2 GB for no reason. Fifteen minutes of building tells you more than an hour of Docker questions.

A delivery pipeline design. The mid-level workhorse. Give someone a team that keeps breaking production and ask them to design the pipeline that stops it. What you are grading is not the stage list, it is the order and the gates. Strong: checks before deploy, something gating production, a rollback path, and when you push back that the pipeline is too slow, they parallelise the slow stages rather than deleting the safety. Borderline: right stages with one gating flaw, no rollback or nothing gating production. Weak: deploys before testing, no gate, no rollback, and no account of where a bad change would have been caught.

An incident simulation. The senior read, and the one that separates people fastest. Hand over a broken system rather than a design question. The signal is in the sequence: do they establish blast radius before root cause, do they stabilise before they explain, do they say out loud what they expect to see before they look. Anyone who has carried a pager does this without being prompted.

The structural case for hands-on work is worth stating as an argument rather than a finding. A task produces an artifact, and an artifact either holds up or it does not. An answer only has to survive the next thirty seconds. That is a claim about the shape of the two things, and nobody has published the study that would settle it.

The two overrides

Two rules sit above the weighted score, and both cap rather than reject.

The authenticity gate. Where verification turns up fabrication, as distinct from vagueness, the recommendation caps at borderline regardless of what the rest of the interview produced, and goes to a person with the specific exchange attached. Severe or repeated fabrication is a no. The reason it caps rather than fails outright is that someone is making a judgement about another person's memory under pressure, and that judgement should be reviewable by a human who can see the transcript.

The critical-skill floor. Where a skill the role genuinely depends on scores below threshold, cap at borderline even when the total is strong. This exists to prevent one specific bad hire: the candidate who is excellent across five dimensions and cannot do the thing you are hiring them to do. Totals hide that. Floors do not.

Both overrides produce a flag and a case rather than a decision, which is the design principle behind the interview engine we are building: it assembles evidence and a recommendation, and a person decides.

On running it

This structure takes longer than the interview it replaces, and it is meant to. The probes alone add fifteen minutes.

What you get back is a first round whose output can be handed to a hiring manager without a conversation attached to explain it. That is the only version of this that survives past the person who designed it.