SRE vs DevOps Engineer: Which Interviews Should You Prepare For?

Site reliability engineering and DevOps overlap because both try to make software delivery and operation safer through engineering, automation, feedback, and shared responsibility. They are not cleanly separated professions. DevOps is commonly used for a broad approach to collaboration and delivery; SRE is a more concrete set of reliability practices and often a job role.

For interview preparation, read the operating contract behind the title. A role that owns service-level objectives, production incidents, and on-call escalation calls for different evidence from a role that builds deployment workflows, infrastructure platforms, and reusable delivery controls.

If your answer cannot connect an SLO, an error budget, an alert, and an engineering change, that is a specific preparation gap.

SRE and DevOps are related at different levels

Official perspective: Google’s SRE Workbook describes DevOps as a broad set of principles around whole-lifecycle collaboration and describes SRE as a role, practices, and beliefs that implement parts of that philosophy. Its memorable programming analogy is that SRE implements the DevOps interface. This is Google’s framing, not an industry law. Google: How SRE Relates to DevOps.

Google’s original SRE description emphasizes using software engineering to perform and automate operational work. It lists availability, latency, performance, efficiency, change management, monitoring, emergency response, and capacity planning among SRE responsibilities. Google also documents its own cap on operational work; candidates should not assume another employer uses the same percentage or team model. Google SRE Book introduction.

In practice, a “DevOps engineer” job may look like platform engineering, infrastructure automation, CI/CD ownership, cloud operations, or a blend. An SRE job may include platform work too. The interview signal comes from verbs such as define SLOs, join on-call, automate releases, build paved roads, manage infrastructure, reduce toil, or lead incident reviews.

Compare the failure each role is hired to reduce

Consider a checkout service with a deployment pipeline and a production SLO. One risky release can expose both sides of the work.

The delivery-focused problem is that releases are slow and inconsistent. Teams copy deployment configuration, secrets checks happen late, rollback steps are manual, and nobody knows whether a change passed the same controls as the previous one. A DevOps or platform-oriented engineer may be expected to build a reusable path from reviewed change to production.

The reliability-focused problem is that customers receive errors after the release. An SRE may be expected to determine user impact, stop error-budget consumption, coordinate mitigation, and change the system so the same failure is detected and contained earlier.

These responsibilities belong to one lifecycle. A safer pipeline reduces incidents; incident evidence should improve the pipeline. Organizational ownership may sit with one team, two teams, or product engineers. Do not present the comparison as a wall between delivery and operations.

Work a 99.9% reliability example

This is an original simplified exercise, not production evidence or an employer question.

Assume the checkout service has a 99.9% successful-request SLO over 30 days. For a simplified window containing 1,000,000 equally weighted requests, the allowed unsuccessful portion is 0.1%, or 1,000 requests. That is the window’s error budget under this definition.

A new release causes 50,000 requests in five minutes, and 2% fail. That creates 1,000 failed requests. Those five minutes consume the entire simplified 30-day budget. The arithmetic does not by itself tell you why requests failed, whether the SLO definition is appropriate, or whether every request has equal business impact. It tells you why the signal deserves urgent investigation.

A strong incident answer separates detection, mitigation, and diagnosis. Confirm customer impact and the affected path. Pause or roll back the change if evidence supports it. Compare good and bad versions, protect the system from further damage, and communicate current impact. Preserve a timeline and hypotheses for later analysis rather than experimenting recklessly during mitigation.

Official technical guidance: Google’s SRE Workbook explains burn rate as the speed at which a service consumes its error budget and shows how alert windows trade off detection, precision, and reset behavior. It also warns that low-traffic services need special care because a small number of failures can create extreme ratios. Google: Alerting on SLOs.

Do not memorize one threshold as universal. In an interview, state the SLO window, the event definition, the traffic assumptions, and the user consequence before calculating.

SRE interview preparation: reliability ownership

The following is preparation inference. A role emphasizing SLOs and on-call is likely to test whether you can reason from symptoms to user impact, operate under uncertainty, and design away recurring manual work.

Practice Linux and systems fundamentals deeply enough to form and test hypotheses. Know what CPU saturation, memory pressure, disk latency, connection exhaustion, queue growth, and dependency timeouts can look like. Avoid treating a metric name as a diagnosis; relate it to a request path and collect evidence.

Practice distributed-systems failure modes: retries, timeouts, partial failure, load shedding, caching, replication, and backpressure. Explain how a retry can improve transient reliability and also amplify an overloaded dependency.

For incident stories, distinguish what you observed, what you personally changed, and what the team decided. A good narrative includes impact, timeline, mitigation, contributing conditions, follow-up ownership, and a check that the corrective action worked. Do not claim an on-call incident you did not handle. A local fault-injection exercise is valid when labeled accurately.

For design, define service-level indicators before drawing an alerting stack. An alert should prompt a useful human action. Explain which conditions page immediately, which create a ticket, and which belong on a dashboard.

DevOps interview preparation: delivery enablement

A role emphasizing CI/CD, infrastructure as code, and developer platforms is likely to test how you make delivery repeatable without hiding risk.

Practice a release path from commit to production: build a reproducible artifact, test it, scan it, promote the same artifact, apply environment-specific configuration safely, deploy gradually, observe health, and roll back or roll forward. State where credentials live and how access is limited.

Understand infrastructure state, drift, plan review, dependency ordering, and recovery after a partial change. “Everything is automated” is not enough. Explain the control that stops a destructive change and the evidence that a rollout is healthy.

Current DORA guidance identifies five software delivery performance metrics: change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate. DORA groups them around throughput and instability and advises applying them in the context of one application or service. They are improvement signals, not individual performance quotas. DORA software delivery performance metrics.

Be ready to connect delivery design to developer experience. A platform should make the safe path understandable and usable. If every exception requires a ticket to your team, the workflow may be automated without being self-service.

A release-safety exercise with observable results

Build this local preparation exercise without claiming a production environment. A small web service has versions v1 and v2. Version v2 deliberately returns errors for one test route.

Create a pipeline that runs unit tests, builds one immutable artifact, records its version, and deploys to a local or disposable environment. Add a smoke test for the healthy route and the deliberately broken route. The deployment of v2 should fail its health gate and preserve or restore v1.

Now approach it from the SRE side. Define a simple successful-request indicator and a target for the exercise. Generate known traffic, calculate the failure ratio, and show which condition would trigger a page. Add a short runbook containing impact check, rollback command, owner, and validation step.

The DevOps evidence is the consistent artifact and gated promotion path. The SRE evidence is the user-centered signal, mitigation logic, and learning loop. The shared evidence is that a known-bad version does not remain serving traffic.

Five questions to practice

Question	What to demonstrate
Explain Core SRE Practices	Connect SLOs, error budgets, toil reduction, and operational ownership.
How to triage slow service alerts	Move from user impact to bounded hypotheses and evidence.
Handle On-Call Incidents	Prioritize mitigation, communication, and safe investigation.
Design Safe Configuration and Deployment for Hundreds of Services	Explain rollout controls, reuse, blast radius, and recovery.
Explain Your Role in a Production Incident	Separate personal evidence from team outcomes and later learning.

Read the job description as an operating contract

Choose SRE-focused preparation when the role explicitly owns production services, SLOs, alerting, on-call response, capacity, and reliability engineering. Ask which services the team supports, whether product engineers share on-call, how toil is measured, and what authority exists when reliability risk rises.

Choose DevOps or platform-focused preparation when the role emphasizes deployment systems, infrastructure modules, environment consistency, developer workflows, and delivery governance. Ask who the platform users are, how success is measured, which parts are self-service, and who responds when the platform itself fails.

If the description lists every cloud tool but says little about outcomes, ask for a recent project and incident. “Maintained Kubernetes” is less informative than “reduced risky manual releases” or “owned availability for this service.” The interview you prepare for should follow that concrete responsibility.

Some openings combine both. In that case, prepare two stories: one about making change safer and one about restoring or protecting a user-facing service. Use the same release exercise to keep the connection between them clear.

Avoid four common interview mistakes

First, do not start with a vendor stack before defining the problem. Kubernetes, Terraform, Prometheus, and a hosted CI service can be reasonable choices, but naming them does not establish availability, safe change, or useful feedback. Define the user-facing risk and operating constraint first.

Second, do not confuse monitoring with paging. A team can retain many useful signals without waking someone for each one. Explain the human action that a page requests and the consequence of waiting until business hours.

Third, do not present rollback as a complete incident strategy. Rollback can fail, database changes can be incompatible, and the triggering change may be unrelated. State the evidence that makes rollback appropriate, the safer alternative when it is not, and the validation after mitigation.

Fourth, do not describe automation only by time saved. A release workflow also standardizes evidence, access, review, and recovery. A reliability project should reduce a specific failure mode or operational burden. Quantify only results you measured, and preserve the baseline and method so an interviewer can assess the claim.

Choose your next preparation step

If the error-budget example felt natural, expand it. Define a better indicator, add latency, consider low traffic, and practice How to triage slow service alerts. If the release path held your attention, add policy checks, staged rollout, artifact provenance, and a recovery test.

Do not choose solely from the title or the number of tools you recognize. Choose the operating contract you want to carry: protecting a service’s reliability, enabling teams to deliver safely, or a clearly defined blend. Then build evidence that survives the most useful interview follow-up: “How do you know it worked?”

Sources and Further Reading

• Google SRE Workbook: How SRE Relates to DevOps
• Google SRE Book: Introduction
• Google SRE Workbook: Alerting on SLOs
• DORA: Software delivery performance metrics