DevOps interviews cover a wide surface — CI/CD, cloud, infrastructure-as-code, containers, observability, security, and the dreaded “a service is down at 2am, what do you do?” But the best ones aren't testing whether you memorised a flag. They're testing whether you can reason about reliability, automation, and trade-offs under pressure.
Topics to be genuinely fluent in
- CI/CD: pipeline design, build/test/deploy stages, rollbacks, deployment strategies (blue-green, canary).
- Cloud + IaC: core services of at least one provider, and Terraform/config-as-code principles — idempotency, state, modules.
- Containers + orchestration: Docker fundamentals and Kubernetes concepts — pods, services, scaling, health checks.
- Observability: metrics, logs, traces, and what you'd actually alert on (and what you wouldn't).
- Incident response: a calm, structured approach to “it's broken,” from triage to mitigation to postmortem.
The scenario question is the real test
“Deploys are failing intermittently — how do you debug it?” There's no single answer; they want your method. And the highest-signal version is the incident walkthrough: something breaks, and they watch how you think.
“First move is stop the bleeding, not diagnose. If error rates spiked right after the deploy, I roll back to the last known-good version — mitigate first, investigate second. Users don't care about my root cause; they care that it works.
Once it's stable, I look at what changed. The deploy is the prime suspect, so I diff it against the previous release — config, image tag, migrations, dependency bumps. I check the timeline: did errors start exactly at rollout, or was there a lag that points at something like a warmed cache or a slow migration?
Then I narrow with the cheapest signals first — error logs and the dashboards I already have, before I go SSH-ing into boxes. Say the logs show a connection-pool exhaustion: that points at a config change to pool size or a new query pattern. I confirm the hypothesis, fix forward or keep the rollback, and write it up.
Postmortem's blameless: why did CI pass? Do we need a canary stage so the next bad deploy hits 1% of traffic, not 100%? The fix isn't just this bug — it's the gap that let it ship.”
Notice the order: mitigate, then diagnose cheaply, then prevent recurrence. Panic-poking at random reads completely differently from that calm narrowing-down. It's the same structured reasoning an SRE interview grades — the two roles overlap heavily.
1. Mitigate: is there a rollback / feature-flag kill switch? Do it first. 2. What changed? Diff the deploy — config, image, migrations, deps. 3. Cheapest signal first: dashboards & logs before shells & tcpdump. 4. Hypothesis → confirm → fix forward or stay rolled back. 5. Blameless postmortem: what let it ship? Add the guardrail.
What changes by level
Junior
You're expected to know the tools and follow a runbook. In a scenario, showing you'd escalate sensibly, check the obvious things, and not make it worse is a pass. Solid fundamentals — what a container is, what a pipeline stage does — matter more than clever architecture.
Intermediate
Now you own the method. Drive the incident without prompting, design a pipeline unprompted, and justify choices — “canary here because the blast radius of a bad model change is high.” You should reason about trade-offs, not just name tools.
Senior or staff
It's about systems and prevention. They'll push on organisational things: how do you reduce toil, set deployment standards, design for graceful degradation, and stop the same class of incident recurring? You're expected to talk about blast radius, guardrails, and the human process around reliability, not just the fix.
Practising the remote format
These rounds are usually a call with screen-share, sometimes a shared terminal or a whiteboard for the pipeline diagram. Same rule as everywhere: narrate. If they hand you a terminal, say what you're about to run and why before you run it — “I'll check the pod status first to see if it's crash-looping.” Thinking out loud while your hands work is the exact skill from a coding round, just applied to infrastructure.
Jumping to root-cause analysis while prod is still down. In a real incident and in the interview, mitigation comes first — a candidate who diagnoses for ten minutes while users are erroring is answering the wrong question. Say “first I'd stabilise, then investigate” out loud; it's the single clearest seniority signal in the whole round.
- Can you walk an incident from alert to blameless postmortem, out loud, without notes?
- Can you design a CI/CD pipeline for a small team and justify each stage?
- Do you lead with mitigation before diagnosis in every scenario?
- Can you explain what you'd alert on — and what you'd deliberately not?
- Have you practised narrating while “driving” a shared terminal?
Pick one failure — “an API's latency just doubled after a deploy” — set a 15-minute timer, and talk through it end to end as if you're in the war room: mitigate, diagnose cheaply, confirm, prevent. Record it. The goal is to make the calm, ordered narration automatic, because that ordering is the first thing nerves scramble.
Trivia you can flashcard. Scenarios you have to talk through out loud, because the real skill is structured reasoning while staying calm. Fit it into the wider loop with the realistic technical prep plan — and if you're weighing this path against a reliability role, the SRE prep guide is worth reading alongside this one.
Practise the scenario out loud
Run a realistic voice mock DevOps interview, narrate an incident from mitigation to postmortem, and get a scored report. Free to start — no credit card.
Start freeFrequently asked questions
What topics come up in a DevOps interview?
CI/CD and deployment strategies, cloud and infrastructure-as-code, containers and Kubernetes, observability (metrics/logs/traces), security basics, and incident-response scenarios. Expect open-ended 'how would you debug/design this' questions, not just trivia.
How do I answer a 'deploy broke prod' scenario?
Mitigate first — roll back or flip a kill switch — before diagnosing. Then find what changed by diffing the deploy, narrow with the cheapest signals first, confirm your hypothesis, and finish with a blameless postmortem that adds a guardrail. Leading with mitigation is the clearest seniority signal.
How do I practise for DevOps scenario questions?
Talk through real scenarios out loud end to end — designing a pipeline, debugging a broken deploy, responding to an incident — on a timer. The skill being tested is structured reasoning while staying calm, which only improves with spoken reps.