Site reliability engineer interview questions and how to answer them
An SRE interview tests two things at once: can you write real code, and can you stay calm and methodical when production is on fire. Expect a coding round, a systems design round built around failure, and at least one conversation where they hand you a broken system and watch how you think. The questions below are the ones that come up most, with what the interviewer is really listening for.
What happens in each round
- 1
Recruiter or hiring manager screen
What happens
Whether you've actually carried a pager, what size of system you've run, and whether you lean more toward coding or operations. Have one incident story ready in a couple of minutes.
- 2
Coding round
What happens
Practical code in Go or Python, often a log parser, a rate limiter or a small tool that talks to an API. They care about clean error handling and edge cases more than clever algorithms.
- 3
Troubleshooting or debugging round
What happens
They describe a symptom, like latency climbing on one service, and you ask questions to find the cause. They grade your method: what you check first, what you rule out, and whether you mitigate before you diagnose.
- 4
Systems design with a reliability focus
What happens
Design something like a URL shortener or a metrics pipeline, then defend it against failures: a zone going down, a dependency slowing, a traffic spike. Expect follow-ups on monitoring and SLOs.
- 5
Behavioral and incident deep review
What happens
How you ran a real incident, how you wrote the postmortem, and how you handled pushback from a product team. Blameless language matters here.
Questions you're likely to get
1.What's the difference between an SLI, an SLO and an SLA?
Why they ask
It's the vocabulary of the whole job. If you blur these together, the rest of the interview gets harder.
How to answer
- An SLI is the measurement, like the share of requests that succeed under a latency threshold
- An SLO is the internal target for that measurement over a rolling window
- An SLA is the external contract with customers, usually looser than the SLO, with money or credits attached
- Give an example from a service you ran and explain why you picked that indicator
2.How would you use an error budget when a product team wants to ship during a rough week?
Why they ask
Error budgets only work if someone enforces them without starting a war. They want to see judgment, not a rulebook.
How to answer
- Check how much budget is left and what burned it
- Point to the agreed error budget policy so it isn't a personal call
- Offer options: a canary release, a feature flag, or a delay until the budget recovers
- Escalate with data if the team still wants to go, and write down the decision
3.Walk me through an incident you led from page to postmortem.
Why they ask
This is the single best predictor of how you'll behave on their rotation.
How to answer
- What alerted you and how quickly you acknowledged and declared the incident
- How you split roles: incident commander, communications, hands on keyboard
- What you did to stop the bleeding before finding the root cause, such as a rollback or traffic shift
- What the postmortem found and which action items actually shipped
4.Latency on an API jumped in the last hour. What do you check?
Why they ask
This is the troubleshooting round in miniature. They want structure, not a guessing game.
How to answer
- Confirm scope: all endpoints or one, all regions or one, all customers or some
- Check what changed: recent deploys, config pushes, feature flags, traffic shape
- Look at the golden signals: latency, traffic, errors and saturation, plus dependencies like the database
- Use traces to find which hop got slow, and roll back first if a recent deploy lines up
5.What makes an alert good, and how do you deal with a noisy pager?
Why they ask
Alert fatigue is how SRE teams burn out. They want someone who fixes it rather than tolerates it.
How to answer
- A good page is urgent, actionable and tied to user impact, ideally an SLO burn rate
- Cause-based warnings like high CPU go to a dashboard or a ticket, not a page
- Review every page from the last rotation and delete, tune or automate the ones nobody acted on
- Every page should link to a runbook
6.What is toil, and how have you reduced it?
Why they ask
Cutting toil is the core idea that separates SRE from traditional operations.
How to answer
- Toil is manual, repetitive, automatable work that scales with the service and adds no lasting value
- Name a specific task you automated, like certificate rotation or scaling a queue consumer
- Explain how you measured the time it used to take
- Mention what you chose not to automate and why
7.Design a monitoring and alerting setup for a new service.
Why they ask
They're checking whether you know the observability stack well enough to build one, not just read one.
How to answer
- Start from what users actually do and pick SLIs that reflect it
- Metrics in Prometheus or a hosted tool, logs with structure, traces through OpenTelemetry
- Multi-window burn rate alerts on the SLO rather than static thresholds
- Dashboards for each on-call question, and a plan for keeping cardinality under control
8.How would you make this service survive the loss of a whole availability zone?
Why they ask
Failure-aware design is the core of the systems round.
How to answer
- Spread instances and replicas across zones with enough spare capacity to absorb one going away
- Talk about stateful parts: database failover, replication lag, and what data could be lost
- Health checks and load balancer behavior during the failover
- Say how you'd test it, such as a game day that actually drains a zone
9.Tell me about a Kubernetes problem you debugged.
Why they ask
Most SRE teams run on Kubernetes, and pods that restart for mysterious reasons are a weekly event.
How to answer
- Describe the symptom, like CrashLoopBackOff, OOMKilled or pods stuck pending
- How you used kubectl describe, events, logs and node metrics to narrow it down
- The actual cause, such as memory limits set too low or a failing readiness probe
- What you changed so it wouldn't happen again
10.How do you roll out a risky change safely?
Why they ask
Most outages start with a change. They want to know your default release habits.
How to answer
- Canary or staged rollout with automated checks against the SLO
- Feature flags so you can turn it off without a deploy
- A tested rollback path before you start
- Avoid Friday afternoon pushes and big-bang config changes to every region at once
11.Tell me about a time you disagreed with a developer or product team about reliability.
Why they ask
SREs influence teams they don't manage. They want to see persuasion, not authority.
How to answer
- Set up the disagreement fairly, including their side
- Show the data you brought, like incident history or budget burn
- Explain the compromise you reached
- Say what you'd do differently next time
Mistakes that sink good candidates
Blaming a coworker by name when you describe an outage
Treating the troubleshooting round as a quiz and guessing instead of asking questions
Claiming you've never caused an incident
Talking only about tools and never about users or impact
Need more Site Reliability Engineer interviews to prep for?
HeroApply applies to Site Reliability Engineer jobs that match you, every day. 519 jobs are open today.