Site Reliability Engineer interview loops

A site reliability engineer — an SRE — keeps a running service's promises to the people who use it, and says so plainly when it is not keeping them. In practice that is four kinds of work: deciding what the service measures and what is allowed to wake someone, running the incident when it breaks and the review that changes something afterward, writing the code that acts on the whole fleet at once, and understanding what the service depends on well enough to know how it will fail. Fluency with a particular monitoring stack or cloud console is the smallest part of it.

As of October 2026 the title covers four jobs, and they overlap. The first is a product's own services, run alongside the team that builds them: Reddit's Ads Reliability team joins the on-call rotation, leads incident response and defines the advertiser journeys its objectives measure, from creating a campaign to billing for it (Reddit), and Mercury is starting an SRE team that rotates through product teams, writing retries and circuit breaking into their code and steering their objectives toward customer outcomes the product teams answer for (Mercury). The second is the platform underneath, under the SRE name, as with the Roblox SREs who run the cell infrastructure underneath its services, along with service discovery and secrets (Roblox). The third is databases and storage: MongoDB's storage-layer SREs define objectives and capacity plans for the storage under Atlas and join a 24/7 on-call rotation (MongoDB), and Grafana Labs' databases SRE keeps its multi-tenant databases reliable for its highest-SLA customers, on 12-hour weekday shifts and a weekend roughly every six to eight weeks (Grafana Labs). The fourth is the safety of change: Plaid's release engineering SRE owns the path from merge to production, with progressive rollouts and automatic rollback, and its error-budget program (Plaid). Some employers post the same work under a software engineer title, as DoorDash does for the team that builds what its engineers use to define objectives and take an incident through to its postmortem (DoorDash). The loop below is for the SRE who owns a service in production: the first job, and the part of the others that runs a service against an objective. Building the delivery pipeline is a DevOps engineer's job and designing cloud accounts a cloud architect's, each with a loop of its own; this one starts once the service is live and has users to let down.

The role is easy to interview badly in two opposite directions. Ask about past incidents and the best storyteller wins, because every outage ends well in the retelling. Ask about SLIs, error budgets and burn rates and whoever read about them most recently wins. What people who have carried a pager for a service that mattered do differently shows up in material, not in answers: they notice the alert that paged eighty times and was never acted on, the rollback nobody has tried, the retry that turns a slow dependency into an outage. So every round below gives the candidate something an interviewer can build in an evening — a script with planted faults, a month of pages, an incident timeline with its draft review, an architecture sketch with its numbers — and scores what they find in it and what they decide.

Few employers publish how they interview for it. GitLab's postings do: every SRE candidate takes the same technical round, a collaborative discussion of system architecture and incident review, before meeting a hiring manager and then SREs from the team they are most likely to join (GitLab). That is the same two kinds of material as rounds three and four of the loop below. trivago asks for a case study and has the candidate present it in the technical interview (trivago).

Employers draw the line on AI in the interview in different places. A Fastly SRE posting bars AI tools from the whole interview process, copilots and real-time transcription included, unless the company has authorized them in advance (Fastly, updated October 2026). GitLab welcomes AI in its technical assessments when the candidate uses it openly and can explain their prompts and decisions, and asks candidates not to read out AI-produced answers in interviews (GitLab, undated). Meanwhile the job itself increasingly expects it: Upstart makes demonstrated use of AI-assisted development tools a minimum qualification for its SREs (Upstart). None of the plans below says either way. The coding test lets the candidate look anything up without saying whether that includes an assistant, and most of its hour is code the candidate writes against a stub fleet. The other three rounds send their pack a day ahead and run every question on it, so an assistant used on the pack could prepare much of each round, its arithmetic included. Decide before the loop starts, and tell the candidate where an assistant may be used, the pack included.

A loop is a set of round plans in order. Each round scores one to three competencies, every must-have is scored in at least two rounds, and the debrief goes competency by competency rather than interviewer by interviewer, so no single interview decides the hire. How these plans work covers the rest of the method.

Further reading, as of October 2026. Google's Site Reliability Engineering (O'Reilly, 2016) is free online in its first edition, and its chapter on addressing cascading failures shows how retries at several layers multiply and how a deadline far above normal latency empties a server's threads, the outage the design round starts from; a rewritten second edition was published in 2026. The Site Reliability Workbook (O'Reilly, 2018) has a chapter on alerting on SLOs that works from a plain error-rate threshold to alerts on how fast the error budget is being spent over a long and a short window together, the alerts the SLO review asks for with numbers. Its chapter on implementing SLOs treats an error budget policy agreed by product, development and SRE as the test of whether an objective is fit for use, the subject of the same round's last section. And its chapter on postmortem culture sets a weak worked postmortem, with vague actions, missing owners and a person to blame, beside a strong one, much as the incident review has the candidate rewrite its draft.