SRE interview questions
6 questions interviewers actually ask, each with a model answer you can study and an AI drill that grades how you would say it out loud.
0/6
Mastered
Questions and answers
Model answer
Toil is manual, repetitive, automatable work that scales with service size and produces no lasting value, like restarting a service by hand. SRE caps toil so engineers spend time on engineering that reduces future toil. Automating toil away is both a productivity and a reliability win.
Model answer
A blameless postmortem analyzes an incident assuming everyone acted reasonably given what they knew, focusing on systemic causes and concrete fixes rather than punishing individuals. Removing blame encourages honest disclosure, which surfaces the real contributing factors and prevents recurrence far better than finger-pointing.
Model answer
Each extra nine of reliability costs exponentially more, and users rarely perceive the difference past a point because their own networks and devices fail. Targeting 100% also leaves no error budget, which means no room to ship changes. The right target is the lowest reliability users are happy with, freeing budget for velocity.
Model answer
Set aggressive timeouts so you do not hang, retry with exponential backoff and jitter but bound the retries, use a circuit breaker to stop hammering a failing dependency, and apply load shedding or fallbacks to degrade gracefully. Assume every dependency will fail and design so one failure does not cascade.
Model answer
Declare the incident early, appoint an incident commander to coordinate, and assign clear roles for operations and communications. Keep a running timeline, communicate status to stakeholders on a cadence, and focus on mitigation first and root cause later. After resolution, run a blameless postmortem with tracked action items.
Model answer
An error budget is the allowed amount of unreliability, the gap between your SLO and one hundred percent. While budget remains, teams ship features freely; once it is exhausted, the focus shifts to reliability work until the service recovers. It turns the reliability debate into a shared, data-driven decision instead of a tug of war between product and operations.