How to Screen DevOps Engineers: 9 Questions and What to Listen For Screening Interview Template

Describe the most complex piece of infrastructure you designed or significantly changed. What were the key decisions, and what did you trade away to get them?

What this assesses: The trade-off half of the question is the part that separates people. Strong answers name the decision and the price: multi-AZ rather than multi-region because the recovery target did not justify the replication cost, a managed database because the team was three people, a queue instead of direct calls with the added latency stated out loud. They are also clear about which part they shaped versus which part was already there when they arrived. Weak answers describe an architecture in the passive voice, list services without a single decision attached, or say the design had no downsides. Anyone who says they chose Kubernetes because it is the standard was not in the room when it was chosen.

How do you define and measure reliability for the systems you run? What target did you actually set, and what did you give up to hold it?

What this assesses: Listen for a number tied to something a user would notice, not to host uptime. Strong answers measure the thing that matters, such as checkout success rate or p99 latency on the read path, know the difference between an objective and a dashboard, and can name what reliability cost them: a release held back, a feature blocked, a quarter spent on a replica set nobody outside the team saw. Weak answers claim five nines with no measurement behind it, or define reliability as the monitoring agent reporting the server is up. If nothing was ever traded away to hit the target, the target was decoration.

Tell me about a security problem you found in your own infrastructure. How did you find it, what did you do first, and what stopped it from coming back?

What this assesses: Two signals here. First, did they find it, or did an auditor hand it to them on a spreadsheet. Strong answers describe their own review turning it up, an over-permissive role spotted during a least-privilege pass, a public bucket caught by a scanner they wired in, credentials in a repository found before anyone used them. Second, did the fix generalize. Strong answers contain first, rotating the key or closing the group, then remove the whole class of problem with a policy, a CI check, or a safer default. Weak answers stop at the one-time cleanup. A candidate with years in infrastructure who cannot recall a single security issue either has not looked or is not telling you.

If you have built or contributed to internal tooling for developers, what did you make self-service first, and how did you know it worked?

What this assesses: Strong answers start from friction, not from architecture: the new-service scaffold, the ephemeral environment, read access to production data, the rollback button. Then they show evidence, which is almost always tickets that stopped arriving, time from empty repo to first deploy, or the number of teams that adopted it without being told to. Weak answers describe a platform nobody used, or a Terraform wrapper written once and abandoned. No platform experience is a fine answer if the candidate can name the three requests they still handle by hand every week, because that is the same instinct without the title.

Walk me through a migration you ran on a system that could not go down. What was the cutover plan, and what went differently than planned?

What this assesses: Strong answers have a shape you can recognize: dual writes or shadow reads, a backfill with a verification step, a gradual cutover behind a flag or a weighted route, and a rollback path that stayed live long enough to matter. They also answer the second half honestly, because something always goes sideways. The backfill ran three days long, a client had the old endpoint cached, the rollback got used at two in the morning. Weak answers describe a maintenance window, which is a downtime plan rather than a zero-downtime one, or report a migration where nothing surprised them, which usually means it was small or it was somebody else's.

What did your cloud bill look like, what was the biggest line item, and what did you change to move the number?

What this assesses: People who owned infrastructure at a company that cared about money know this number. Strong answers give a rough monthly figure, name the top line, usually compute, egress, or a logging vendor charging by ingest, and describe one change with a result attached: rightsizing after actually reading utilization, committed use or spot for the steady base, cutting log retention that nobody queried past a week, or fixing a chatty cross-zone call path. Weak answers never saw the bill, or did cost work assigned to them without ever learning what it saved. The specific dollar figure matters less than whether cost was ever their problem.

A request path is slow and no single service looks broken. Walk me through how you actually find it.

What this assesses: This is a method question, and the good answers sound like a method. Strong candidates start from a trace or a request ID rather than a hunch, compare median against the tail because an average hides the problem, look for saturation and queueing rather than only errors, and correlate against the last deploy or config change. They name what instrumentation already existed and what they had to add mid-investigation. They usually have a story where the cause was outside their code entirely: connection pool exhaustion, a client retry storm, DNS, a noisy neighbor. Weak answers are check the logs and look at CPU, which is where you start, not how you finish.

What was on-call actually like on your last team? How often did your phone go off, who else was in the rotation, and what did you fix so a page stopped happening?

What this assesses: The last part of the question is the one that predicts the hire. Strong answers give real frequency, two or three pages a week with one outside business hours, name the rotation size, and then describe an alert they deleted or automated out of existence and why it was safe to do so. That is someone who removes toil rather than absorbing it. Weak answers stay vague, say it was not bad without numbers, or describe a rotation they were adjacent to instead of on. A candidate who was paged nightly for a year and changed nothing is telling you exactly how they will treat your alerts.

What is in your stack today, and where would you need to ramp up on ours? Name the parts you would want someone else to own.

What this assesses: Calibration beats coverage. Strong answers claim two or three things confidently and mark the edge of each: fluent in Terraform including recovering from broken state, has run Postgres in production but never split a shard, uses Kubernetes daily but has never stood up a cluster without a platform team behind it. Naming what they would rather hand off is not weakness, it tells you where your risk actually lands after the hire. Weak answers list a dozen tools at uniform depth, or lean on picking things up quickly without saying what would need picking up. Nobody is strong across networking, databases, security, and developer experience at the same time.