Site reliability engineer screening questions: SLOs, error budgets, incidents, toil and on-call load

Site reliability engineer screening questions should test whether the candidate has owned the reliability of real services rather than only kept them running: which service level objectives (SLOs) they set and measured, what happened when an error budget ran out, which incidents they led and what the postmortems changed, how much of their week was toil and what they automated away, and how heavy their on-call load was. Google's SRE book, where most of these terms come from, sets a goal of keeping toil below half of each SRE's time, so a candidate who did the job can tell you their own share. There is no license for SREs, and cloud or Kubernetes certifications are supporting evidence only.

The DevOps engineer screening questions cover pipelines, infrastructure as code, Kubernetes ownership and cost, with one short SLO question, and the cloud engineer screening questions cover accounts, identity and networking. This page goes deeper on reliability itself: objectives, error budgets, incident command, postmortems, toil and the on-call load the client is really asking someone to carry. For a shorter recruiter call, the DevOps engineer phone screen questions work for SRE candidates too, and the 30-60-90 day plan for site reliability engineers shows what the hire should deliver first.

Which SRE job is it?

Before the first call, ask the hiring manager which services the hire will own, the current SLOs (if any), the on-call rotation, response time and recent page volume, and whether the job is writing code, running platforms or both.

Which terms, references and certifications should you check?

• SLOs and error budgets. The Embracing Risk chapter describes the error budget as an objective measure of how unreliable a service is allowed to be: releases continue while measured reliability stays above the SLO, and when violations spend the budget, releases are halted while the team works on reliability. Example arithmetic: a 99.9 percent availability SLO over 30 days allows 0.1 percent of 43,200 minutes, or 43.2 minutes, of full downtime; at 99.95 percent it is 21.6 minutes.
• Toil. The Eliminating Toil chapter defines toil as production work that is manual, repetitive, automatable, tactical, without enduring value and growing with the service, and states a goal of keeping it below 50 percent of each SRE's time.
• On-call load. The Being On-Call chapter says no more than 25 percent of the time left after engineering work should be on-call, and sets a ceiling of two incidents per 12-hour shift, because an incident with its follow-up takes about six hours on average in Google's experience.
• Postmortems. The Postmortem Culture chapter describes blameless postmortems that look for contributing causes without blaming a person, triggered by events such as user-visible downtime beyond a threshold, data loss, an on-call intervention such as a rollback, or a monitoring failure.
• Delivery metrics. DORA's metrics guide names five software delivery measures: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate.
• Telemetry. OpenTelemetry is a Cloud Native Computing Foundation project for generating, exporting and collecting traces, metrics and logs.
• Certifications. Google Cloud's Professional Cloud DevOps Engineer exam assesses, among other things, the ability to apply site reliability engineering practices (two hours, $200, with three or more years of industry experience recommended). The Linux Foundation's Certified Kubernetes Administrator is a two-hour, performance-based exam valid for two years. AWS and Azure equivalents are listed in the DevOps page.

Knockout questions

SLO, incident and postmortem questions

1. "Pick one service you owned. What were its SLIs and SLOs, and who chose them?"
   • Strong answer: an indicator such as the share of requests that succeed within 300 milliseconds, a target and window, where the data came from, and who agreed it with the product owner.
   • Red flags: "Five nines" with no measurement, or a customer contract's SLA quoted as the internal SLO.
2. "What happened the last time a service used up its error budget?"
   • Strong answer: releases slowed or paused, reliability work moved up the backlog, a burn-rate alert caught it early, and they can say what they fixed.
   • Red flags: the budget ran out and nothing changed, or there was never a budget at all.
3. "Walk me through the worst incident you led."
   • Strong answer: how it was detected, when it was declared, who held which role (commander, communications, operations), mitigation before root cause, customer updates and the timeline.
   • Red flags: a story in which they watched, or in which they fixed everything alone and told no one.
4. "What did the postmortem change, and were the action items done?"
   • Strong answer: contributing causes, specific actions with owners and dates, how completion was tracked, and one action that prevented a repeat.
   • Red flags: a person blamed, or action items that were never finished.
5. "Which alert did you remove or rewrite, and why?"
   • Strong answer: moved from alerts on causes (CPU, a single host) to alerts on user impact or budget burn, and gives the page volume before and after.
   • Red flags: every alert is useful.
6. "How did you get a service ready for a launch or a traffic peak?"
   • Strong answer: a load test, a capacity forecast with headroom, autoscaling limits checked, a readiness review or checklist, a rollback plan.
   • Red flags: "Autoscaling handles it."

Toil, automation and on-call load questions

How does SRE experience get overstated?

• Dashboards as SLOs. Graphs on a screen described as reliability targets. Ask for the target and what happened when it was missed.
• Responder as commander. Joining incident calls described as leading them. Ask who made the decisions.
• The SLA as the SLO. A contract number quoted as an engineering objective. Ask how it was measured.
• Operations renamed. A ticket queue with an SRE title. Ask for the engineering share of their week.
• Team postmortems as personal. Ask which actions they owned and finished.
• Platform user as operator. Deployed onto clusters another team ran. Ask when they last upgraded or recovered one.

A 15-minute phone-screen flow

1. Minutes 0 to 2: the services, the current objectives, the rotation and the stack.
2. Minutes 2 to 5: knockouts 1 to 5.
3. Minutes 5 to 10: the SLO question and the worst incident they led. Write down targets, times and actions in their words.
4. Minutes 10 to 13: toil share and one automation story, or the alert they removed.
5. Minutes 13 to 15: pay and on-call compensation expectations (see salary expectation questions), notice period, next steps.

Scoring

What to put in the submittal

SRE: [name]
Seat type: [embedded / platform / observability / database / operations]
Services owned: [names or kinds], SLIs and SLOs [examples, window]
Error budget story: [what happened when it was spent]
Incidents led: [count], worst one in two sentences, their role
Postmortem action they finished: [one line]
On-call history: [rotation, pages per week, actionable share]
Toil share and automation: [estimate], [what they automated, hours saved]
Stack: [cloud, orchestration, data stores, observability tools]
Certifications (if the client requires): [name, issuer, expiry]
Candidate's own gap: [e.g. "has not led an incident; SLOs were set by another team"]

Lawful phrasing

Describe the rotation, response time and pay, then ask whether the candidate can commit. Do not ask about children, caregiving, health or sleep to judge whether they can handle nights; if a candidate raises a need, treat it as a possible accommodation request, as described in ADA accommodations in interviews. Ask the sponsorship question the same way for everyone, avoid age-coded phrases such as "digital native," and see illegal interview questions for the full list. This page is not legal advice.