The screen almost everyone runs, and why it misses
The standard DevOps interview is a tool inventory. Kubernetes, Terraform, the CI system you happen to use, whichever cloud. It produces a confident yes or no and tells you very little, because tooling is the most transferable part of the job and the fastest thing to learn on arrival.
What does not transfer is judgement under pressure and a disposition toward permanent fixes. Those are the two things that decide whether your first reliability hire reduces incidents or simply absorbs them.
If you only test one thing
Ask them to walk you through an incident they owned end to end — detection, mitigation, root cause, and what they changed so it could not recur. The last clause is the whole test.
Production reliability and incident response
This is the competency the role fails without. It is also the one where a plausible answer and a strong answer sound similar for the first thirty seconds.
| Weak | Strong |
|---|---|
| Treats on-call as fire-fighting. The story ends when the service came back up. | Treats an incident as a defect in the system that allowed it. The story ends with what changed. |
| Manual patches, applied under pressure, described with some pride. | Automated remediation, or a design change that removed the failure mode. |
| Root cause is named as a component ("the database fell over"). | Root cause is named as a decision ("we had no backpressure, so a slow consumer took the queue with it"). |
A useful follow-up: what did you decide not to fix, and why? Strong operators have a list. They have made a call that some failure mode was cheaper to absorb than to engineer around, and they can tell you the reasoning. Someone who has never made that trade has probably never owned a budget or an error budget.
CI/CD, and the gatekeeper problem
Pipeline work reveals disposition more clearly than anything else in this role, because there are two coherent philosophies and they produce opposite teams.
- The gatekeeper builds a pipeline only they understand, and becomes the bottleneck every deploy routes through. This can look like seniority from the outside — they are always involved, always needed.
- The enabler builds templates other engineers extend without asking, and measures their own success by how rarely they are needed.
Ask what the deploy process looked like when they arrived and what it looked like when they left, then ask who else could change it. The answer to the second question is the one that matters. A pipeline nobody else can safely touch is a brittle pipeline regardless of how elegant it is.
Cost, which nobody screens for and everybody regrets
Over-provisioning is the default failure of a reliability hire with no cost exposure, and it is invisible until the bill arrives. "Just to be safe" is a real engineering position; it is also how a small team ends up paying enterprise infrastructure prices for a service with modest traffic.
You do not need a finance interview. One question does it: ask what their infrastructure cost, roughly, and whether they could have run it for less. Someone who has never looked will say so. Someone who has will have a number and an opinion about it.
What not to screen for
- Memorised command syntax. It is a search away and it dates faster than the interview does.
- Your exact stack, unless the hire is genuinely short-term. A strong operator learns your cloud in a fortnight; disposition does not change in a fortnight.
- Certifications, as a proxy for judgement. They evidence study, which is worth something, but not the incident instinct this role lives on.
- Willingness to be on call at any hour. Screening for that selects for burnout, and it is the reliability equivalent of hiring on hours worked.
The general version of this — how to pick questions that separate candidates rather than questions they can prepare for — is in technical interview questions that discriminate. For the written half of the screen, how to test technical skill without a puzzle.