SRE Fundamentals
Fast recall
Quick revision
Core answer
Whether you understand SRE as engineering applied to operations — SLOs, error budgets, toil reduction, automation — not just 'the on-call team'.
Equating SRE with 'ops' or 'on-call' — missing SLOs/error budgets (the quantitative reliability contract) and toil reduction (the engineering mandate).
Frame SRE as engineering applied to operations: SLOs and error budgets as the reliability contract, toil reduction via automation as the mandate, and the blameless postmortem as the learning loop — distinct from traditional ops.
Interview-ready guide
Interview answer
Site Reliability Engineering is an engineering discipline, originated at Google, that applies software-engineering practices to operations — it treats operations as a software problem rather than a manual, ticket-driven one.
It exists because as systems scale, manual operations don't: human toil doesn't compound, on-call burnout rises, and reliability degrades. 9% over 28 days, and the error budget is the gap between 100% and the SLO — the allowed unreliability that balances velocity and reliability. When the budget is overdrawn, launches freeze and reliability work is prioritized, which turns 'reliability versus velocity' from an opinion into a number.
Toil — manual, repetitive, automatable work — is capped and eliminated via automation, because human toil doesn't compound but code does. And blameless postmortems surface systemic causes without scapegoating, building a learning loop from incidents. The tension I'm honest about is that SRE teams can become a privileged ops silo that just says no, which defeats the model — healthy SREs partner with product teams on reliability.
SRE Fundamentals
Direct Answer
Site Reliability Engineering (SRE) is an engineering discipline, originated at Google, that applies software-engineering practices to operations — treating operations as a software problem rather than a manual, ticket-driven one. It exists because as systems scale, manual operations (SSH in, restart, fix) don't: human toil doesn't compound, on-call burnout rises, and reliability degrades. SRE replaces toil with automation and governs reliability with SLOs (service-level objectives) and error budgets — a quantitative contract between the business and engineering about how reliable is reliable enough.
Common Mistakes & Pitfalls
Equating SRE with 'ops' or 'on-call' — missing SLOs/error budgets (the quantitative reliability contract) and toil reduction (the engineering mandate).
Check your understanding
Answer these without looking back at the article.
- What is the difference between an SLI, an SLO, and an SLA, and how do they relate?
- How does the error budget turn the reliability-versus-velocity trade-off into a number?
- What counts as toil, and why must SRE cap and eliminate it rather than absorb it?
- Why are postmortems blameless, and what does a blame culture do to learning?
- How should SREs engage with product teams to avoid becoming a 'no' silo?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.