DevOps and SRE Interview Preparation

What these interviews are looking for

DevOps and site reliability engineer interviews test a wide surface, but the thread running through all of it is operational maturity. Interviewers want to know whether you can build systems that deploy safely, stay up under load, and recover quickly when they break, and whether you treat reliability as a measurable target rather than a vague aspiration. Knowing the name of a tool is the easy part. Explaining when you would reach for it, what it costs, and what you would lose by using it is what separates strong candidates from people who have only read the documentation.

The rounds usually cover Linux and networking fundamentals, CI/CD and infrastructure as code, a reliability design discussion, and incident response. SRE loops lean harder on reliability theory like service level objectives and error budgets, while DevOps loops lean toward pipelines and release mechanics, but the overlap is large. Prepare across the whole surface rather than betting on one specialty.

The single biggest differentiator across every round is whether you reason from production experience or from theory. Interviewers can tell within two minutes which one they are talking to, because the person who has been paged at 3am talks about blast radius, rollback, and what they would check first, while the person who has only studied talks about features and happy paths.

What good versus weak looks like

It helps to know the shape of a strong answer before you walk in. The same question produces wildly different responses depending on operational maturity.

Solidify the fundamentals

A surprising number of candidates can write Terraform but stumble on what happens underneath. Interviewers probe the basics because production debugging depends on them. Be ready to walk through what happens when a request is slow: is it DNS, the load balancer, the application, the database, or the network in between, and how would you isolate each layer. The candidates who do well narrate a path, they do not list symptoms.

Know your way around a Linux box well enough to diagnose a problem live. How you would find what is consuming memory or CPU, how you would check open connections, how you would read logs and follow a process. Networking comes up too: the difference between latency and throughput, how a load balancer distributes traffic, and what a health check actually verifies. These questions reward someone who has actually debugged production rather than only read about it.

Here is the kind of muscle memory worth rehearsing. When a host is misbehaving, you should be able to talk through a triage sequence without hesitating.

top -o %CPU              # what is burning CPU right now
free -h                  # memory pressure and swap
df -h                    # disk full is a classic silent killer
ss -tunap | head         # open sockets and listening ports
journalctl -u myapp -f   # follow the service log live

The point is not to recite flags. It is to show that when something breaks you have a reflex for where to look first, and that you understand the order matters. You check the cheap, common causes before the exotic ones. A disk that is 100% full or a process stuck in uninterruptible sleep explains far more outages than a kernel bug.

CI/CD and infrastructure as code

Expect to design or critique a deployment pipeline. A common prompt is "walk me through how code gets from a pull request to production safely." Structure the answer around the stages and the safety at each one, and call out where a bad change gets caught.

• Build and test on every change, with the pipeline failing fast on a broken test, so a regression never reaches a human reviewer's attention as a surprise.
• Promote the same artifact through environments rather than rebuilding, so what you tested is what ships. Rebuilding per environment quietly reintroduces drift.
• Roll out gradually with a canary or blue-green deploy, watching metrics before sending all traffic, so a bad release degrades 1% of users rather than 100%.
• Keep a fast, automated rollback, because the question is not whether a bad deploy happens but how quickly you recover. A rollback that needs a manual approval and a 15 minute pipeline is not a rollback.

For infrastructure as code, be ready to talk about why you would manage infrastructure declaratively, how you handle state safely, and why you would never click changes into a console for anything that matters. HashiCorp's Terraform documentation is explicit that state locking is there to stop concurrent operations from corrupting shared state, which is exactly the risk to name in an interview (HashiCorp Terraform state locking). A short, clear snippet shows fluency.

resource "aws_autoscaling_group" "api" {
  min_size          = 2
  max_size          = 10
  desired_capacity  = 3
  health_check_type = "ELB"
}

The point to make is that this is version controlled, reviewed, and repeatable, so the environment can be rebuilt from scratch and there is no undocumented snowflake server. Push the conversation further if you can: explain that state is the dangerous part, that you keep it in a remote backend with locking so two engineers cannot corrupt it with a simultaneous apply, and that you separate state per environment so a mistake in staging cannot touch production.

Sample dialogue: critiquing a pipeline

Interviewers often hand you a flawed setup and ask what you would change. A good answer prioritizes and explains the risk, it does not just list improvements.

Interviewer: "Our pipeline builds a fresh Docker image in each environment, deploys straight to all production hosts at once, and rollback means re-running the old commit through the full build. What would you fix first?"

Candidate: "Three things, in priority order. First, the all-at-once production deploy is the highest risk, a bad change hits every user instantly, so I would add a canary or rolling deploy with a metric gate. Second, rebuilding per environment means you are not shipping what you tested, so I would build one artifact and promote it. Third, rollback through a full rebuild is too slow when you are mid-incident, so I would keep the previous artifact ready to redeploy in seconds. The deploy strategy is the one I would do first because it bounds the blast radius of every other mistake."

That answer works because it ranks the fixes by blast radius, names the failure each one prevents, and finishes with a one-line justification of the ordering. That is the structure to aim for on any "what would you improve" question.

Reliability and SRE concepts

SRE rounds dig into how you measure and protect reliability. Be precise about the vocabulary, because vague answers here are a clear tell. A service level indicator is the thing you measure, such as the share of requests served under three hundred milliseconds. A service level objective is the target for that indicator, such as 99.9% over a month. The error budget is what is left over, the small fraction of failures you are allowed. Google's SRE material frames SLOs as a tool for choosing what reliability promise is worth defending, not as decorative uptime language (Google SRE on service level objectives).

The reason error budgets matter is that they turn reliability into a shared, numeric decision. If you have burned the budget, you slow down and focus on stability. If you have budget to spare, you can ship faster. Framing reliability this way, as a tradeoff the whole team can see, is exactly the maturity SRE interviewers look for. It also reframes an argument that is usually political, product wants velocity and ops wants stability, into a number both sides agreed on in advance.

It helps to have the budget arithmetic in your head, because interviewers do ask you to convert an SLO into real downtime.

The lesson to voice out loud is that each extra nine costs more than the last, often an order of magnitude more in engineering effort, so you choose the target that matches what users actually need rather than reaching for 99.99% by reflex. A batch reporting system and a payments API do not deserve the same SLO.

Be ready to design for resilience: retries with backoff and jitter, circuit breakers so a failing dependency does not cascade, timeouts on every external call, and graceful degradation so a non-critical feature failing does not take down the core path. Name the failure modes before you are pushed. A subtle point worth raising is that naive retries make outages worse, because a struggling service gets hammered by a synchronized retry storm. That is why backoff and jitter matter, they spread the load instead of concentrating it.

You can also turn the SLO arithmetic into a practical judgement call. The strongest candidates do not only compute the budget, they say what they would do with the result.

function errorBudgetDecision({ slo, minutesInWindow, badMinutes }) {
  const allowedBadMinutes = Math.round(minutesInWindow * (1 - slo) * 10) / 10;
  const burn = Math.round((badMinutes / allowedBadMinutes) * 100);
  const action = burn >= 100 ? "freeze risky releases and repair reliability" : "keep releasing with tighter watch";
  return { allowedBadMinutes, burn: `${burn}%`, action };
}

errorBudgetDecision({ slo: 0.999, minutesInWindow: 30 * 24 * 60, badMinutes: 51 });
// { allowedBadMinutes: 43.2, burn: '118%', action: 'freeze risky releases and repair reliability' }

Incident response

Almost every loop includes an incident question, often "tell me about the worst outage you handled" or "a service is down, walk me through your response." The interviewer wants calm structure under pressure, not heroics. Google's SRE chapter on emergency response puts the first emphasis on a documented process and clear commands during an incident, while Atlassian's incident commander guidance makes the command role explicit (Google SRE emergency response, Atlassian incident commander).

Lead with stabilizing the system, not finding the root cause. The first job in an incident is to restore service, even with a temporary fix like a rollback or shifting traffic, and only then to investigate why. Describe how you would establish a clear incident commander, keep communication flowing to stakeholders, and avoid the trap of several people making uncoordinated changes at once. A useful framing is to separate the roles: someone runs the incident, someone communicates, someone does the hands-on debugging, and those are different jobs even if a small team means one person wears two hats.

A simple structure you can speak through under pressure:

1. Acknowledge and assess. Confirm the impact, who is affected, and how badly.
2. Stabilise. Restore service with the fastest safe lever, usually rollback or traffic shift, before you understand the cause.
3. Coordinate. Name an incident commander, open a single channel, stop uncoordinated changes.
4. Communicate. Tell stakeholders what is known, what you are doing, and when the next update lands.
5. Investigate and resolve. Once the bleeding has stopped, find and fix the real cause.
6. Learn. Run a blameless postmortem with concrete follow-ups.

After the incident, talk about the blameless postmortem. The goal is to find the systemic causes and the missing guardrails, not a person to blame. Mentioning concrete follow-ups, an alert that should have fired earlier, a missing automated rollback, a runbook that was out of date, shows you treat incidents as a source of improvement rather than something to move past quickly. The phrase that signals maturity here is that humans operating a confusing system is not a root cause, the confusing system is.

A worked incident answer

When asked to tell a real story, use a tight structure: situation, what you saw, what you did first, the resolution, and the lasting fix. Here is the shape of a strong answer.

"Invoice PDFs started failing after a library upgrade moved rendering work from the worker pool onto the API node. Error rate on invoice download rose to about 12%, and CPU saturation on two nodes hit the alert threshold. I declared an incident, named myself incident commander, and asked one engineer to roll traffic away from the hottest node while another pinned the renderer back to the previous image. Downloads recovered in six minutes. After that we found the real cause: the new renderer loaded fonts on every request and ignored the warm cache path. The lasting fixes were a canary that exercises PDF generation before broad rollout, a per-worker CPU saturation alert, and a runbook step that shifts document traffic without touching the billing API."

Notice what makes it land: it stabilized before investigating, it gave a number for impact, it named a concrete root cause, and the follow-ups were systemic guardrails rather than "be more careful." That last part is what interviewers are listening for. It is also distinct from a generic application bug story: the signal is saturation, traffic shifting, rollback scope, and a runbook that makes the same class of incident easier to handle next time.

Monitoring and observability

Reliability work depends on being able to see what the system is doing. Be ready to discuss the difference between metrics, logs, and traces, and when each helps. Metrics for trends and alerting, logs for the detail of a specific event, traces for following a request across services. A clean way to put it is that metrics tell you something is wrong, traces tell you where, and logs tell you why.

Talk about alerting on symptoms that users feel, like error rate and latency, rather than on every internal signal, because alert fatigue is a real failure mode. An on-call engineer who is woken by noise will eventually miss the alert that matters. Designing alerts that are actionable and tied to user impact is a strong, practical signal. If you can reference a structured approach, the four golden signals of latency, traffic, errors, and saturation, or the USE and RED methods, do so, but explain the idea rather than just dropping the acronym. Google's monitoring chapter names latency, traffic, errors, and saturation as the four core signals for a user-facing system (Google SRE monitoring distributed systems).

A practical test you can offer for any alert: would it wake someone up, and if it fired right now, is there a clear action to take. If the answer to either is no, it should be a dashboard or a ticket, not a page. That distinction between paging alerts and informational signals is something a lot of teams get wrong, and naming it shows you have lived with on-call.

Map your proof to the loop you are in

The same topics come up in different loops, but the interviewer is not always scoring the same evidence. A platform engineer may ask whether your deployment path is boring and reversible. An SRE may ask whether your reliability target changed engineering behavior. A hiring manager may ask whether people trusted you during an incident. Treat the loop as a set of risk checks, then choose the story that answers the risk instead of reciting your whole background.

This is where many otherwise strong candidates flatten their answer. They tell a detailed Kubernetes story in an incident round, or a heroic incident story in a pipeline-design round, and both miss the point. Before each answer, take five seconds to ask: "Are they testing safe operation, reversible change, reliability tradeoffs, or leadership under pressure?" Then lead with the proof that matches that test.

For a junior or mid-level role, the proof can be tight and local: you followed a runbook, found a disk filling up, rolled back cleanly, and asked for help at the right moment. For a senior role, the proof should include tradeoffs: you chose a deployment strategy, selected an SLO, or changed an alert so it paged on user impact rather than noise. For a staff-level platform or SRE role, the proof should outlive the incident: a golden path, a safer default, a better review check, or a reliability policy that other teams adopted.

Use the job description to weight your preparation. If it names developer experience, prepare a pipeline and self-service platform story. If it names on-call, SLOs, capacity, and production ownership, prepare the incident and error-budget stories. If it mentions regulated systems or customer commitments, be ready to talk about change windows, rollback evidence, audit trails, and how reliability promises differ by region or customer tier.

Common mistakes to avoid

• Naming tools without explaining when, why, or at what cost you would use them.
• Skipping straight to root cause in an incident answer instead of stabilizing first.
• Being vague about SLOs and error budgets, which signals you have not run a service to a target.
• Forgetting rollback. A deploy strategy with no fast way back is incomplete.
• Reaching for maximum reliability or the heaviest tooling by reflex, instead of matching effort to need.
• Blaming a person in a postmortem story, which tells the interviewer you have not internalised blameless culture.
• Listing improvements without prioritizing them. Ranking by blast radius is the signal.

Sources worth knowing before the interview

You do not need to quote these like scripture, but reading them sharpens the vocabulary interviewers expect:

• Google SRE on service level objectives for SLI, SLO, and error-budget framing.
• Google SRE on monitoring distributed systems for latency, traffic, errors, and saturation.
• Google SRE on emergency response for incident process and command structure.
• HashiCorp Terraform state locking for the shared-state risk behind infrastructure as code.
• Atlassian incident commander for the incident leadership role many teams expect.

FAQ

Do I need to memorize Kubernetes internals? Understand the concepts deeply, pods, services, deployments, how scheduling and health checks work, and be honest about hands-on depth. Reciting internals you have never used is easy to expose with one follow-up. Knowing when not to use Kubernetes is often a stronger signal than knowing its internals.

How much coding is in these loops? More than people expect. You should be comfortable scripting in Python or Bash, automating a task, and reasoning about a small program. Some SRE loops include a full coding round close to a software engineering interview.

What if I have not run a service with a formal SLO? Be honest, then reason from first principles. Define what you would measure, set a target, and explain how you would use the error budget. Demonstrating the thinking matters more than having the war story.

How do I handle a tool I have not used? Say so plainly, then map it to one you do know and reason about the tradeoffs. "I have not run Argo CD, but I understand GitOps, and the principle is that the desired state lives in git and a controller reconciles to it." Honesty plus transferable reasoning beats bluffing every time.

How to practice

Rehearse out loud. Walk through a deployment pipeline end to end, design an observability stack from scratch, define an SLO and error budget for a service, and talk through a real incident using the stabilize-then-investigate structure. After each, check that you justified your tool choices, named the failure modes before being pushed, prioritized your fixes by blast radius, and tied alerts to user impact. Record yourself once and listen back, the gaps are obvious when you hear them. That operational mindset, reliability as something you measure and defend, is what DevOps and SRE interviews are built to find.

Practice next

Apply the same operating mindset to the adjacent rounds:

• DevOps engineer interview questions
• System design interview prep for senior engineers
• Technical phone screen prep
• Live coding interview prep