SRE mock interview — practice with AI

SRE interviews are the loop where DevOps depth meets software engineering rigor — and the candidates who get offers are the ones who can move from a five-minute outage triage to a thirty-minute SLO design conversation without losing the audience. Most candidates lose offers not on Linux trivia but on the moment they're asked "what's your error budget for this quarter and how did you arrive at it." This guide shows how to use AI mock interviews to rehearse the SRE loop specifically.

Typical interview rounds for SREs

The SRE loop is the longest in infra — typically 5–6 rounds. Recruiter screen; a fundamentals phone screen (Linux internals, networking, distributed systems basics); a coding interview (Python or Go, usually parsing logs or building a small CLI, sometimes data-structure-light); an incident-response or troubleshooting round ("production is down — drive the call"); a system design round ("design a global load balancer with 99.99% availability"); and a behavioral round with the hiring manager. Senior and staff loops add a SLO/reliability-strategy round where you argue tradeoffs at the org level.

The incident-response round and the reliability-strategy round are where AI mocks pay off massively. Both are open-ended conversations under time pressure, both reward structured thinking, both punish generic answers. The AI mock reproduces the unfolding-outage format almost exactly: a vague prompt, escalating follow-ups, scoring on how you narrow the search space. The system design round also fits well — SRE design has its own flavor (availability, blast radius, dependency graphs) that the mock can drive specifically.

Top technical topics

SLOs and error budgets

The Google SRE book vocabulary is table stakes. Be ready: SLI vs SLO vs SLA, picking SLIs that customers actually care about (request success rate, latency p99, freshness — not CPU utilization), error budget math (a 99.9% monthly SLO gives you 43 minutes of budget), error budget policy (what you do when you blow it — freeze releases, deprioritize features, mandatory postmortem). A favorite question: "the team has 99.95% availability but customers complain — what's wrong?" Strong answers interrogate the SLI definition, the aggregation window, and the per-customer experience.

Incident response

The mock will simulate this directly. Be ready for the structured triage rhythm: assess blast radius first (who's affected, how many), then stabilize (rollback, traffic shed, capacity scaling), then diagnose (logs, traces, recent changes), and only then commit to a long-term fix. The IC (incident commander) role is a separate skill — be ready to talk about how you coordinate when three people are typing at once. Postmortem culture: blameless, action items with owners, and the difference between root cause and contributing factors.

Linux and OS internals

Be ready: process model, signals, file descriptors, the OOM killer and how to predict what it picks, cgroups and namespaces, /proc and /sys for live introspection, syscalls and strace, eBPF for production tracing without restarting services, and Linux networking (iptables, conntrack, netfilter). A favorite question: "the load average is 200 but CPU is 30%. What's wrong?" Strong answers separate runnable from sleeping processes and point at IO wait, lock contention, or threads.

Networking

Senior SRE loops probe deep. Be ready: TCP handshake, slow start and congestion control, the difference between latency and throughput in a single conversation, DNS (and why DNS is half the world's outages), TLS handshakes and OCSP stapling, BGP basics for global infra, anycast vs unicast routing, load balancer types (L4 vs L7, hardware vs software, sticky vs round-robin). A favorite scenario: "latency from EU to US-East doubled at 3am, no deploy. Walk me through."

Distributed systems

SRE design rounds love these. Be ready: CAP and PACELC, consistency models (strong, eventual, causal, read-your-writes), consensus (Raft, Paxos sketch), leader election, sharding strategies and rebalancing, replication topologies (sync vs async, multi-leader hazards), distributed transactions (saga, two-phase commit and why nobody runs it), idempotency tokens, and queue semantics (at-most-once vs at-least-once vs exactly-once and what exactly-once actually means in practice).

Observability stack

Prometheus, Grafana, Loki, Tempo or Jaeger, OpenTelemetry. Be ready: metric cardinality and what it costs, alerting on symptoms vs causes, what makes a good runbook, log sampling at scale (and why your log bill is the second-biggest infra cost), trace sampling strategies (head-based vs tail-based), and how to design dashboards for an on-call who has 30 seconds before they need to make a decision.

Common scenario questions

• "Production is down. The latest deploy was 4 hours ago. Drive the incident call." (Triage rhythm, rollback question, comms, IC posture.)
• "Set an SLO for a payment API. Defend your number to a CFO who wants 100%." (Cost of nines, error budget concept, customer-perceived availability.)
• "Design a global load balancer with 99.99% availability." (DNS routing, anycast, health checks, regional failover, blast radius.)
• "Half the requests to one microservice are slow but only at 4am UTC. Investigate." (Cron jobs, GC, log rotation, backup windows, retention sweeps.)
• "You've blown the quarterly error budget. The PM wants to ship a big feature next week. What do you say?" (Budget policy, freeze, negotiation, escalation path.)

Behavioral focus areas — what hiring managers look for

SRE hiring managers screen for three specific traits. First, calm under fire — can you keep a level voice when the situation gets ugly? The mock won't simulate cortisol but it will test whether your structured thinking holds when the prompt gets ambiguous. Second, blameless culture — every postmortem story should focus on systemic causes (we didn't have the alert, the runbook was outdated, the deploy tool let this through) not on the person who pushed the button. Third, business judgment about reliability — staff and principal SREs argue with PMs and execs about how much reliability is worth. Strong stories show how you made that case with numbers, not vibes. Expect prompts about a memorable outage, a time you blew an SLO, a time you said no to a feature for reliability reasons.

How to use AI mock practice for this role

Set the interview type to "Tech Screening" or "Scenario" depending on what you're drilling. For SLO and reliability-strategy practice, paste your current team's situation as context and have the AI play the skeptical CFO or PM. For incident response, switch to "Scenario" mode and have the AI drive an unfolding outage for 15–20 minutes. The mock scores how you narrow the search space, not whether you arrive at the "right" root cause.

For system design, run "System Design" with SRE-specific prompts: design a global rate limiter, design a multi-region database failover, design a control plane that doesn't take itself down. The AI will push on availability and blast radius the way an SRE interviewer does — not on the user-facing UX.

One drill that pays off fast: run five back-to-back incident scenarios in different domains (payment, streaming video, internal API, ML inference, file storage). The pattern-recognition for "is this a deploy, a dependency, a data issue, or capacity" is the most transferable SRE interview skill.

Frequently asked questions