Site reliability engineer interview questions in English
SRE interviews in English test reliability thinking (SLOs and error budgets), live troubleshooting, coding and system design, plus how you behave on call. Practise explaining an SLO and an error budget in two sentences each, narrate a debugging session out loud step by step, and prepare an incident story told as a clear timeline.
What a site reliability engineer interview looks like
1. Recruiter screen
Systems you've run, scale, on-call experience and languages (Go, Python).
English focus: Give scale and responsibility in one sentence: 'I'm on call for services handling 20,000 requests a second.'
2. Coding
Practical scripting or algorithm questions, often in Python or Go.
English focus: Think aloud and mention edge cases like empty files or huge inputs.
3. Troubleshooting
'The site is slow. What do you do?' A live, open-ended debugging conversation.
English focus: Say each hypothesis, how you test it, and what the result tells you.
4. System design
Design or scale a service with reliability targets, failover and observability.
English focus: Start from SLOs and failure modes, not from boxes.
5. Behavioural
Incidents, toil reduction, disagreements with product teams about reliability.
English focus: Use data like error budgets to support your position.
10 site reliability engineer interview questions, with spoken answers
Each answer is written to be said out loud: short sentences, the main point first, and one concrete detail. Change the details to your own experience before you practise.
1. What is the difference between an SLI, an SLO and an SLA?
Recruiter screen
What they listen for: Precise definitions and how they relate.
“An SLI is the measurement, for example the percentage of requests that succeed in under 300 milliseconds. An SLO is our internal target for that measurement, like 99.9% over 30 days. An SLA is an external promise to customers, usually with money attached, so it's set looser than the SLO.”
2. What is an error budget, and how do you use it?
Behavioural
What they listen for: That it balances reliability and speed, and changes decisions.
“It's the amount of unreliability the SLO allows. At 99.9% over 30 days, that's about 43 minutes. While we have budget left, teams can ship quickly. If we burn through it, we slow down releases and spend time on reliability. It turns an argument into a number.”
3. Users say the website is slow. How do you investigate?
Troubleshooting
What they listen for: Scope first, then a layered, hypothesis-driven approach.
“First, scope: is it everyone or some users, all pages or some, and since when? I'd check latency dashboards to confirm. Then I'd go layer by layer: load balancer, application, database, dependencies. And I'd check what changed recently, because a deploy or config change is the most common cause.”
4. A server's disk is full. What do you do?
Troubleshooting
What they listen for: Safe immediate action, then root cause and prevention.
“I'd find what's using the space, usually with du on the main directories. Often it's logs. Short term, I'd compress or remove old logs carefully, and check for deleted files still held open by a process. Then fix the cause, like missing log rotation, and add an alert at 80% so we're warned next time.”
5. Write a script that finds the ten most common IP addresses in a log file.
Coding
What they listen for: Working code, and thought about file size.
“I'll read the file line by line instead of loading it into memory, since logs can be huge. For each line I extract the IP, count it in a dictionary, and at the end take the top ten with a heap or Counter's most_common. Quick question: is the IP always the first field?”
6. How would you design a service to survive a data centre outage?
System design
What they listen for: Redundancy across zones or regions, data replication trade-offs, and failover testing.
“I'd start with the target: how much downtime and data loss is acceptable. Then run in at least two zones or regions behind a global load balancer. The hard part is data: synchronous replication is safer but slower, asynchronous is faster but can lose recent writes. And I'd test failover regularly, because untested failover usually fails.”
7. Tell me about an incident you led.
Behavioural
What they listen for: Clear roles, communication and a blameless follow-up.
“Our checkout API started timing out during a sale. I was incident commander: I assigned one person to investigate, one to communicate, and posted updates every 15 minutes. We found a database connection pool exhausted by a new retry setting, rolled it back, and recovered in 35 minutes. The follow-up was a load test for config changes, not only code changes.”
8. What is toil, and how do you reduce it?
Behavioural
What they listen for: The definition and a concrete example of automating it away.
“Toil is manual, repetitive operational work that grows with the service and doesn't add lasting value, like restarting a stuck job by hand every week. I reduce it by measuring it first, then automating the biggest pieces. In my last team we automated certificate renewal and saved about four hours a week.”
9. How do you decide what to alert on?
System design
What they listen for: Symptom-based alerting and protecting on-call from noise.
“I alert on symptoms users feel, like error rate or latency against the SLO, ideally with burn-rate alerts. Causes like high CPU go on dashboards, not pagers. Every page should be urgent and actionable; if people ignore an alert, it should be fixed or deleted.”
10. A product team wants to launch, but you think the service isn't ready. What do you do?
Behavioural
What they listen for: Data-driven influence and a constructive path.
“I'd make the risk concrete with data: load test results, missing alerts, no rollback plan. Then offer a path, for example launch to 5% of users with a clear rollback trigger. I'd rather help them launch safely than block them.”
Phrases to have ready
- Scoping a problem
- “Before I dig in: is this affecting everyone, or a subset of users?”
- Stating a hypothesis
- “My working theory is the database. I'll check connection counts to confirm or rule it out.”
- Using data in a disagreement
- “We've used 80% of this month's error budget, so I'd suggest we pause risky releases.”
- Incident communication
- “Impact: about 10% of checkouts failing. Mitigation in progress. Next update at 14:30.”
- Explaining a trade-off
- “Synchronous replication protects the data, but adds latency on every write.”
- Closing an incident story
- “The lasting fix was in the process, not just the code.”
Site Reliability Engineer vocabulary in plain English
- Error budget
- How much failure the reliability target allows before we slow down.
- Burn rate
- How fast we're using up the error budget.
- Toil
- Manual, repeated operations work that a script could do.
- Graceful degradation
- When part of the system fails, the rest keeps working with fewer features.
- Blast radius
- How much is affected when something breaks.
- Incident commander
- The person coordinating the response, not necessarily fixing it.
English mistakes that cost points
Avoid: Jumping to a solution in troubleshooting before scoping the problem.
Instead: Ask who, what and since when first. Interviewers score the process.
Avoid: Saying '100% uptime' as a goal.
Instead: Talk about appropriate targets: 'For this internal tool, 99.5% is enough.'
Avoid: Telling incident stories with 'someone did a bad deploy'.
Instead: Blameless phrasing: 'a config change went out without a load test.'
Avoid: Mixing 'latency' and 'throughput', or 'availability' and 'reliability'.
Instead: Use each term precisely. SRE interviewers often check this.
FAQ
What are the most common SRE interview questions?
SLI versus SLO versus SLA, error budgets, 'the site is slow, what do you do?', Linux troubleshooting, a practical coding task, designing for failover, alerting strategy, toil and incident stories.
How do I talk through a troubleshooting question in English?
Scope the problem, state a hypothesis, say how you'll test it, and say what the result means. Repeat. Short phrases like 'my working theory is…' and 'that rules out…' keep your thinking visible.
How is an SRE interview different from a DevOps interview?
SRE loops usually include more coding and go deeper on reliability targets and error budgets. DevOps loops focus more on CI/CD and infrastructure tooling. Many questions overlap; see the DevOps page too.
Keep practising
Read next
Browse by topic: System Design · Technical Interviews · Behavioural & STAR
Other roles: Data Analyst · Data Scientist · Data Engineer · Business Analyst · DevOps Engineer · QA Engineer · Cybersecurity Analyst · Engineering Manager · Technical Program Manager · Machine Learning Engineer
Ready to practise?
Turn interview English into a repeatable skill
Work through the Interview English Course, then book live coaching with engineers who give feedback on both your technical answers and how you deliver them in English.
Join 500+ preparing for global roles