SRE Interview Preparation: Study Plans, Question Bank and a Winning Answer Framework

A story to begin with

What an SRE interview looks like

flowchart LR
  A[Recruiter screen<br/>fit and motivation] --> B[Technical screen<br/>Linux, networking, scripting]
  B --> C[Troubleshooting round<br/>live scenarios]
  C --> D[System design round<br/>reliability focused]
  D --> E[Coding round<br/>practical Python or Go]
  E --> F[Behavioural round<br/>incidents, leadership]
  F --> G[Offer]
  style C fill:#6366f1,color:#fff
  style D fill:#6366f1,color:#fff

How companies level candidates

Many people interview one stage above where they work today. Prepare for the level you want.

The answer framework that works for any scenario

flowchart TD
  A[1. Clarify<br/>impact, scope, start time, changes] --> B[2. Stabilise<br/>safest reversible mitigation]
  B --> C[3. Hypothesise<br/>from golden signals and data]
  C --> D[4. Test cheaply<br/>one change at a time]
  D --> E[5. Communicate<br/>status, ETA, who is involved]
  E --> F[6. Prevent<br/>postmortem, guardrails, detection]
  style B fill:#f87171,color:#fff
  style F fill:#34d399,color:#062

Say these steps out loud. Interviewers grade the structure of your thinking more than whether you guess the exact cause.

Example: "Checkout latency doubled after a release."

1. Clarify: how many users, which regions, when did it start, what shipped?
2. Stabilise: if the release correlates, roll back or turn off the feature flag.
3. Hypothesise: compare new version vs old on the golden signals; check dependency latency, database and cache.
4. Test: trace a slow request; compare a canary against baseline.
5. Communicate: post an update now and every 15 minutes.
6. Prevent: add canary analysis on latency, a load test in CI, a dashboard marker for deploys.

30-day plan: Getting started

• Week 1: Linux commands and performance basics, networking (DNS, TCP, TLS, HTTP), SRE fundamentals.
• Week 2: SLIs and SLOs, Prometheus and Grafana, alert design, logging.
• Week 3: Docker, Kubernetes troubleshooting, Git and CI basics, Terraform introduction.
• Week 4: Python scripts for logs and APIs, 10 scenario drills, two mock interviews.

30-day plan: Practitioner

• Week 1: Error budgets, burn-rate alerts, observability architecture, tracing.
• Week 2: Kubernetes reliability and internals, Terraform at scale, AWS core services.
• Week 3: Release engineering, capacity, DR, system design drills with reliability sections.
• Week 4: Incident command stories, chaos engineering, AI for SRE, three mock interviews.

30-day plan: Senior and staff

• Week 1: Advanced Kubernetes (control plane, networking, scheduling), multi-cluster.
• Week 2: Reliability architecture: cells, multi-region, overload, cascading failures, consensus.
• Week 3: Chaos programmes, AI and LLM reliability, platform strategy, outage case studies.
• Week 4: Behavioural and leadership stories, two system design mocks, a staff-level case study.

30-day plan: Leader and principal

• Week 1: Refresh breadth fast; close gaps in modern Kubernetes and AI operations.
• Week 2: Team formation, operating models, maturity roadmap, KPIs and OKRs.
• Week 3: Architecture reviews of well-known outages; design org-wide programmes; FinOps and risk.
• Week 4: Executive storytelling, hiring and organisation questions, mock panels.

Rapid-fire question bank (answer each in 30 seconds, out loud)

1. What are SLI, SLO and SLA?
2. What is an error budget and what happens when it is gone?
3. Explain burn-rate alerting.
4. What are the four golden signals?
5. Liveness vs readiness probes?
6. How does Kubernetes schedule a pod?
7. What is a PodDisruptionBudget?
8. What causes CPU throttling in containers?
9. How can retries make an outage worse?
10. How do you prevent a thundering herd?
11. Blue-green vs canary?
12. RTO vs RPO?
13. What is the steady-state hypothesis in chaos engineering?
14. How do you secure LLM tool use against prompt injection?
15. What is metric cardinality and why does it matter?
16. What is toil?
17. What happens when you type a URL in the browser?
18. What does exit code 137 mean?
19. Security group vs NACL?
20. Why is replication not a backup?
21. What is a cascading failure?
22. What makes a good postmortem action item?
23. How do you design on-call to avoid burnout?
24. What is a runbook and when do you automate it?
25. How do you decide what to automate?

Practise with the Interview Practice trainer on this site for model answers, and use the Incident Simulations for scenario practice.

Preparing stories for behavioural rounds

Prepare six stories and reuse them: your biggest incident, a mistake and what changed, toil you eliminated with numbers, influencing a team, a conflict, and a project you led. Use STAR plus reflection: Situation, Task, Action (what you did), Result (with numbers), and what you would do differently.

The coding round

Expect practical Python or Go: parse logs, count and rank things, write a retry with backoff, implement a rate limiter or LRU cache, merge intervals to compute downtime. Habits that impress: clarify inputs, state the brute force first, write clean code, test with edge cases, and state time and space complexity.

import random, time
def retry(fn, tries=5, base=0.2, cap=5):
    for i in range(tries):
        try: return fn()
        except Exception:
            if i == tries - 1: raise
            time.sleep(random.uniform(0, min(cap, base * 2**i)))  # full jitter

Smart questions to ask the interviewer

• How are SLOs set and what happens when the error budget is exhausted?
• How many pages does on-call get per week, and how is on-call compensated?
• How are postmortems handled and how many action items get closed?
• What share of SRE time goes to project work vs operations?
• Where does reliability work sit in the roadmap process?

What strong on-call engineers practise

The engineers interviewers trust with a pager tend to share a few habits, and they make an excellent self-study plan. They learn how the system really works by tracing a request through it and drawing the architecture themselves. They read real postmortems like case studies. They rehearse incidents in a safe setting, for example by having a colleague play the failing system while they work through it aloud. They shadow experienced engineers before taking the pager, and they keep learning once they are on call. Interviewers look for exactly this: curiosity about how things work, a method for debugging, and calm communication under pressure.

How to turn this into impact: your first 90 days in a new SRE role

Getting the job is half the story. Here is a plan that builds credibility fast, whatever your level.

flowchart LR
  A[Days 1 to 30<br/>Learn:<br/>system, people, history] --> B[Days 31 to 60<br/>Contribute:<br/>one visible improvement]
  B --> C[Days 61 to 90<br/>Lead:<br/>propose and start a programme]
  style A fill:#22d3ee,color:#012
  style C fill:#34d399,color:#062

Days 1 to 30: learn.

• Draw the architecture of your main service: users, entry points, services, data stores, dependencies. Show it to the team and fix what they correct.
• Read the last 10 postmortems and the current runbooks. Note which problems repeat.
• Shadow on-call. Ask what keeps people awake.
• Meet product, support and security colleagues; learn what they need from reliability.
• Collect baseline numbers: pages per week, incident counts, deployment frequency.

Days 31 to 60: contribute.

• Pick one small, visible improvement: delete the ten noisiest alerts, automate a weekly manual task, add a missing runbook, add deploy markers to dashboards.
• Take your first on-call shifts with a buddy.
• Present your findings to the team in a short, kind, data-backed note (no blame).

Days 61 to 90: lead.

• Propose one programme with a clear owner and measurable result, for example "define SLOs for checkout and set up burn-rate alerts" or "reduce pages by 40%".
• Write a one-page plan: problem, evidence, proposed steps, effort, expected outcome.
• Get a sponsor and start. Share progress every two weeks.

Conversations that build trust

• To the manager: "Here is what I learned and the two things I would fix first. Which matters most to you?"
• To developers: "How can we make your next release safer and easier to roll back?"
• To product: "Which three user journeys should we protect?"

Pitfalls

• Arriving with a solution before understanding the problem.
• Criticising the past instead of building on it.
• Trying to fix everything instead of showing one clear win.
• Staying silent about what you do not know; ask early.

Interview questions

Q1. How do you approach a vague "the site is slow" question? Clarify impact and scope, check recent changes, look at the golden signals, break down by region, version and endpoint, mitigate safely if a cause is likely (rollback), then investigate and plan prevention.

Q2. What would you do in your first 90 days on a new SRE team? Learn the system and incident history, baseline key metrics, fix the noisiest alerts, help define SLOs for critical services, and pick one automation that visibly reduces toil.

Q3. Tell me about an incident you led. Describe the situation, your role, the decisions and why, communication, resolution, measurable impact, and the systemic fixes that followed.

Q4. How do you stay current in SRE? Read public postmortems and engineering blogs, run small experiments in a home lab, follow conference talks, and turn what you learn into team improvements.

Q5. Why do you want to be an SRE? Connect engineering skills to reliability impact: you enjoy debugging complex systems, removing toil with code, and working with developers to make systems safer.

Next: keep practising in the Interview Practice trainer and the Incident Simulations.