The DevOps/SRE Interview

"Hope is not a strategy. Everything eventually fails, so plan for it — and interview for the person who already has." — the SRE mindset, distilled

You have spent this entire volume learning to run software: to package it into containers, ship it through pipelines, schedule it on Kubernetes, provision the cloud beneath it as code, watch it with metrics and traces, and defend it. Now we turn that knowledge toward a specific, high-stakes conversation — the one across a table (or a video call) where someone decides whether to hand you the pager for a system real people depend on. This Part is about the DevOps, SRE, and Platform interview: what it actually tests, why it feels different from the backend interviews you may have prepared for, and how to walk in ready.

Here is the reframe that changes everything. A backend interview mostly asks can you build it? A DevOps or SRE interview asks can you build it, deploy it, run it at 3 a.m., observe it, secure it, and keep it up when it — inevitably — breaks? The center of gravity shifts from write to operate. Interviewers stop being satisfied by working code and start probing the edges: what happens under load, on failure, during a bad deploy, when the database is slow and the pager is screaming. This chapter orients you to that whole gauntlet before the deep-dive chapters that follow arm you for each round.

And the demand is real. DevOps, SRE, and Platform Engineering are among the best-compensated, most sought-after tracks in the industry, and even "pure" backend and full-stack loops now routinely wander into "how would you deploy this?" and "what do you do when it goes down?". Whether you're aiming for an ops title or just want to stop losing points on the operational half of every interview, this Part is your map.

What the role actually does (so you know what they test)

Titles blur across companies, but the shape of the work is consistent, and the interview mirrors the work. A DevOps/SRE/Platform engineer is the person who owns the build → ship → run layer:

• Automate the path to production — CI/CD pipelines so a merge becomes a safe deploy with no human hand-offs.
• Operate the runtime — containers and orchestration (Kubernetes), autoscaling, rollouts, rollbacks.
• Provision infrastructure as code — cloud resources defined in Terraform/CloudFormation, versioned and reviewable.
• Make systems observable and reliable — metrics, logs, traces, SLOs, alerting, on-call, incident response, postmortems.
• Reduce toil and pave roads — build the platform and tooling that lets product teams ship themselves, safely.
• Debug live — when the site is slow or down, be the person who methodically finds and fixes it under pressure.

Because that is the job, the interview tries to simulate slices of it. Nobody asks you to reverse a binary tree to prove you can carry a pager; they hand you a slow server, a broken pipeline, a flaky deploy, or a reliability target and watch how you think.

The interview loop: the rounds you'll face

A DevOps/SRE loop is usually a mix of the rounds below. You rarely get all of them in one company, but across a few interview cycles you'll meet every one. Here is the topic map, then the detail.

The round types, and what each one is really assessing

The mindset interviewers are probing

Underneath every round, interviewers are testing for a way of thinking more than a stack of facts. Four mental habits recur, and naming them for yourself will change how you answer:

• Operational thinking — "what happens when it fails?" For every design you propose, they'll ask the follow-up: at 3 a.m., under 10x load, when a node dies, when the network partitions, when the deploy is half-rolled-out. Senior candidates volunteer the failure modes before being asked. Assume failure is normal, not exceptional.
• Automation-first. If a human does it twice, it should be scripted. When you catch yourself describing a manual step ("then someone SSHes in and restarts it"), that's a flag — the better answer automates it, or explains why it can't be. Toil is the enemy.
• Measure, don't guess. Reach for data — a metric, a log, a trace, a benchmark — before opinion. "I'd check the p99 latency and error rate" beats "it's probably the database." Instrument first; conclude second.
• Ownership. You build it, you run it. The answer that ends "…and I'd own the rollback and write the postmortem" lands differently from one that ends "…and then it's ops's problem." There is no wall to throw things over.

How this differs from a pure backend interview

The overlap with backend is real — you must still know HTTP, databases, concurrency, and data structures. But the emphasis moves, and knowing where it moves lets you spend your prep wisely.

The takeaway isn't that backend prep is wasted — it's that you must extend it. Every design answer should grow an operational tail: how it deploys, how it scales, how you'd know it's healthy, and how you'd recover it. That tail is the difference between a backend answer and an SRE answer.

The SRE flavor: reliability as a math problem

Site Reliability Engineering — Google's implementation of DevOps — adds a distinctive quantitative layer that shows up hard in interviews. Three ideas do most of the work.

SLI / SLO / SLA. A Service Level Indicator is a measurement (e.g. the fraction of requests served in under 200 ms). A Service Level Objective is your internal target for it (e.g. 99.9% of requests succeed over 30 days). A Service Level Agreement is the external, contractual promise (usually looser than the SLO, with penalties). Interviewers want you to define a good SLI — one that tracks user happiness, measured at the right place — and set a realistic SLO.

Error budgets. This is the idea that makes SREs sound different from everyone else. If your SLO is 99.9% success, then 0.1% is your error budget — a permitted amount of unreliability, and a currency you can spend. Budget left over? Ship faster, take more risk. Budget exhausted? Freeze risky changes and pour effort into reliability. It's the mechanism that finally aligns dev (who want to ship) and ops (who want stability): they're now spending from the same account.

The budget is concrete, and being able to compute it live is a strong signal:

Reduce toil. Toil is manual, repetitive, automatable operational work that scales with traffic and produces no lasting value — restarting a service by hand, copying config, clicking through a runbook. SRE culture caps toil (Google famously targets under 50% of an SRE's time) and spends the rest engineering it away. In interviews, spotting toil in a scenario and proposing to automate it is a reliable way to sound senior.

How to prepare

This is a hands-on discipline, and it rewards hands-on prep. Reading about Kubernetes is worth a fraction of running it and breaking it. A concrete plan:

• Build the real thing, end to end. Take a small app and carry it all the way: write a Dockerfile, wire a CI/CD pipeline (GitHub Actions is free and enough), deploy it to a local Kubernetes (kind, minikube, or Docker Desktop), put a metric and a dashboard on it. The muscle memory of having done it is what makes your answers specific instead of vague.
• Break things on purpose. Kill a pod and watch it reschedule. Push a bad image and practice the rollback. Fill a disk. Max out CPU with a stress tool and debug it with top. Interviewers can hear the difference between someone who has seen a CrashLoopBackOff and someone who has only read about one.
• Know the fundamentals cold. Linux (processes, memory, filesystems, networking, the top/ss/strace toolkit), TCP/TLS/HTTP/DNS, and how a request physically travels from a browser to your code. These are the rounds you cannot bluff, and they're the ones that separate levels.
• Sharpen practical scripting. Be fluent parsing logs and automating chores in Bash and Python (and read Go — it's the language of cloud-native tooling). Practice: "given this access log, report the top 10 IPs by error count." That's a real DevOps coding question.
• Rehearse the reliability vocabulary. Be able to define an SLI, set an SLO, compute an error budget, and name the golden signals (latency, traffic, errors, saturation) without hesitating.
• Prepare incident STAR stories. Have two or three crisp on-call/incident narratives ready — Situation, Task, Action, Result — emphasizing calm, method, ownership, and a blameless postmortem. This is where the behavioral round lives; the Behavioral, Vol 6 frameworks apply directly, just pointed at outages and cross-team friction instead of feature work.

Common Mistakes

• Preparing like it's a backend interview. Grinding only algorithms and skipping Linux, networking, and the deploy/observe/recover half leaves you silent in exactly the rounds that define the role. Extend your prep; don't just reuse it.
• Reciting tools instead of reasoning. Naming Kubernetes, Terraform, and Prometheus proves nothing. Interviewers probe the why and the what-happens-when-it-fails. Concepts first, tools as illustration.
• Jumping to a fix in the live-debug round. Guessing "restart it" or "it's the database" before forming and testing a hypothesis reads as luck, not skill. Narrate a method: confirm the symptom, scope it, walk the layers, test one hypothesis at a time.
• Ignoring the operational tail in system design. A design that never mentions how it deploys, scales, is monitored, or recovers is a backend answer in an ops round. Always grow the tail.
• Chasing 100% reliability. Insisting nothing should ever fail signals you don't understand error budgets or cost. The senior answer picks a realistic SLO and spends the budget deliberately.
• Behavioral stories with blame. "The dev team pushed bad code and I had to clean it up" fails the culture check. Frame incidents blamelessly, with shared ownership and a systemic fix.

Summary

• A DevOps/SRE interview tests build → ship → run, not just build: the center of gravity moves from writing code to deploying, operating, observing, securing, and recovering it.
• The loop is broad — Linux/systems, live troubleshooting, CI/CD, containers/Kubernetes, cloud/IaC, networking, observability/SRE, practical scripting, an ops-slanted system-design round, and behavioral on-call stories.
• Interviewers probe a mindset: operational thinking ("what happens when it fails?"), automation-first, measure-don't-guess, and end-to-end ownership.
• The SRE layer is quantitative — SLI/SLO/SLA, error budgets (the currency that aligns dev and ops), the golden signals, and reducing toil. Being able to compute an error budget live is a strong signal.
• Prepare hands-on: build a real pipeline, run Kubernetes locally, break things on purpose, know Linux and networking cold, sharpen log-parsing scripts, and rehearse blameless incident STAR stories (cross-ref Behavioral, Vol 6).

Next, we go straight into the round most likely to open your loop and most rewarding to master — designing a CI/CD pipeline from commit to production, safely — the deep dive behind the "design a pipeline" prompt you just met.