Platform & Developer Experience
Site Reliability Engineer
The most standardised interview in this family, which makes it the most preparable.
What the job actually is
You own whether the service is up, measured against a number you agreed in advance. SLOs and error budgets, incident command, capacity planning, and the automation that removes the toil you just discovered. The distinction that matters: SRE serves end users; platform engineering serves internal developers. Teams blur it constantly, so ask who your customer is.
Titles this hides behind
The loop
Prepare like this
- Practise NALSD with real arithmetic. Take "design a service serving 50k QPS at 99.9%" and produce machine counts, disk throughput and failure-domain layout. Say the numbers out loud; the round rewards estimation fluency.
- Have an error-budget policy opinion. The hardest rounds centre on what you do when the budget is exhausted and product wants to ship anyway.
- Rehearse one incident end to end — detection, mitigation, root cause, and the action item that actually got done. Incident-response storytelling now outweighs traditional coding in these loops.
- Refresh Linux internals. It is 19% of the corpus and close to 100% of the troubleshooting round.
Be ready for
- "Your error budget is gone in week two of the quarter. Product wants to ship. What happens?" The signature question. There is no clean answer — they want your reasoning and your escalation path.
- "Latency doubled ten minutes ago. Talk me through what you check, in order."
- "What is an SLO you have set that turned out to be wrong?" Testing whether you have actually operated one rather than read about them.
Red flags in the posting
SRE that is ops with a pager. If the JD names no engineering time, no error budget and no automation ownership, you are being hired to absorb toil rather than remove it. Ask directly what fraction of time is project work — the Google-derived norm is 50%, and a team that cannot answer has not thought about it.
On-call with no rotation size. Ask how many people are in the rotation. Fewer than six is a burnout signal.
Compensation
A day that is actually representative
| Time | What you are actually doing |
|---|---|
| 08:00 | Handover, then error-budget check. |
| 10:00 | Write an SLO with a product owner who wants one that is easy to meet. |
| 13:00 | Toil removal — automating the thing you did three times last week. |
| 15:00 | A capacity model for a launch. |
| 16:30 | Postmortem action item that has been open six weeks. |
Real cases worth being able to discuss
The published error-budget model and NALSD interview format have been widely adopted; the error-budget policy is the mechanism that makes reliability a shared decision rather than a veto.
Use it to say: “I use the error budget to turn a reliability argument into a pre-agreed policy, which is the only version that survives release pressure.”
A deployment reaching only some servers, combined with a repurposed flag, produced roughly $440m of losses in 45 minutes.
Use it to say: “It is my standard example that deployment consistency and a kill switch are reliability controls, not release conveniences.”
A three-week plan
Week 1 — NALSD
Days 1–5: Five capacity questions, one a day, fifteen minutes each, ending with a machine count and stated assumptions.
Week 2 — operating
Days 1–2: Write an error-budget policy you would defend.
Days 3–5: Rehearse one incident end to end with the four decision points.
Week 3 — depth
Days 1–3: Linux internals and troubleshooting drills.
Days 4–5: The blameless postmortem answer, out loud.
The book for this field
Infrastructure & Reliability
Reliability and error budgets, capacity arithmetic, networks, storage and the restore you have not tested, the physical layer, a debugging method that transfers, running production, and an honest look at Kubernetes. Plus a Middleware section — web and application servers, messaging (IBM MQ, Kafka) and managed file transfer, from basics to licensing and cost.
Also read for this role
Networks, Automation, Connectivity & Data Centres
Twelve chapters from a single packet to a submarine cable. Subnetting worked by hand, BGP and why hijacks succeed, DNS and the two outages worth knowing by name, TLS and the expiry that still takes down companies, cloud networking with the arithmetic, transit and peering, colocation and what an AI rack did to the industry, and four debugging scenarios worked end to end.
All 18 chapters in Networks, Automation, Connectivity & Data Centres →
Cross-cutting
Skills every archetype tests
These are shared across every field on this site — the same question asked in different vocabulary — so preparation here compounds rather than being spent once. The book above is specific to your field.
Practice the 35 Platform questions → · Back to Platform & Developer Experience →