Site reliability engineer interview questions, with worked answers

How to use these questions

Answer with a real service: its users, its target, the worst incident you saw, what you measured and what you changed so it would not happen again. Interviewers listen for numbers and for the reasoning behind a trade-off, not for tool names.

What a site reliability engineer is expected to know

• Targets: service level objectives and indicators for availability and latency, error budgets, and how they steer release decisions.
• Observability: metrics, logs and traces with PrometheusAsked in 25% of site reliability engineer ads (as of 5 Nov 2026).Metrics and alert rules that follow what users feel; Grafana dashboards on top are counted here too. or another tool, alerts on user impact, and dashboards that answer questions.
• Operations: LinuxAsked in 67% of site reliability engineer ads (as of 5 Nov 2026).Read a struggling server from the shell: processes, memory, disks, the network and the kernel's own logs., KubernetesAsked in 33% of site reliability engineer ads (as of 5 Nov 2026).Run production clusters: scheduling, health checks, autoscaling, upgrades and what fails when a node dies., networks, capacity and load on AWSAsked in 25% of site reliability engineer ads (as of 5 Nov 2026).Regions and zones, load balancers, managed databases and the limits that bite during an incident. depends on the provider, AzureAsked in 33% of site reliability engineer ads (as of 5 Nov 2026).Regions and zones, the managed services teams use, and the provider's own health and monitoring tools. depends on the provider or Google CloudAsked in 17% of site reliability engineer ads (as of 5 Nov 2026).Regions and zones, managed Kubernetes and the provider's monitoring and logging. depends on the provider.
• Change and automation: safe releases through CI/CDAsked in 67% of site reliability engineer ads (as of 5 Nov 2026).Pipelines with safe releases built in: gradual roll-outs, automatic checks and a quick way back., rollback, runbooks, and code in PythonAsked in 67% of site reliability engineer ads (as of 5 Nov 2026).Tools that remove repeated work: checks, clean-ups, reports and small services that fix things on their own. or GoMany reliability tools and operators are written in Go; read them and write small services in it. that removes manual work.
• People: incident managementAsked in 25% of site reliability engineer ads (as of 5 Nov 2026).Lead an incident: roles, updates, a timeline, the way back to service, and the review afterwards., on-call and blameless reviews.

Targets, error budgets and what to measure

What is an SLO, and how do you choose the SLIs for a service?

What they check: that targets start from users, not from what is easy to measure.

Short answer: "A service level indicator is a measure of what users feel, such as the share of requests that succeed or that answer within a set time. A service level objective is the target for it over a window, for example that 99.9 percent of requests succeed over thirty days. A service level agreement is the promise to a customer, with consequences, and is set looser than the SLO."

The full answer: Choose a few indicators per service along the user's path: can they log in, can they pay, how long does a search take. Measure as close to the user as you can, at the load balancer or in the client. Set the target from what users and the business need, not at perfection, because every extra nine costs much more than the last.

A weak answer: "Our SLO is one hundred percent uptime." Follow-up: "Servers are fine but users complain." Explain why the indicator should be measured from the user's side.

What is an error budget, and what does the team do when it runs out?

What they check: that you can use the budget to balance speed and reliability, with agreement.

Short answer: "The error budget is the unreliability the SLO allows: with a 99.9 percent target, the one-in-a-thousand that may fail. While budget is left, the team releases freely. When it runs out, the agreed policy starts: risky releases pause and the team works on reliability until the service is back within target."

The full answer: The policy must be agreed before it is needed, by the product owner and engineering, or it turns into a fight during the first freeze. Look at what used the budget: one large incident needs a fix, many small failures may need a better release process. A budget that is never used can mean the target is too strict and the team too slow.

A weak answer: "The SRE team blocks all releases." Follow-up: "The product owner wants one more feature out during the freeze." Explain who decides and on what data.

How do you measure latency, and why can an average mislead?

What they check: percentiles, and that slow requests matter even when they are few.

Short answer: "I measure latency as percentiles, such as the 95th and 99th, over successful and failed requests apart. An average hides the slow tail: if most requests are fast and a few take ten seconds, the average looks fine while some users wait. A slow error and a fast error also mean different things."

The full answer: A page often makes many calls, so a slow tail on one service reaches most users. Keep the measurement close to the user and look at it per region and per kind of request. Set the latency target in the same way as the success target, with its own window.

A weak answer: "Average response time is under two hundred milliseconds, so we are fine." Follow-up: "The 99th percentile doubled after a release." Explain how you would find which requests got slower.

Observability, alerts, on-call and incidents

How do you build observability for a service: metrics, logs and traces?

What they check: that you can answer a new question about a system without shipping new code.

Short answer: "Metrics show the shape over time, such as request rate, errors, latency and saturation; logs tell what happened in one request; traces follow a request across services. I connect them with shared request IDs, so a spike on a dashboard leads to the traces and logs behind it."

The full answer: The tools are named side by side in most companies: Prometheus with Grafana, Datadog, Dynatrace, New Relic, Splunk, or the cloud's own, often collected with OpenTelemetry so the choice can change later. Watch the cost, because logs and high-detail metrics grow fast; keep what answers questions and drop the rest. Observability is also a habit: teams add the signals when they build a feature.

A weak answer: "We log everything and search when something breaks." Follow-up: "The monitoring bill rose sharply." Explain what you would keep, sample or drop.

What makes a good alert, and how do you cut alert noise for the on-call engineer?

What they check: alerts tied to user impact and to an action, and care for the people on call.

Short answer: "A good alert means users are hurt or soon will be, and someone must act now. I alert on the error budget burning too fast rather than on CPU, send everything that can wait to a ticket, and give each alert an owner and a runbook. Every alert that woke someone for nothing is fixed or deleted."

The full answer: Count the pages per shift and review them weekly; a rota where people are woken often burns out. Alert on symptoms users feel, and keep cause dashboards for the investigation. A fair on-call has enough people, handovers, and rest after a night call.

A weak answer: "More alerts are safer." Follow-up: "Last week's on-call had forty pages." Explain how you would sort and cut them.

A major outage starts. Walk us through how you run the incident.

What they check: roles, calm order and restoring service before finding the cause.

Short answer: "I declare the incident, name an incident lead, someone on communication and the people doing the fixing, and open one channel and a timeline. First we restore service, often by rolling back the last change or moving traffic, then we look for the cause. Updates go out on a fixed rhythm, even when there is nothing new."

The full answer: Check what changed first: releases, configuration, traffic, the provider's status. Avoid several people changing things at once. Measure time to detect and time to restore, because they show where the process can improve. Close the incident when users are fine, not when the cause is known.

A weak answer: "Everyone jumps in and fixes what they can." Follow-up: "The rollback does not help." Explain what you would try next and who you would call.

How do you write a blameless postmortem that actually leads to change?

What they check: learning from failure without blame, and actions that get done.

Short answer: "A blameless postmortem describes what happened, the impact, the timeline, what helped and what got in the way, and why the actions made sense to people at the time. It ends with a few actions, each with an owner and a date, tracked like any other work."

The full answer: Blame teaches people to hide mistakes, so the review asks how the system allowed the error, not who made it. Look for several causes, not one root. Share the review widely, and check after a month whether the actions are done; a postmortem with open actions is a warning.

A weak answer: "The engineer who made the change gets more training." Follow-up: "The same incident happens again." Explain how you would check the earlier actions.

Toil, automation, capacity and safe change

When is a runbook enough, and when should it become automation?

What they check: that you write runbooks and know when to replace them with code.

Short answer: "A runbook is a written procedure for a known problem, so anyone on call can act. When the same runbook is followed often, its steps never change and they are safe to run without judgement, I turn it into automation, first as a tool a person starts, then as a fix that runs on its own with a check."

The full answer: Automation that fails quietly is worse than a runbook, so it needs logging, limits and a way to stop it. Keep the runbook for the cases the automation does not cover. Measure how often each runbook is used; that list is your automation backlog.

A weak answer: "We automate everything from the start." Follow-up: "The automatic fix restarted the whole cluster." Explain the limits you would build in.

What is toil, and how do you reduce it?

What they check: that you can name repeated manual work and make room to remove it.

Short answer: "Toil is manual, repeated work that grows with the service and leaves no lasting value: restarting a service by hand, handing out access, clearing disks. SRE teams cap it, often at half of their time, and spend the rest on engineering that removes it."

The full answer: Measure toil for a few weeks: what, how often, how long. Then remove the biggest items through automation, self-service or a fix in the product. Some toil moves back to the team that causes it. If toil keeps rising, it is a staffing or design problem to raise with leadership.

A weak answer: "Toil is just part of operations." Follow-up: "The team has no time to automate." Explain how you would make the case and win the time.

How do you plan capacity and test load before a big peak?

What they check: forecasting, load tests and headroom, with the cost in view.

Short answer: "I start from the forecast of the business, translate it into requests per second per service, and run load tests in a production-like setup to find where each part breaks. Then I add headroom, check quotas and limits with the cloud provider, and plan what to switch off if load goes past the plan."

The full answer: The bottleneck is often not where expected: a database connection limit, a third-party service, a quota. Autoscaling helps but has delays and limits of its own. After the peak, compare the forecast with what happened and scale back down, because spare capacity costs money every hour.

A weak answer: "Autoscaling will handle it." Follow-up: "Traffic is triple the forecast." Explain how the service degrades gracefully.

How do you release changes safely: canary, feature flags and rollback?

What they check: a release process that limits the damage of a bad change.

Short answer: "A canary release sends a small share of traffic to the new version and compares its errors and latency with the old one; if they look worse, the release stops and rolls back automatically. Feature flags separate shipping code from switching a feature on. Every release must be easy to undo, including database changes."

The full answer: Most incidents follow a change, so this is where SRE work pays most. Roll out region by region, keep releases small and frequent, and avoid releasing at the end of the day before a weekend. Database changes are made in steps that the old and the new version both accept, so rollback stays possible.

A weak answer: "We test well, so we release to everyone at once." Follow-up: "The canary looks fine but one customer is broken." Discuss what your checks missed.

How would you run chaos engineering safely in production?

What they check: controlled experiments with a clear hypothesis and a stop button.

Short answer: "Chaos engineering means causing failures on purpose to learn how the system behaves: stopping a server, adding delay to a dependency, cutting a zone. I start in a test setup with a written hypothesis, a small blast radius and a way to stop at once, and move to production only when the basics hold, at a quiet hour, with the team watching."

The full answer: Each experiment should end in a learning: an alert that did not fire, a timeout that was too long, a runbook that was wrong. Game days, where the team practises an incident together, are a gentler start and train people as well as systems.

A weak answer: "We switch servers off at random to see what happens." Follow-up: "The experiment caused a real outage." Explain what your stop rule should have been.

A dependency your service relies on becomes slow. How do you protect your service?

What they check: timeouts, retries, circuit breakers and graceful degradation.

Short answer: "Every call to a dependency gets a timeout shorter than my own target, a limited number of retries with growing waits, and a circuit breaker that stops calling a dependency that keeps failing. Where possible the service degrades gracefully, for example by showing cached data instead of failing the page."

The full answer: Unlimited retries can turn a slow dependency into a full outage, so retries need a budget too. Map the dependencies of a service and which ones are critical; agree targets with their owners. Test what happens when each one is slow, not only when it is down.

A weak answer: "We retry until it works." Follow-up: "The dependency is a payment provider." Discuss what can degrade and what must not.

How do you keep a Kubernetes platform reliable through upgrades and node failures?

What they check: practical operations of clusters, not only their theory.

Short answer: "I spread workloads across zones, set requests and limits so the scheduler can place them, use disruption budgets so an upgrade never takes too many copies down, and health checks that restart what hangs. Upgrades go to a test cluster first and then node pool by node pool, with capacity added before old nodes are drained."

The full answer: Keep the cluster close to the supported version, because skipped upgrades pile up risk. Watch the control plane, DNS and the network inside the cluster, which cause many hard incidents. Practise losing a node and a zone, and write down how long recovery takes.

A weak answer: "Kubernetes heals itself." Follow-up: "After an upgrade, some pods never become ready." Walk through what you would check.

The senior steps

As a staff site reliability engineer or SRE manager, how would you bring SRE practices to teams that have none?

What they check: influence without authority, and adoption step by step.

Short answer: "I start with one willing team and its most painful service, help them set an SLO, clean up their alerts and run a blameless review, and show the result in numbers. Then I turn what worked into templates, training and a light standard, so the next teams adopt it themselves. SRE should help teams own their reliability, not take it from them."

The full answer: At staff and principal site reliability engineer level the work is standards across many teams and the hardest cross-team incidents; as SRE manager it is the team, the on-call model, hiring and the budget. Both need a view of reliability in money: what an hour of outage costs and what the next nine would cost to reach.

A weak answer: "Teams must follow the SRE rules or lose production access." Follow-up: "A team says SLOs slow them down." Explain what you would measure and change.

Your CV for these questions

Each service on your CV invites the questions above: what was its target, how did it fail, what did you change, and what number moved. Write each of those as one line under the job it belongs to, so the story is there to be asked about:

Check your CV against an SRE job you are aiming for: what the check finds missing is likely to come up, so rehearse those incidents and changes first.