SRE Interview Questions 2026: Rounds, Drills and Prep Plan

SRE interview questions in 2026 test five things: Linux and networking fundamentals, live production troubleshooting, reliability math (SLIs, SLOs and error budgets), automation-focused coding, and how you behave during incidents. The round that decides most site reliability engineer interviews is the troubleshooting scenario, usually some version of "a server is slow, find out why." Prepare with a repeatable diagnostic method and a few worked error budget calculations, and you cover the parts most candidates lose points on.

Below: each round, a troubleshooting decision tree, and worked SLO math.

Key Takeaways

• A typical SRE loop has a recruiter screen, a technical screen (coding or Linux), then 4 to 5 onsite rounds: troubleshooting, coding, system design, reliability concepts and behavioral.
• The "server is slow" round rewards method over memorized answers. Check load, CPU, memory, disk and network in a fixed order and say what each result rules out.
• Know the error budget numbers cold: 99.9 percent over 30 days allows 43.2 minutes of downtime, 99.99 percent allows about 4.3 minutes.
• SRE coding rounds are practical (log parsing, rate calculations, retry logic) and usually sit at easy to medium LeetCode difficulty.
• Senior loops add capacity-focused design, where you must estimate machines, bandwidth and storage with real numbers instead of boxes and arrows.
• Incident stories should show calm triage, clear communication, mitigation before root cause, and a blameless postmortem with follow-ups that shipped.

What Is the Difference Between SRE, DevOps and Platform Roles?

Site reliability engineering is software engineering applied to operations problems. Google coined the term and describes it in its free "Site Reliability Engineering" book, where SREs own availability, latency, performance, monitoring, emergency response and capacity for production services. The defining practice is the error budget: teams agree on a reliability target and use the remaining "budget" of failure to decide how fast to ship.

DevOps is a broader culture and set of practices that removes the wall between development and operations. A DevOps engineer job title usually means CI/CD, infrastructure as code and cloud automation. Platform engineering builds internal products (deploy tooling, service templates, Kubernetes platforms) that other teams use.

Titles blur in practice, so read the job description. Here is how the interviews usually differ:

The overlap is large: Linux, networking, Kubernetes and one cloud provider show up everywhere. Our Kubernetes and Docker interview questions and AWS interview questions guides cover the tool-specific side in more depth.

What Does a Site Reliability Engineer Interview Loop Look Like?

Most SRE loops follow the same shape, though the number and order of rounds varies by company and level.

1. Recruiter screen (30 minutes): background, on-call experience, and level calibration.
2. Technical screen (45 to 60 minutes): either a coding problem or a rapid-fire Linux and networking Q&A. Some companies do both.
3. Troubleshooting round (45 to 60 minutes): a live scenario where the interviewer plays the system and answers your commands.
4. Coding and automation round (45 to 60 minutes): practical scripting or a data structures problem.
5. System design (60 minutes): often with a reliability or capacity twist. At Google this can be a non-abstract large system design (NALSD) round.
6. Behavioral and incident response (45 minutes): past incidents, on-call, postmortems and conflict with product teams.

Google is the most formal example. Its SRE postings have separated software-engineering and systems-engineering tracks, and the software-leaning track tends to carry a higher coding bar. Check the posting for your exact role. Our Google technical interview process breakdown covers the shared parts of that loop.

Linux and Networking Fundamentals You Will Be Asked

Fundamentals questions are fast and conversational. The interviewer wants crisp, correct answers and the ability to go one layer deeper when pushed. These come up constantly:

• What does load average mean? The average number of processes running or waiting to run over 1, 5 and 15 minutes. On Linux it also counts processes in uninterruptible sleep (state D), usually waiting on disk I/O, so high load does not always mean high CPU.
• What happens when you type a URL into a browser? DNS resolution, TCP handshake, TLS handshake, HTTP request, load balancer, application, response. Expect follow-ups on any layer.
• How does DNS resolution work? Stub resolver, recursive resolver, root servers, TLD servers, authoritative server, with caching governed by TTL at each step.
• What is an inode, and how can a disk be "full" with free space? An inode stores file metadata. You can exhaust inodes with millions of small files while df -h still shows free bytes. Check with df -i.
• Why does deleting a log file not free disk space? A process still holds the file open. Find it with lsof +L1 and restart or signal the process.
• What does TIME_WAIT mean, and when is it a problem? The side that closes a TCP connection first holds it in TIME_WAIT to absorb stray packets. Large numbers can exhaust ephemeral ports on busy clients.
• What is the OOM killer? The kernel mechanism that kills a process when memory is exhausted. Evidence shows up in dmesg.

Also know SIGTERM vs SIGKILL, systemd basics, the TCP handshake, and L4 vs L7 load balancing. Know which tool answers which question, not every flag.

The Troubleshooting Round: The "Server Is Slow" Drill

The troubleshooting round is a live simulation. The interviewer says something like "Users report that the checkout page is slow. You have SSH access to the web server. What do you do?" You name a command, they tell you the output, and you keep going. There is no single right answer. The grade comes from your method, your narration, and whether you avoid jumping to conclusions.

Start with scope before touching a terminal. Ask three questions: Is it all users or some? When did it start, and did anything change (deploy, config, traffic)? Is it this host or the whole fleet? A slowdown on every host after a deploy points somewhere very different from one bad node.

Then work through a fixed sequence. A well-known version is Brendan Gregg's "Linux Performance Analysis in 60,000 Milliseconds" checklist, published on the Netflix tech blog, which runs ten commands in order. Interviewers recognize it, and it gives you structure under pressure.

uptime                 # load averages: rising, falling, or steady?
dmesg | tail           # OOM kills, disk errors, TCP drops
vmstat 1               # run queue, swapping, CPU split (us/sy/wa/st)
mpstat -P ALL 1        # one hot core = single-threaded bottleneck
pidstat 1              # which process is burning CPU
iostat -xz 1           # disk util, await, queue depth
free -m                # memory, buffers and cache
sar -n DEV 1           # network throughput per interface
sar -n TCP,ETCP 1      # connection rate and retransmits
top                    # sanity check against everything above

The diagnostic decision tree

Use this tree to say out loud what each finding rules in and out. Interviewers often feed you one symptom and watch whether you branch correctly.

The most common trap is the "everything looks normal" branch. When the host looks healthy, a strong candidate says so explicitly and moves outward: application logs, request latency broken down by endpoint, then dependencies. A slow database query or an exhausted connection pool makes the web tier slow while its own metrics look fine.

Finish with mitigation, not just diagnosis. Say how you would stop the bleeding (roll back the deploy, drain the bad host, scale out, shed load), then how you would confirm the fix and what you would add to monitoring. That sequence is what separates SRE candidates from generalist debuggers. Our debugging interview guide and how to think out loud cover the narration habit in more detail.

SLIs, SLOs and Error Budgets: The Math You Need

An SLI (service level indicator) is a measured ratio of good events to total events, such as the share of HTTP requests that return successfully within 300 ms. An SLO (service level objective) is the target for that SLI over a window, such as 99.9 percent over 30 days. An SLA is a contract with consequences, usually looser than the internal SLO. The error budget is 1 minus the SLO.

Worked example 1: time-based budget

A service has a 99.9 percent availability SLO over a rolling 30-day window.

• Window: 30 days x 24 hours x 60 minutes = 43,200 minutes
• Error budget: 0.1 percent of 43,200 = 43.2 minutes

A 25-minute outage consumes 25 / 43.2 = about 58 percent of the month's budget. Common answers to memorize:

Worked example 2: request-based budget

The API serves 500 million requests a month with a 99.95 percent success SLO. The budget is 500,000,000 x 0.0005 = 250,000 failed requests. If a bad deploy fails 2 percent of traffic for 2 hours, and traffic is steady at about 694,000 requests per hour, that is 2 x 694,000 x 0.02 = about 27,800 failures, or roughly 11 percent of the budget.

Worked example 3: burn rate alerts

Burn rate is how fast you spend budget relative to the SLO window. A burn rate of 1 uses exactly the full budget over 30 days. A burn rate of 14.4 sustained for one hour uses 14.4 / 720 hours = 2 percent of a 30-day budget. Google's "The Site Reliability Workbook" recommends multiwindow, multi-burn-rate alerts along these lines:

• Page when 2 percent of budget burns in 1 hour (burn rate 14.4)
• Page when 5 percent burns in 6 hours (burn rate 6)
• Ticket when 10 percent burns in 3 days (burn rate 1)

Each alert pairs a long window with a short one (often one-twelfth of the long window) so it fires fast and resets fast once the problem clears. If you can explain why paging on a raw error-rate threshold produces either noise or missed incidents, and why burn rate fixes that, you will stand out.

Follow-up questions to expect: What do you do when the budget is exhausted (freeze risky launches, prioritize reliability work)? Why not aim for 100 percent (users cannot tell the difference, and it blocks all change)? How do you pick an SLI for a batch pipeline (freshness and correctness instead of request success)?

The Coding and Automation Round

SRE coding rounds test whether you can write tools that work on real data. Typical prompts:

• Parse an access log and return the top 10 IPs by request count, or the p99 latency per endpoint.
• Given a stream of timestamps, compute requests per second over a sliding window.
• Write a retry function with exponential backoff and jitter.
• Implement a simple rate limiter (token bucket or sliding window).

Here is a compact example of the log parsing style, in Python:

from collections import defaultdict
import math

def p99_by_endpoint(lines):
    latencies = defaultdict(list)
    for line in lines:
        parts = line.split()
        if len(parts) < 3:
            continue
        endpoint, ms = parts[1], parts[2]
        try:
            latencies[endpoint].append(float(ms))
        except ValueError:
            continue
    result = {}
    for endpoint, values in latencies.items():
        values.sort()
        idx = math.ceil(0.99 * len(values)) - 1
        result[endpoint] = values[idx]
    return result

What interviewers grade beyond correctness: skipping malformed lines instead of crashing, thinking about memory when the file is 50 GB (stream it, use a streaming quantile estimate), and explaining complexity. Python and Go are the strongest language choices. See our Python interview questions and Go interview questions for language-specific prep. The rate limiter prompt also appears as a design question, covered in our rate limiter system design guide.

Non-Abstract Large System Design

Non-abstract large system design (NALSD) is a design interview where you must put real numbers on your architecture: how many machines, how much bandwidth, how much storage, and what happens when a data center fails. Google describes the approach in a chapter of "The Site Reliability Workbook", and the format has spread to other SRE loops.

A standard system design interview is satisfied with "add a cache and a queue." An NALSD interviewer asks how big the cache is, how many nodes it needs, and what the hit rate must be for the database to survive. The flow usually goes:

1. Clarify requirements and SLOs. Throughput, latency targets, data size, durability.
2. Design for one machine. Does it fit? Usually not, which tells you where the pressure is.
3. Scale out with arithmetic. For example: 50,000 QPS, each server handles 2,000 QPS at target latency, so 25 servers. Add headroom for N+2 and a lost zone, and you need closer to 40 across three zones.
4. Plan for failure. Lose a zone, lose a dependency, double the traffic. Show the design still meets its SLO.
5. Add monitoring. Which SLIs, which alerts, which dashboards.

Practice back-of-the-envelope figures: a typical 10 Gbps NIC moves about 1.25 GB/s, a day has 86,400 seconds, and 1 million requests per day is roughly 12 per second on average (peaks are higher). Write the math down as you go so the interviewer can follow it.

Incident Response Behavioral Questions

Incident response questions check whether you stay calm, communicate clearly and fix systems instead of blaming people. Expect prompts like:

• Tell me about the worst production incident you were part of. What was your role?
• Describe a time you were paged for something outside your expertise.
• Tell me about a postmortem you wrote. What changed afterward?
• A product team wants to launch, but the error budget is spent. What do you do?
• Describe a time you reduced toil or alert noise.

Structure answers with STAR, but put the weight on actions and follow-through. Strong incident stories share the same beats: you declared the incident early, someone owned command and someone owned communication, you mitigated before you chased root cause, and the postmortem produced action items that actually shipped. Blameless language matters. "The deploy pipeline allowed an untested config to reach production" lands better than "a junior engineer pushed a bad config." Our top 50 behavioral interview questions list has more prompts to build your story bank from.

A Four-Week SRE Interview Prep Plan

This plan assumes about 8 to 10 hours a week. Shift time toward your weaker side.

In the final week, run one full mock loop back to back. Afternoon fatigue is real, and troubleshooting gets sloppy when you are tired.