What do DevOps engineer interviews actually test?

Who you're actually talking to

For most DevOps roles you won't meet a generalist recruiter for the technical rounds. After an initial screen (often a talent partner checking notice period, salary, right to work), the people asking the hard questions are usually the ones you'd work alongside: a platform or SRE lead, a senior DevOps engineer, sometimes the engineering manager who owns the on-call rota. In regulated environments — finance, healthcare, anything touching PCI or SOC 2 — a security engineer often sits in on at least one round, because access control and audit trails are part of the job, not a side concern.

This matters because these interviewers have usually been paged at 3am for something you'd be expected to fix. They are not testing whether you can define "CI/CD" or list AWS services. They are testing whether they'd trust you with production access.

The technical screen: what it actually looks like

Most pipelines for this role include one of three formats, sometimes two of them:

A take-home or live exercise involving real broken infrastructure. You might get a repo with a Terraform module that fails to apply, a Dockerfile that builds a 2GB image when it should build 200MB, or a GitHub Actions/GitLab CI pipeline that passes locally but fails in the runner. You're asked to fix it and explain your reasoning, not just paste a working diff. Interviewers pay attention to whether you check the plan output before applying, whether you look at exit codes and logs before guessing, and whether you explain why the fix works rather than that it works.

A live debugging or pairing session. You share your screen, they hand you a Kubernetes cluster (often kind or minikube) with a pod stuck in CrashLoopBackOff, or a service returning 502s behind a load balancer, and you talk through your diagnosis in real time: kubectl describe pod, checking resource limits, reading events before reading logs, checking whether it's the app or the ingress. The value is entirely in the narration. Silence while you type is a worse signal than a wrong first guess followed by a sensible next step.

A whiteboard or verbal system design round. Design a deployment pipeline for a service with a hard uptime requirement, or design how you'd roll out a schema migration with zero downtime, or design monitoring for a set of microservices. These are judged on trade-offs: blue-green versus canary, why you'd choose one autoscaling policy over another, what you'd put in a dashboard versus what you'd alert on, how you'd set an SLO and what you'd do when the error budget runs out.

The questions that are actually probing competence

A few questions come up in almost every DevOps interview, and each one has a version that separates people who've done the work from people who've read about it.

"Walk me through an incident you handled." A real answer names the symptom, the diagnostic steps in order, the actual root cause, the immediate fix, and — crucially — what changed afterwards: a new alert, a runbook, a change to a deploy gate. It also usually includes something that went wrong in the response itself, because incidents rarely go cleanly. If the story has no postmortem and no follow-up action, the interviewer will ask what changed, and there needs to be an answer.

"How do you manage secrets?" They're listening for whether you distinguish between secrets in version control (a fail), secrets in environment variables (a partial answer), and secrets pulled at runtime from something like Vault, AWS Secrets Manager, or SSM Parameter Store with scoped IAM roles and rotation. Bonus points, unprompted, for mentioning how you'd rotate a credential that's already leaked, because that's the question behind the question.

"What's the difference between your monitoring and your alerting?" This tests whether you think in SLIs and SLOs or just in dashboards. A strong answer separates what you'd look at during an investigation (metrics, traces, logs — ideally named: Prometheus/Grafana, Datadog, the ELK or Loki stack) from what should actually wake someone up, and explains why alert fatigue is a design failure, not an inevitability.

"How would you roll this back?" Asked about almost any deployment scenario. The answer needs a concrete mechanism — a previous image tag, a Helm revision, a database migration that's reversible or at least forward-compatible — not "we'd just redeploy the old version," which assumes the old version is still buildable and that the rollback itself won't break something else.

"Why Terraform/Ansible/Puppet over the alternative?" Less about the tool and more about whether you understand declarative versus imperative state management, what drift is, and how you detect and reconcile it. If your team uses GitOps (ArgoCD, Flux), expect a question about what happens when someone changes something directly in the cluster instead of through Git, because that's the actual daily friction of the model.

What a shallow answer sounds like

To someone who does this job, a shallow answer has a specific shape. It names tools without naming a decision: "we used Kubernetes and Terraform and Jenkins" tells the interviewer nothing about what you actually chose or why. It skips the failure mode: describing a deployment process with no mention of what happens when it fails, or a monitoring setup with no mention of what you're not currently watching. It treats "I'd restart it" as a diagnosis rather than a stopgap — restarting a pod might clear a symptom, but if you can't say what caused the crash, the interviewer knows you'd be back at 3am doing it again. And it answers system design questions with a single architecture and no alternatives considered, which reads as having memorised one diagram rather than having weighed trade-offs on a real system with real constraints — cost, team size, existing tooling.

The inverse is also true and worth knowing: over-explaining every acronym, or reciting a textbook definition of blue-green deployment when asked how you'd deploy a specific service, reads the same way. The interviewer wants your reasoning applied to their scenario, not a general lecture.

What to do before the interview

Go back through your last two or three real incidents, migrations, or infrastructure changes and write out, in order: symptom, diagnosis steps, fix, and what changed afterwards. If you can't fill in the last part, that's worth noticing before the interview, not during it.

If the role's advert mentions specific tools — Terraform over Pulumi, EKS over self-managed Kubernetes, Datadog over open-source Prometheus — check your own experience against that stack honestly. Where you've used the equivalent but not the exact tool, say so and explain the mapping; interviewers generally respect "I've used Chef, not Puppet, but the model's the same" far more than a vague claim of familiarity that falls apart under one follow-up question.

And if you're sending out a high volume of applications and hearing nothing, it's worth checking whether the advert's specific requirements are showing up early enough in your CV to get you to this stage at all — the interview only tests what you already know; it can't fix a CV that buries the Kubernetes and Terraform experience the advert asked for on page two.