How to interview a DevOps engineer without a whiteboard
Algorithm questions predict very little for this role, because the work is diagnostic rather than compositional. Nobody in an infrastructure job is asked to invert a tree; they are asked why a deployment that worked on Tuesday fails on Thursday with an error message written by somebody who assumed you had the source code. Interviewing well means reproducing that situation honestly, which is harder to arrange than a whiteboard and considerably more informative.
Why do coding puzzles fail for infrastructure roles?
Because they test the ability to construct a solution from a clean statement, and infrastructure work almost never starts from a clean statement. It starts from a symptom, an estate somebody else built, and incomplete information. The skill being hired is narrowing an uncertain problem quickly under pressure, and a puzzle with a known answer measures the opposite thing.
There is a second, quieter cost. Strong candidates in this discipline often come from operations backgrounds rather than computer science ones, and a puzzle round filters them out first. The people who remain are those who recently practised puzzles, which correlates with job hunting rather than with capability.
This is not an argument against asking candidates to write code. They should write code, because Terraform, pipeline definitions and glue scripts are code and get reviewed like code. The argument is that the code should be the kind they will actually write, in the presence of the ambiguity they will actually face.
Which interview formats produce real signal?
Four of them, and each is good at a different thing. Most hiring processes use one and infer the rest, which is how a candidate who debugs superbly ends up unable to explain a rollback to a stakeholder, or the reverse.
| Format | What it measures well | What it misses | Effort to run |
|---|---|---|---|
| Broken environment exercise | Diagnostic order, tolerance for uncertainty, tool fluency | Judgement over a longer horizon, and design taste | High to build once, low to repeat |
| Review of a deliberately flawed pull request | Whether they catch blast radius, drift and security problems in someone else's work | How they behave when the system is on fire | Low |
| Walkthrough of an incident they handled | Honesty, follow-through, how they talk about colleagues | Anything you cannot verify, so treat as a conversation not a test | Low |
| Design conversation on your real estate | Trade-off reasoning, and whether they ask what the constraints are | Execution, since talking well and building well are separate skills | Low |
| Take-home pipeline build | Code quality and documentation habits | Speed and pressure, and it excludes people with caring responsibilities | Medium, and it costs the candidate most |
| Live algorithm coding | Little that applies to the role | Essentially the whole job | Low, and it filters out strong operations backgrounds |
How do you build a broken environment exercise?
Take a small application in a container, deploy it somewhere disposable, and break exactly two things: one obvious and one that only appears under a specific condition. A missing environment variable that causes an immediate crash loop is the obvious one. A readiness probe pointing at a path that returns a redirect, so the pod never becomes ready even though the process is healthy, is the second. Give forty-five minutes, full internet access, and an explicit instruction that guessing aloud is welcome.
What you are watching for is order. Strong candidates establish the shape of the problem before touching anything: what state is the workload in, what do the events say, has it ever worked, what changed. Weaker candidates start applying fixes in the first two minutes, which is the exact behaviour that turns a ten-minute incident into an outage.
Score it on process, not completion. A candidate who finds the first fault, describes precisely how they would isolate the second and runs out of time has demonstrated more than one who fixed both after being nudged twice. Write the rubric before the first interview, or the panel will unconsciously reward whoever reminds them of themselves.
Which questions actually separate candidates?
Ask what they have deleted. The answer distinguishes people who have operated a system from people who have only built one, because deletion requires knowing what is genuinely unused, and that knowledge only comes from having run the thing for a while. Follow up on how they established it was safe to remove.
Ask what is in their current Terraform state that should not be, or what part of their infrastructure is not in code at all. Everyone has an answer. The value is in whether they know it, can explain why it ended up that way, and have a proportionate view of whether it matters. Candidates who claim everything is fully coded and drift-free are either working somewhere unusually disciplined or not looking.
Ask about a time they said no to a developer or a manager, and what happened afterwards. Half of this job is negotiating with people who want a change immediately. A candidate who has never refused anything will not hold a release gate, and a candidate who enjoys refusing will become the bottleneck the hire was meant to remove.
How do you test whether they can work with developers?
Give them something to explain. Ask them to describe, in plain terms and in under two minutes, what a rollback is and why it is sometimes the wrong response. The role sits between engineering and everybody else, so the ability to give a non-specialist an accurate answer without condescension is a working requirement rather than a nice extra.
Then have an engineer from the team they will support sit in one round. Not to assess technical depth, but to answer the question the panel cannot: would you ask this person for help twice. If a developer would rather work around them than approach them, the platform work will be ignored no matter how good it is.
The failure mode to watch for is contempt. It usually arrives dressed as standards: developers who do not understand containers, teams who write bad manifests. Some of that is fair. A candidate who cannot also describe what makes those mistakes reasonable is going to build a platform that punishes its users.
What signals should you ignore?
Certifications, tool bingo, and the size of somebody's home lab. Certifications demonstrate that a syllabus was completed, which is weak evidence about behaviour under pressure. Tool lists on a CV mostly reflect the shape of the last employer. A home lab is a hobby, and plenty of excellent engineers do not want a second data centre in the spare room.
Be equally sceptical of years of experience with tools that have not existed long, and of anyone claiming deep production experience with something released in the last eighteen months. Both usually indicate a CV written to match a job ad, which is a rational response to keyword screening rather than dishonesty, but it means the number tells you nothing.
The awkward case is the first infrastructure hire, where nobody internal can judge the technical answers. Do not solve this by asking harder questions. Solve it by bringing in a practitioner for one round, or by paying an experienced contractor for a day to design and mark the exercise. Assessing a specialist you do not have is a problem you can buy your way out of cheaply, and hiring the wrong person is not.
Common questions
- How should you technically assess a DevOps engineer?
- With a diagnostic exercise rather than an algorithm test. Deploy a small containerised application into a disposable environment, break two things, and give the candidate forty-five minutes and full internet access to work out what is wrong. Score the order in which they investigate, not whether they finish. Pair that with a review of a deliberately flawed infrastructure pull request, which shows whether they notice blast radius and drift in somebody else's work.
- What questions should you ask a DevOps candidate?
- Three that consistently separate people. What have you deleted, and how did you establish it was safe? What in your current infrastructure is not in code, and why did it end up that way? When did you last refuse a request from a developer or a manager, and what happened next? Each requires having operated a system rather than only built one, and none can be prepared from an interview question list.
- Should you give a DevOps candidate a take-home test?
- Only if the alternative is worse. Take-homes produce good evidence of code quality and documentation habits, but they cost the candidate several unpaid hours and systematically exclude people with caring responsibilities or a current job. A live exercise on a prepared broken environment gets most of the same signal in under an hour, and shows behaviour under time pressure that a take-home cannot.
- How do you interview an infrastructure engineer if nobody on the team is one?
- Buy the expertise for the assessment rather than guessing. An experienced practitioner engaged for a day can design the exercise, sit the technical round and write the rubric, which is a small cost against a mis-hire in a role that will hold production access. Do not compensate by asking harder written questions, because without an expert on the panel the answers cannot be evaluated.
- Do certifications matter when hiring DevOps engineers?
- Very little on their own. A cloud certification confirms that a syllabus was completed and gives no evidence about diagnostic behaviour, judgement or how somebody works with developers. They can be mildly useful as a signal of self-directed study for a career changer. They are a poor basis for shortlisting, and screening on them tends to filter out strong candidates from operations backgrounds.
