SRE vs DevOps Interview: What Is Actually Different?
The two loops overlap more than the job titles suggest, and the part that differs is not the part most candidates prepare. Here is what actually changes, based on what candidates report being asked and what employers publish about their own interviews.
- read
- 7 min read
- read
- last updated
- September 2026
- last updated
The shared half is bigger than you think
Read enough first-hand accounts of both and the same questions keep appearing: a pod in CrashLoopBackOff, what an inode holds, how many hosts are in a /23, reviewing a Terraform module someone else wrote, writing a pipeline. Employers publishing their own interview guides name the same ground — Terraform, cloud networking, Kubernetes debugging, reliability practice. That pool is common to both titles, and it is where most interviews spend most of their time.
So the honest answer to "what should I study differently" is: for a large part, nothing. If you are preparing for one and get invited to the other, most of your preparation transfers. What differs is a layer on top, and a question about the job itself that DevOps candidates rarely have to ask.
Gnoseed offers free open-answer practice for both — the DevOps set and the SRE set — and they were deliberately built to overlap in theme without duplicating cards.
Reasoning about a system past the point where it still works
The reliability layer is the genuine difference. A DevOps interview asks how you would deploy something safely; an SRE interview asks what happens when the thing is already overloaded and your response makes it worse. Cascading failure, retry amplification, load shedding, circuit breakers and the reason latency turns sharply upward near full utilisation — these come up in SRE loops and rarely in DevOps ones.
The second addition is arithmetic. SRE design rounds expect numbers: how many machines, how much disk, what the network costs, what happens if a zone disappears. One employer names its method — Non-Abstract Large System Design — and says explicitly that the reasoning is scored more than the answer. A candidate who draws boxes and never divides anything will pass a general design round and fail this one.
Third is SLO practice rather than SLO vocabulary. Both loops ask what an SLI, SLO and SLA are. Only the SRE loop tends to follow with where you measure the indicator, what burn-rate alerting is and why it uses two windows, and who has to agree an error budget policy before it obliges anyone to do anything.
Delivery rationale is the other side of the trade
DevOps loops spend more time on the delivery pipeline as a system of decisions: trunk-based development versus long-lived branches, blue-green against canary against rolling, what decoupling deployment from release buys you, how database migrations fit into continuous delivery, and what makes a build "continuous integration" rather than a build server on a timer.
There is also more organisational ground — introducing practices into a company with a separate operations team, reconciling a change advisory board with continuous deployment, and how an org chart ends up visible in the architecture. Those questions are asked less often verbatim than the operational ones, but they are where a senior DevOps candidate is separated from a mid-level one.
"SRE" does not mean one thing
The title spans, in practice, a software engineer who writes reliability tooling and carries a pager; an infrastructure specialist who operates Kubernetes; and, in some places, a systems administrator role that was renamed. One interviewer put it plainly on a public forum: SRE is an overloaded term to the point that even inside one large company it can mean vastly different things, with separate software-engineering and systems-engineering interview tracks.
That has a practical consequence for preparation. A coding-heavy loop and a troubleshooting-heavy loop are advertising different jobs, and the interview's own shape is evidence about which one you are in. It is entirely reasonable to ask early: how much of the team's time is spent writing code versus operating, who owns production change, whether the team can decline to support a service, and what the on-call load actually is. Asking well reads as seniority.
DevOps has its own version of this ambiguity, but it bites less often, because the DevOps loop varies more in emphasis than in kind.
One pool, then the layer on top
Prepare the shared operational ground first, because it is the majority of both loops and it transfers completely: container and Kubernetes troubleshooting, Linux and systems fundamentals, networking from DNS to the load balancer, reading and reasoning about infrastructure code, and pipeline mechanics.
Then add the layer for the title you are interviewing for. For SRE that is failure under load, capacity arithmetic, SLO practice and the role questions above. For DevOps it is delivery strategy and the rationale behind the practices. If you have time for both, do both — the overlap means the second one costs far less than the first.
One last thing that applies to either: check the tooling policy before the day. Some employers now disable AI assistants during interviews and say so in writing, while others encourage their use. Being surprised by that is an avoidable way to have a bad hour.
Common questions
Is an SRE interview harder than a DevOps interview? +
Not harder, but narrower and deeper in one direction. Both draw on the same operational pool; the SRE loop adds reasoning about systems under load and usually a design round that expects real numbers. If your background is operations rather than software engineering, the arithmetic and the failure-mode reasoning are where preparation pays off most.
Do I need to write code for an SRE interview? +
Often yes, but rarely algorithm puzzles. Reported coding rounds tend to be practical: parse a log file and extract something, write a small exporter, build a utility that other engineers would use. Some organisations run a genuine software-engineering track for SRE and others do not, which is exactly why it is worth asking which one you are in.
Which should I prepare if I have applied to both? +
Start with the shared operational ground — Kubernetes, Linux, networking, IaC, CI/CD — because it is most of both interviews. Then add the SRE reliability layer, since it is the material least likely to be covered by general preparation and the most likely to be the thing that differentiates you.
Are DORA metrics an SRE topic or a DevOps topic? +
Both, with different framing. DevOps interviews ask what they measure and how they are misused, typically as a management question. SRE interviews are more likely to move to SLOs and error budgets, which are a control rather than a report. Knowing the current DORA set matters either way — the metrics were revised, and "the four keys with MTTR" is now out of date.
Does Gnoseed have practice for both? +
Yes, and they are separate decks by design: the DevOps set covers delivery rationale plus the shared operational ground, and the SRE set covers the reliability layer on top. Both are free open-answer practice — you answer out loud, then compare against a model answer and a checklist.
Prepare the shared half first
Both sets are free and need no account. Start with whichever title you are interviewing for; the overlap means the second one takes far less time than the first.