Role: Site Reliability Engineer, SLOs and on-callFull interview loop

For a team running a service with real users and real traffic that wants one engineer to own how it is measured, how it is changed and how it recovers. It assumes that engineer writes code against production and joins the on-call rotation for what they write. It does not test a particular cloud, container internals or a deployment pipeline, and a candidate who is strong on those and weak on what follows should not pass it.

Every round begins with something that has already gone wrong, because that is where most of an SRE's work begins. The coding test is a restart script that set off latency alerts in all three zones last Monday and would do it again next Monday. The SLO review is a month of 212 pages to a rotation of six, and an outage that none of them caught because the failures came back as HTTP 200. The incident review is a rate limit pushed to every region in ninety seconds, a rollback that failed when it was needed, and a draft review blaming the engineer who typed the number. The design round is a payment provider that slowed down and took a whole shop with it; its last section runs that design live, on the night of a sale.

The four must-haves are read twice each, and the two reads always come from different directions. Safe automation is read in code the candidate writes and then in a tool somebody else wrote and trusted too far. SLOs and alerting are read first as a rewrite of an objective and its alerts, then as a diagnosis of why nothing paged for half an hour. Incident response is read first as a review of someone else's incident, from its timeline, and then live, on the candidate's own design. Capacity and dependencies are read as arithmetic — how many instances a zone can lose while a script runs — and then as a design around a dependency the company does not control. No competency gets a third read. If one of them is going to be over-scored, it is incident response: calm, well-told accounts of past outages are common, which is why neither of its reads asks for one.

Two trade-offs are deliberate. Safe automation is a must-have, so this loop turns down an engineer who runs incidents well and reasons clearly about SLOs but cannot write a script that stops itself before it hurts anyone. For a team whose reliability work is mostly coordination rather than code, make it a nice-to-have and give the coding round's hour to a second incident. Reliability trade-offs goes the other way: it is read once, in the SLO review, because deciding what happens when an error budget runs out is usually argued with a product lead by someone with standing to argue it. For a senior hire, make it a must-have and give it a second question — whether the sale is worth eighteen instances fits naturally in the design round's capacity section.

The role's Technical Interview covers round two's ground on a different service — an objective rewritten from one booking API's numbers, its pages, and a release on a budget two-thirds gone — and adds a capacity question. Use it in round two's place once the SLO review's pack has been passed around. It then scores the same two competencies, and its capacity question goes in the interviewer's notes, because capacity and dependencies are already read twice.