We use analytics and advertising cookies to understand how the site is used and whether our ads on Facebook and Instagram work. They are set only if you accept. See our Privacy Policy for details.
Prep for Google's SRE loop: coding, non-abstract large system design (NALSD), Linux and troubleshooting depth, and Googleyness.
Google invented the SRE role, and its loop reflects it. Expect coding, a Non-Abstract Large System Design (NALSD) interview, a round on systems depth - Linux internals, networking and troubleshooting a misbehaving production system - and a Googleyness and leadership round. NALSD is Google SRE's own format: every SRE candidate gets one, and it asks you to design a credible system for a specific large-scale problem and then prove it is real, with concrete estimates of machines, disk, network and memory, and a plan for surviving component and datacenter failures. Google hires SREs on two closely related tracks - software engineering (SRE-SWE) and systems engineering (SRE-SE) - and the balance between coding and systems depth shifts with the track and level, so confirm with your recruiter which one you are interviewing for. As with every Google hire, a hiring committee reviews the packet and team matching follows.
The NALSD round. Practice designs where you must size the system: QPS, bytes per request, disk and network throughput, machine counts. Read the NALSD chapter of Google's SRE Workbook and work its example end to end.
The systems round. Know your way around processes, signals, file descriptors, /proc, permissions and the standard debugging tools (top, strace, lsof, tcpdump, df, iostat), and when you would reach for each.
Linux internals questions: virtual memory and paging, the page cache, scheduling, system calls, what happens when a process forks or runs out of memory.
Troubleshooting and NALSD both lean on it: TCP handshake and congestion, DNS resolution, HTTP, load balancing and what changes when traffic crosses datacenters.
The coding rounds. SRE-SWE candidates should prepare as for a Google SWE loop at Medium difficulty; SRE-SE candidates still need clean, correct code for practical problems.
Hash maps, heaps, trees and queues come up in coding and in NALSD when you choose how data is stored and indexed.
Not required - use the language you know best - but a scripting language is the natural fit for log-parsing and automation problems, and many SRE candidates choose Python.
One Googleyness round. Prepare stories about an outage you handled, a postmortem that changed something, pushing back on an unsafe launch, and reducing toil.
Curated walkthroughs for the bounded designs that show up in Google's system design rounds. Capacity estimation, architecture, deep-dives, and trade-offs.
Time-series DBs (Prometheus, M3, VictoriaMetrics), trace sampling, exemplars, OpenTelemetry, alerting, and the cardinality explosion that turns a $10K/month platform into a $1M/month outage.
L4 vs L7, consistent hashing, health checks, connection draining, and the difference between a fleet that survives partial failures and one that cascades into outage.
Consistent hashing, eviction, replication, and what really happens when a single hot key takes down the cluster.
The internet's phone book. A globally distributed, read-dominated, cache-everywhere hierarchy that has to answer in single-digit milliseconds and never go down.
Raft leader election, log replication, snapshots - and the CAP theorem in operational practice. The substrate every other distributed system stands on.
Batch vs streaming, lambda vs kappa, the warehouse-vs-lakehouse decision, and dimension modeling that survives schema drift.
Sample STAR answers, common prompts, pitfalls, and follow-up strategies for the behavioral themes that decide Google's loop.
Not a soft round. Structured questions about collaboration, ambiguity, learning, and motivation - scored against rubrics, not vibes.
The honesty test. Can you own a missed commitment or production incident specifically and without flinching - or do you blame the team, the requirements, or the on-call rotation?
Microsoft's Growth Mindset core. Also tested at Google, Anthropic, and any company that screens for self-awareness. The signal is whether you actually changed.
Google scores how you think more than what you already know - decompose ambiguity, reason out loud, and adjust as new information arrives.
Tested at every level, scored harder at senior. Did you take responsibility for outcomes - or just for tasks?
The site reliability engineer learning path and the judgment cases that mirror this loop's execution and metrics questions.
Total comp ranges, base, equity, and bonus across the levels tested in this loop. Aggregated from public sources.
5 Site reliability engineer levels covered. Updated 2026-05.
649 MCQs and 245 coding challenges, grouped by topic. Free preview shows question titles - premium unlocks full content.
Behavioral and system design rounds reward practice with a live AI interviewer that probes follow-ups, not silent reading.
Start an AI mock interview →Non-Abstract Large System Design is an interview format Google SRE developed, and every SRE candidate gets one. You design a system for a specific large-scale problem, then make it concrete: estimate resource needs, check the design against real limits on disk, network and machines, and show how it survives failures. Google's SRE Workbook has a chapter on the method with a worked example.
A typical system design round can stay at the level of boxes and arrows. NALSD asks whether the design could actually be built and run: how many machines, how much bandwidth, where the bottleneck is, and what happens when a datacenter goes away. Expect to iterate - start with something that works in principle, then improve and scale it under the interviewer's questions.
Yes. SRE is an engineering role at Google and coding is part of the loop. Software-engineering-track (SRE-SWE) candidates face a bar similar to SWE coding rounds; systems-engineering-track (SRE-SE) candidates often get more practical problems but still need to write correct, readable code. Ask your recruiter which track and how many coding rounds you have.
Practice talking through outages out loud: what you check first, why, and what each result rules in or out. Be explicit about mitigating user impact before chasing root cause. Brush up on Linux internals and networking so you can explain what is happening underneath a symptom such as high load, a full disk, or intermittent timeouts.
They are free on sre.google and directly relevant: the SRE book covers SLOs, error budgets, monitoring, incident response and postmortems, and the SRE Workbook includes the NALSD chapter. You do not need to memorize them, but the vocabulary and the way of thinking show up throughout the loop.