AnyLearn
All interview prep
InfrastructureMid-levelSite Reliability Engineer

Site Reliability Engineer Interview Prep: Questions and a Mock Test

Site reliability engineering has an unusually well documented definition, because the team that named it published a book about it. That is a gift to anyone preparing: unlike most roles, the standard an SRE interview measures you against is written down and free to read. This page works through what the loop tests, where candidates lose points, and finishes with a graded mock covering the six areas the questions cluster around.

The loop

How the process is structured

The interview loop: each round, how long it runs, and what it tests
RoundLengthWhat it tests
1.Coding[1]Not publishedA genuine software engineering coding round, not a scripting exercise. This follows directly from how the discipline staffs itself: Google's SRE book describes hiring where "50-60% are Google Software Engineers" and the rest are "very close to the Google Software Engineering qualifications". Expect data structures, complexity reasoning and code you would be willing to review.
2.Systems and networking depth[1]Not publishedThe layer beneath the runtime. The two areas named as the most commonly sought alternate skills are "UNIX system internals and networking (Layer 1 to Layer 3)". In practice: processes and scheduling, memory and page cache, file descriptors, DNS, TCP behaviour under loss, and being able to say what a specific command would actually tell you.
3.Reliability design and SLOs[2]Not publishedDesigning a service and then defending its reliability targets. Expect to define an SLI for a given user journey, set an SLO without simply copying current performance, and explain what happens operationally when the error budget is exhausted.
4.Troubleshooting and incident behaviour[4]Not publishedA live debugging scenario plus incident stories from your own history. Assessed on whether you separate mitigation from diagnosis, and on whether your postmortem instinct is blameless in the specific sense of identifying "the contributing causes of the incident without indicting any individual or team".

Bracketed markers point to the dated sources at the end of this article. Loops change; check the retrieval dates before relying on a round count.

The bar is a software engineering bar

The single most common misread of this role is treating it as operations with a better title. Google's own account of how it staffs SRE says the opposite. Chapter 1 of Site Reliability Engineering describes hiring so that "50-60% are Google Software Engineers", with the remaining "40-50% are candidates who were very close to the Google Software Engineering qualifications" but who additionally bring depth the software track does not require. It names what that depth is: "UNIX system internals and networking (Layer 1 to Layer 3) expertise are the two most common types of alternate technical skills we seek."

Read that carefully, because it sets the shape of the loop. You are expected to pass a genuine coding round, not a shell scripting round. Data structures, complexity and clean decomposition are all in scope. What is added on top is systems depth: what a file descriptor is, what happens on a TCP retransmit, why a process is stuck in D state. Candidates who prepare only the systems half fail the coding round, and candidates who prepare only the coding half get found out the moment a question goes one layer below the runtime.

Why the 50 percent rule keeps appearing

The same chapter states a constraint that shapes almost every behavioural question in an SRE loop: "Google places a 50% cap on the aggregate 'ops' work for all SREs-tickets, on-call, manual tasks, etc." The stated reason is not comfort. It is that "without constant engineering, operations load increases and teams will need more people just to keep pace with the workload."

This matters in an interview because it tells you what a good answer to "how did you handle that outage" looks like. An answer that ends at restoring service is incomplete. The expected shape is: stabilise, then remove the class of work the incident created. If your story ends with a runbook, a reasonable follow-up is why the runbook was not code. Toil, in this vocabulary, is manual repetitive work that scales linearly with service size and produces no lasting value, and the ability to recognise it and argue for engineering it away is a large part of what separates a senior answer from a mid one.

Be ready for the inverse question too. Not all toil is worth automating, and saying so with a cost argument reads as judgement rather than dogma.

SLIs, SLOs and error budgets, precisely

Interviewers use these three terms as a quick competence filter, because they are so widely used loosely. The book's definitions are exact. A service level indicator is "a carefully defined quantitative measure of some aspect of the level of service that is provided". A service level objective is "a target value or range of values for a service level that is measured by an SLI". A service level agreement is "an explicit or implicit contract with your users that includes consequences of meeting (or missing) the SLOs they contain".

The consequences clause is the whole difference between an SLO and an SLA, and it is where sloppy answers get caught. An SLA has teeth, usually financial. An SLO is an internal target you can miss without a lawyer becoming involved.

Two pieces of stated guidance come up repeatedly. On how many indicators to pick: "Choosing too many indicators makes it hard to pay the right level of attention to the indicators that matter, while choosing too few may leave significant behaviors of your system unexamined." And on where to set the number: "Don't pick a target based on current performance", because doing so "may lock you into supporting a system that requires heroic efforts to meet its targets, and that cannot be improved without significant redesign".

The error budget, and why 100 percent is wrong

An error budget is the gap between your SLO and perfection, spent over a period. The book puts it plainly: "The difference between these two numbers is the 'budget' of how much 'unreliability' is remaining for the quarter." What makes it useful is not the arithmetic, it is the incentive: "The main benefit of an error budget is that it provides a common incentive that allows both product development and SRE to focus on finding the right balance between innovation and reliability."

The policy attached to it is what interviewers probe. When the budget is spent, "releases are temporarily halted while additional resources are invested in system testing and development to make the system more resilient". A candidate who describes an error budget purely as a reporting metric has missed the point; the number only does work if something happens when it runs out.

Expect a question aimed at the target itself. The stated position is that "100% is probably never the right reliability target: not only is it impossible to achieve, it's typically more reliability than a service's users want or notice". The argument to be able to make is economic. Each additional nine costs more than the last, and past some point the user's own network is the dominant term anyway, so the spend buys nothing anyone can perceive.

Incidents, postmortems, and the delivery metrics

Incident questions are behavioural in form and technical in substance. Interviewers listen for a structure: is there a clear incident commander, is communication separated from debugging, is mitigation separated from diagnosis. Restoring service first and finding the cause afterwards is the expected instinct, and candidates who insist on root cause before rollback tend to lose points.

On postmortems, the standard is blamelessness, defined narrowly rather than vaguely: "For a postmortem to be truly blameless, it must focus on identifying the contributing causes of the incident without indicting any individual or team for bad or inappropriate behavior." The reasoning is the quotable part: "You can't 'fix' people, but you can fix systems and processes to better support people making the right choices when designing and maintaining complex systems." Note that blameless does not mean no accountability; it means the accountability attaches to systems.

One currency check worth doing before an interview. DORA's guidance now presents five metrics, not four, and some names have changed: change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate. It also warns against treating them as standalone targets, which "encourages gaming the system", and against comparing them across teams with different contexts. Quoting the old four by their old names is a small, very visible staleness tell.

Open-ended

What they actually ask

  1. 1.A service currently runs at 99.95% availability. Product asks you to commit to an SLO. What do you commit to, and how do you decide?

    What a strong answer covers

    The trap is answering 99.95%. The stated guidance is "Don't pick a target based on current performance", because that locks you into defending whatever the system happens to do today. A strong answer starts from the user: which journey matters, what does failure look like from outside, and how much unreliability would users genuinely not notice. It then works back to a number, sets it below current performance if the current number is accidental, and defines the measurement window and the policy that fires when the budget is spent. Mentioning that the SLO is a decision-making instrument rather than a report is the senior signal.

  2. 2.Your error budget for the quarter is exhausted in week three. What actually changes?

    What a strong answer covers

    Something has to change or the budget was theatre. The documented consequence is that "releases are temporarily halted while additional resources are invested in system testing and development to make the system more resilient". A good answer describes the freeze, what is exempt from it (reliability fixes, security patches), who can override it and on what basis, and how the team spends the freed capacity. The best answers also handle the political reality: the point of agreeing the policy in advance is that nobody is negotiating it during the argument.

  3. 3.Walk me through an incident you were on call for. Start at the page.

    What a strong answer covers

    Interviewers are listening for structure rather than heroics. Strong answers name the signal that paged and whether it was the right signal, separate the person communicating from the people debugging, and mitigate before diagnosing. They quantify user impact rather than describing it. They end past the fix: what the postmortem found, what the contributing causes were, which action items shipped, and what class of work was removed rather than documented. Answers that end at "we restarted it and it came back" leave most of the assessment unanswered.

  4. 4.How would you tell whether a team is drowning in toil, and what would you do about it?

    What a strong answer covers

    Strong answers define toil precisely: manual, repetitive, automatable work that scales linearly with the service and creates no enduring value. They then reach for measurement rather than anecdote, ticket volume and on-call interrupt counts per week, and compare against the stated "50% cap on the aggregate 'ops' work". The interesting half is the judgement: not all toil should be automated, and the argument is a cost one comparing engineering time against recurring load and risk. Candidates who say every manual task must be automated are usually marked down for missing that.

  5. 5.You own a request path with a p50 of 40ms and a p99 of 3 seconds. Where do you look?

    What a strong answer covers

    The gap says the mean is hiding the problem, so the answer should reject averages immediately. Good candidates enumerate causes that produce a long tail specifically: queueing under bursty arrival, garbage collection or other stop-the-world pauses, cache misses hitting a slow path, lock contention, a slow dependency reached only sometimes, retries adding a full timeout to a fraction of requests, and single slow shards or hot keys. They reach for traces rather than more metrics, because the question is which requests are slow rather than how slow requests are, and they mention that percentiles do not compose across services, so a p99 built from per-service p99s is not the user's p99.

  6. 6.Design monitoring for a payment API you have just inherited. Nothing exists yet.

    What a strong answer covers

    The expected move is to start from user journeys and symptoms rather than from a list of machine metrics: is the request succeeding, is it fast enough, is money correct. From there, a small number of SLIs, because "choosing too many indicators makes it hard to pay the right level of attention to the indicators that matter". Strong answers distinguish paging alerts (symptom-based, actionable, someone must act now) from ticketing alerts and from dashboards, and explicitly rule out paging on causes such as CPU. Cost awareness is a good senior signal: high-cardinality labels are where observability bills come from, and tracing needs a sampling decision made deliberately.

Worked examples

Three sample questions, answered

These three show the level the mock is pitched at, with the answer and the reasoning in the open. The graded paper keeps its answer key server-side.

1.What is the defining difference between an SLO and an SLA?
SLOs and error budgets
  • An SLO is measured monthly, an SLA is measured quarterly
  • An SLO applies to internal services, an SLA applies to external ones
  • An SLA includes consequences for meeting or missing the target; an SLO is the target itself
  • An SLA is set by engineering, an SLO is set by the customer

Why: The definitions turn on consequences. An SLO is "a target value or range of values for a service level that is measured by an SLI". An SLA is "an explicit or implicit contract with your users that includes consequences of meeting (or missing) the SLOs they contain". Measurement period and audience vary case by case; the contractual consequence is the actual distinction.

2.During an ongoing outage with a known-bad deploy 20 minutes old, what should happen first?
Incident response and postmortems
  • Roll back the deploy, then investigate the cause
  • Reproduce the failure in staging so the cause is confirmed before acting
  • Write the postmortem doc while details are fresh
  • Page the author of the change to explain what they shipped

Why: Mitigation comes before diagnosis. Restoring service is the goal during an incident; understanding it is the goal afterwards. Insisting on confirming root cause before rolling back extends user impact for information that the postmortem can recover later. Paging the author to explain themselves mid-incident is also the behaviour blameless postmortem culture is designed to prevent.

3.A dashboard shows average request latency is 60ms and healthy. Users report the site is slow. What is the most likely explanation?
Metrics, logs and traces
  • The dashboard is querying the wrong service
  • Users are exaggerating a difference they cannot really perceive
  • The average is hiding a heavy tail that a percentile would expose
  • Latency is being measured in the wrong unit

Why: Averages conceal tail behaviour. A service can hold a 60ms mean while a meaningful slice of requests takes seconds, and users experience the slow requests rather than the arithmetic. This is why reliability targets are expressed at percentiles such as p95 or p99 rather than as means.

The mock

An 18-question knowledge check

This is a knowledge check, not a simulation. The real loop happens on a whiteboard, in an editor, and in conversation. What this paper does measure is the underlying knowledge those rounds draw on: each question is tagged with a topic, grading happens per topic, and a weak topic points you at the course that fixes it.

Your paper0 / 18 answered
  1. 1.Which of these is a service level indicator rather than a service level objective?
    SLOs and error budgets
  2. 2.Why is setting an SLO equal to the service's current measured performance considered a mistake?
    SLOs and error budgets
  3. 3.A service has a 99.9% availability SLO measured over 30 days. Roughly how much unavailability does that permit?
    SLOs and error budgets
  4. 4.Which alert is best suited to paging a human at 3am?
    Metrics, logs and traces
  5. 5.Why can you not compute a system's true p99 latency by averaging the p99s of its component services?
    Metrics, logs and traces
  6. 6.Your observability bill has tripled after a release that added a userId label to a core metric. What happened?
    Metrics, logs and traces
  7. 7.In the sense used by Google's postmortem guidance, what does a blameless postmortem require?
    Incident response and postmortems
  8. 8.Which of these is listed as a trigger for writing a postmortem?
    Incident response and postmortems
  9. 9.What is the clearest sign that an incident response process is working during a major outage?
    Incident response and postmortems
  10. 10.Adding a retry to every failed call to a struggling downstream service most often produces which outcome?
    Failure modes in distributed systems
  11. 11.Under the CAP theorem, what does a network partition actually force you to choose between?
    Failure modes in distributed systems
  12. 12.A client times out after 2 seconds and reports failure. The server completed the write at 2.1 seconds. What is the correct characterisation?
    Failure modes in distributed systems
  13. 13.What does a canary release primarily buy you compared with deploying to all instances at once?
    Safe deploys and rollback
  14. 14.Which change is genuinely hard to roll back, and therefore needs a different strategy?
    Safe deploys and rollback
  15. 15.DORA's current guidance on its delivery metrics warns most strongly against which practice?
    Safe deploys and rollback
  16. 16.A read-heavy service is CPU-bound on identical database queries. Which change addresses the cause most directly?
    Scaling, caching and load balancing
  17. 17.Sharding a table by a monotonically increasing timestamp most commonly causes which problem?
    Scaling, caching and load balancing
  18. 18.What does adding a queue between a web tier and a slow downstream worker actually change?
    Scaling, caching and load balancing
18 questions left to answer.
Apparatus

Sources

Hiring loops change. Every claim above carries a retrieval date so you can judge how current it is.

  1. [1]Google, Site Reliability Engineering, Chapter 1: Introduction · retrieved 2026-08-13
  2. [2]Google, Site Reliability Engineering, Chapter 4: Service Level Objectives · retrieved 2026-08-13
  3. [3]Google, Site Reliability Engineering, Chapter 3: Embracing Risk · retrieved 2026-08-13
  4. [4]Google, Site Reliability Engineering, Chapter 15: Postmortem Culture · retrieved 2026-08-13
  5. [5]DORA, Software delivery metrics: the four keys · retrieved 2026-08-13
Keep preparing

Refresh your memory

Free learning paths covering the ground this loop tests, whatever your score. Each one ends with a shareable certificate.