Site Reliability Engineer Interview Questions: Reason About Reliability

SRE interviews can include coding and systems questions, but a useful preparation exercise is to connect operational choices to what users experience. Can you define a failure, measure it consistently, and choose an action that improves reliability rather than merely producing more alerts?

The scenarios below are original practice questions, not an employer's interview bank. For the underlying terminology, Google's SRE workbook on implementing SLOs explains service-level indicators, objectives, and error budgets. An employer's actual policy and service boundaries still matter.

1. What would you measure for a booking service?

First clarify the user journey. Loading a landing page successfully does not establish that customers can complete a booking. A candidate might propose successful eligible booking requests as one indicator, with latency measured separately.

Then define "eligible" and "successful." Which client errors are excluded? Are retries counted individually? Does a response count as successful if the downstream reservation never persists? These choices must be explicit before the percentage becomes useful.

A strong answer explains the observation point and its blind spots. A server-side success counter may miss failures that prevent a request from reaching the service at all.

2. Calculate a request-based error budget

A fictional service records 1,000,000 eligible requests during a completed measurement window. Its objective is 99.9% success. It has recorded 400 unsuccessful requests under the agreed definition.

Calculation	Result
Permitted unsuccessful fraction	100% minus 99.9% = 0.1%
Budget for this request volume	1,000,000 multiplied by 0.001 = 1,000 requests
Budget consumed	400 requests, or 40%
Budget remaining	600 requests, or 60%

Do not translate that result directly into minutes of permitted downtime. This is a request-based objective, and traffic need not be constant. In a live rolling window, the denominator and which requests remain in the window also change.

3. In a live window, would you stop releases with 40% consumed?

Not from that percentage alone. Ask how quickly the budget was consumed, what remains of the relevant window, whether a current incident is burning it rapidly, and what release policy the team agreed to follow.

A low-risk reliability fix is not necessarily equivalent to a large feature rollout. Explain the evidence, owner, and rollback conditions rather than claiming that one budget threshold universally answers every release decision.

4. What makes an alert worth paging someone for?

Describe the condition, user impact, required response, and time sensitivity. A high resource-utilization signal may aid diagnosis without requiring an immediate page. Conversely, an important user journey can fail while machine-level metrics appear normal.

Explain how you would test the alert, link the responder to a usable runbook, and reduce duplicates without hiding distinct failures. An alert that nobody can act on creates interruption rather than reliability.

5. How would you handle an incident with incomplete evidence?

Separate mitigation from a final causal conclusion. Establish scope, check recent changes, preserve useful evidence, and coordinate a reversible mitigation through the incident process. Communicate what is known and unknown.

After recovery, distinguish the triggering event from conditions that allowed the impact to spread. "An engineer made a mistake" does not explain missing safeguards, detection delays, or recovery friction.

6. Which recurring task would you automate first?

Compare frequency, manual effort, failure risk, and the cost of maintaining the automation. A script that silently repeats an unsafe action is not a reliability improvement. Describe validation, ownership, and how an operator can recover if the automation fails.

Prepare one real example you can defend, including an unsuccessful hypothesis. Use the technical interview preparation guide for a practice plan and the guide to answering an unfamiliar technical question when a scenario exceeds your experience.