2026 update
A few things have changed in 2026. AI is now allowed in coding rounds at Canva and Meta, detection has improved at companies that still ban it, comp has split at staff+, and the post-onsite wait got longer. Read what changed in 2026 →
What you'll be expected to do
The bar they grade against- Own the reliability of a service or sub-system, define SLOs, build observability, drive down toil
- Participate in primary on-call rotations; lead incident response when paged
- Write production-grade infrastructure code (Terraform, Pulumi, K8s manifests) and automate manual operations
- Partner with the product engineering team on architecture decisions that affect reliability
- Author postmortems and drive remediation items to completion
- Improve CI / CD pipelines, deploy safety, and rollback mechanisms for your service
The loop, round by round
5 rounds · 4–6 weeksMost companies follow a similar shape for SRE interviews. Total calendar time is 4–6 weeks from recruiter screen to offer.
Background, role calibration, on-call experience, motivation
Algorithmic problem at LeetCode-medium level plus a systems / scripting question (e.g. "parse this log format and emit X"). Some loops do bash + Python combined
Live debugging on a real-ish broken system: read logs, trace, hypothesise, narrow down root cause. Some companies do this as a take-home with a Docker-compose stack
Design an observability stack, a multi-region failover strategy, or a high-availability service. Probing on SLOs, error budgets, failure modes, blast radius
On-call war stories, incident response, partnership with product engineering, handling toil vs feature pressure
Sample questions you should be ready for
9 of the ones that decide itRepresentative of what companies ask at this level. Every question here is drillable out loud, which is the fastest way to find out whether your answer holds up under follow-ups. Calibrd adds voice practice with coaching on every answer, and a full voice mock interview: a live round with an AI interviewer who has read the role and your CV, then an honest debrief.
- 01“Walk me through how you'd debug a service whose p99 latency just doubled, no obvious deploy correlation. What's your first 15 minutes?”Practise this →
- 02“Given a stream of structured log lines, walk me through how you'd compute the per-endpoint error rate over a 5-minute sliding window. Choose your language; cover what changes at 100k events/second.”Practise this →
- 03“Implement a rate limiter as a class in Python. Walk through how you'd extend it to handle distributed rate-limiting across 50 service instances.”Practise this →
- 04“Design the observability stack for a 100-service microservices architecture. Cover metrics, logs, traces, and the SLO framework.”Practise this →
- 05“Design a deployment system that lets engineers ship to prod 50 times a day safely. Cover canaries, rollbacks, feature flags, and the blast-radius story.”Practise this →
- 06“Design a multi-region active-active service with sub-100ms p99 latency. Walk through replication, failover, and what breaks when a region goes down.”Practise this →
- 07“Tell me about an incident you led the response on. Walk through detection → diagnosis → mitigation → postmortem.”Practise this →
- 08“Describe a time you pushed back on a product team that wanted to ship something you thought was unsafe. How did the conversation go?”Practise this →
- 09“Tell me about a high-toil situation in your previous role. What did you do to reduce it?”Practise this →
These are the general ones. Paste a real posting and Calibrd predicts the questions that company asks for that exact role, then interviews you on them.
Predict my questions →Compensation benchmark
US majors · USD · medianMedian compensation for SRE at major US tech companies, headline numbers in USD. Pay in markets like London, Berlin and Singapore tends to be meaningfully lower in base terms, and equity ratios vary by company stage.
FAANG L4 SRE total comp at 50th percentile is $260–340k. SRE typically tracks the SWE band at the same level, sometimes a small premium at companies where SRE is a separate ladder (Google, where SRE is a co-equal track).
How to prep
5 tactical tipsLead behavioural answers with the STAR method: Situation, Task, Action, Result. The tips below build on that structure for this specific role.
- 01Drill 50+ LeetCode mediums focused on hash maps, graphs, and streams, the SRE coding bar is closer to SWE than DE
- 02Read the Google SRE Book (free online) cover-to-cover, it's the lingua franca of SRE interviews and gets referenced directly
- 03Practise reading logs and metrics fast. Spin up a local Prometheus + Grafana stack and break things deliberately to build debugging intuition
- 04Know one IaC tool deeply (Terraform or Pulumi) and one container orchestrator (Kubernetes) at the level of "I could write the manifests from scratch"
- 05Have 5–6 STAR stories with concrete incident details: detection time, time to mitigation, scope of impact, what changed in postmortem
Where SRE candidates fail
Spot it in a mock firstA few common mistakes that get SRE candidates rejected even when they are otherwise strong. Worth catching in a mock interview before they show up in a real one.
Designing a reliability solution without naming SLOs, error budgets, or what "good enough" means.
Why it fails
SRE system design grades explicitly on whether you can reason about reliability as a budget, not an absolute. "Five nines" isn't an answer; the answer is "three nines availability, 200ms p99 latency, error budget of X minutes per quarter, here's how we'd spend it." Candidates who design for 100% uptime signal "haven't thought in SLO terms."
Fix
Open every reliability design by naming the SLOs you'd target and why. Then frame trade-offs against the error budget: "if we spend half the budget on this feature launch, that means we need to lock down everything else this quarter." The SLO framing is the SRE signal.
Doing the debugging round by guessing causes instead of forming hypotheses from the data.
Why it fails
Debugging rounds at SRE bar grade on whether you read the signal before you reach for the cause. Jumping to "it's probably the database" without checking metrics, logs, or recent changes signals "I'd waste an hour during a real incident chasing the wrong thing." The senior pattern is: check the obvious signal first (deploys, dashboards, error rate by endpoint), then narrow.
Fix
Structure debugging answers as a checklist: what changed recently (deploys, config), where's the signal narrowest (which endpoint, which region, which version), what would falsify each hypothesis. Even one or two minutes of structured triage at the start tells the interviewer you've done this in real incidents.
Describing past on-call work as "I respond to pages and fix issues" without specific incident detail.
Why it fails
SRE interviewers calibrate against incident ownership. Generic on-call descriptions tell them nothing. "We had a 40-minute outage last month: the alert fired at 02:14, I diagnosed it by 02:28 using the request-rate dashboard, mitigated by failing over to region us-east-2, RCA the next day pinned it on a config push" lets them peg you immediately.
Fix
For your top 3–4 incident stories, attach four numbers: detection time (when alert fired), diagnosis time (when you identified the issue), mitigation time, and scope of impact (users affected, dollars lost, SLA hit). Rough numbers beat no numbers.
Recommended resources
No affiliate linksBooks, courses, and tools that come up most often in SRE prep.
- 01Google SRE Book →
The canonical reference. Free online. Read chapters 3 (Embracing Risk), 4 (SLOs), and 14 (Managing Incidents) before any SRE loop.
- 02Google SRE Workbook →
Practical follow-up to the SRE Book. Chapter 2 (SLOs) and chapter 9 (Incident Response) are the highest-leverage.
- 03Brendan Gregg, Systems Performance →
The reference for the debugging / performance-analysis round. Linux internals at SRE-relevant depth.
- 04Implementing Service Level Objectives (Alex Hidalgo) →
The book-length treatment of SLOs — the concept every SRE design round orbits. Read it if the SLO chapter of the SRE Book left you wanting worked examples.
- 05Honeycomb, Observability Engineering blog →
Practitioner-written posts on real observability problems. Useful for the system-design round on observability.
Frequently asked questions
Is this guide useful if I'm a SWE moving into SRE, or coming from DevOps / Ops?
Yes, the L4 / IC3 bar described here applies whether you came from backend engineering, DevOps, or sysadmin / ops. SWE-to-SRE transitions usually have a strong coding base but need to build on-call and reliability intuition (SLOs, error budgets, blast radius). DevOps-to-SRE transitions have strong infrastructure skills but need to drill the coding round, which sits closer to the SWE bar than people expect.
How long should I prep before my SRE onsite?
The process takes 4–6 weeks. Add 6–8 weeks of prep, LeetCode mediums, the Google SRE Book, and one observability deep-dive are the highest-leverage. Don't underestimate the coding round.
What's the most common mistake candidates make at the SRE bar?
Under-investing in the coding round. Many candidates from DevOps backgrounds have great infra skills but get filtered at the coding screen because they assumed SRE = bash + Terraform. The coding bar is closer to SWE than DevOps; drill LeetCode mediums for 4+ weeks.
What if my interview process is different from what's listed?
Most variation is at the edges. Major tech companies (FAANG, scale-ups, mid-size SaaS) follow processes within 1–2 rounds of what's described. Smaller startups often run fewer rounds (3–4) but the bar at each round is similar; less-tech-mature companies sometimes skip system design or behavioural rounds entirely. Read the JD and ask the recruiter at the screen, they'll tell you what's coming.
How does this guide compare to running a free scan?
This guide covers the general bar at L4 / IC3. The free scan reads your specific job description and returns predicted questions for that exact role + company, a calibrated comp benchmark, and (with your CV) experience-gap analysis and an ATS resume check. PDF emailed.
Walk in ready
Walk into your SRE interview ready.
Paste your actual job and Calibrd shows you exactly what that company asks, where your CV is thin, and what it should pay. Then rehearse the round out loud with honest feedback until you're confident. Any tech role. Free to start.
Free to start · No credit card · Your CV stays on your device