DevOps interviews have a shape most candidates don't expect. There's rarely a whiteboard algorithm. Instead there's a series of "how would you" and "what would you do when it breaks" questions — and the interviewer is listening for whether you've actually been on call, or only read about it.
Below are 20 questions grouped by the rounds a real DevOps loop uses, with the experience level each group usually targets. For each group there's also a note on how to say the answer out loud, because these rounds are almost entirely spoken.
WhalePrep observation: DevOps interviews reward specifics more than almost any other role. "We used Kubernetes" says nothing. "We ran three clusters and the painful part was upgrade windows" says you were there.
CI/CD and release engineering
Almost always the opening round. Weighted heavily for Junior and Middle candidates.
- Walk me through a pipeline you've built. What happens between a commit and production?
- What's the difference between continuous delivery and continuous deployment?
- How do you roll back a bad release? Compare blue-green and canary deployments.
- How do you keep secrets out of your pipeline and out of your repo?
Saying it out loud: question 1 is an invitation to give a tour, and most candidates give a list of tool names instead. Structure it as a journey with decision points: "Commit triggers the pipeline. Unit tests and a lint gate run in parallel, then we build a container image tagged with the commit SHA. That image goes to staging automatically. Production needs a manual approval, because we're a small team and we wanted a human in the loop for the last step." The last clause is the important one — it explains a tradeoff you chose, which is what separates an engineer from a tool user.
Containers and orchestration
The Middle-level core. Expect Docker fundamentals plus at least one Kubernetes debugging question.
- What's actually different between a container and a virtual machine?
- What happens, step by step, when you run
kubectl applyon a Deployment? - How do liveness and readiness probes differ, and what breaks when you configure them wrong?
- A pod is stuck in CrashLoopBackOff. Walk me through your debugging.
Saying it out loud: question 8 is a process question disguised as a knowledge question. The interviewer wants your debugging order, narrated: "First kubectl describe pod to see events — that catches image pull errors and failed mounts immediately. If events look clean, kubectl logs with the previous flag, because the current container is already gone. If the logs are empty, I'd suspect the container is dying before it can log, so I'd check the command and the readiness probe timing." Narrating the order shows you've done it. Naming the tool alone doesn't.
Why this works: every "how would you debug" question is really asking "what would you check first, and why that first?" Prioritisation is the signal. Candidates who list every possible cause in random order sound less experienced than candidates who name three in the right sequence.
Infrastructure as code and cloud
Middle to Senior. This round tends to decide your level.
- What problem does Terraform state solve, and what goes wrong when two engineers apply at the same time?
- What does immutable infrastructure mean in practice, and why does it matter?
- How do you structure infrastructure code across dev, staging, and production?
- How would you design a service to survive an availability zone going down?
Saying it out loud: for question 9, don't just define state — go to the failure, because that's what's really being asked: "State is how Terraform maps your config to real resources. Two people applying at once is the classic disaster: without locking, the second apply reads stale state and can destroy something it thinks is gone. That's why remote state with locking isn't optional — we used S3 with DynamoDB locking." Definition, failure mode, mitigation. Three beats, roughly twenty seconds.
Monitoring, observability, and incidents
Middle to Senior. The on-call story here is often the most memorable part of your interview.
- What's the difference between monitoring and observability?
- What would you actually alert on, and how do you avoid alert fatigue?
- Tell me about an incident you were on call for. What did you do in the first ten minutes?
- What makes a postmortem useful rather than a formality?
Saying it out loud: question 15 is the highest-leverage question in the whole loop, and the trap is telling it as a hero story. Interviewers want calm process, not drama: "Alerts fired at 2am for elevated 5xx. First thing I did was check whether anything had deployed in the last hour — it had. I rolled back before diagnosing, because restoring service comes first. Then we found the root cause in a migration that hadn't been backwards compatible." Notice: mitigate first, diagnose second. Saying that out loud in the right order signals real on-call instincts.
Linux, networking, and access
Asked at every level — the fundamentals round that catches people who only know the managed-service layer.
- A production server is out of disk space. How do you find what's using it?
- Walk me through what happens on the network between a user typing a URL and your app responding.
- Where does TLS get terminated in a typical load-balanced setup, and what are the tradeoffs?
- How do you handle least-privilege access — and why are long-lived access keys a problem?
Saying it out loud: question 18 is deliberately enormous. Don't try to cover everything; scope it out loud first: "I'll go end to end but stay shallow unless you want me to go deep somewhere — DNS resolution, then TCP and the TLS handshake, then the load balancer picking a backend, then our ingress routing to a pod." Then pause and let them steer. Candidates who ask "how deep do you want me to go?" score better than candidates who monologue for six minutes and never reach the interesting part.
Practical target: prepare one real story for each of the five groups — a pipeline you built, a pod you debugged, a state conflict you hit, an incident you handled, a server you fixed. Twenty questions collapse into five stories, and stories survive interview nerves far better than definitions.
The part that isn't about infrastructure
The uncomfortable truth about DevOps interviews: the questions above are mostly things you already know from the job. What's hard isn't knowing — it's explaining a complex system clearly, out loud, in a second language, while someone waits.
That skill degrades sharply under pressure, and it's separate from the technical material. We wrote about why that happens, and what to do about it, in Why smart candidates fail English interviews.
The practical version: take three questions from this page — ideally the on-call one — and answer them out loud, end to end, before your next interview. Not rehearsed in your head. Out loud, where you can hear where the structure falls apart.
