Google SRE Interview Questions: Rounds, Process, and How to Prepare

Reading time: 12 minutes
Best for: Software engineers preparing for Google's SRE interview loop

This guide breaks down the most common Google SRE interview questions, explains what each round is actually testing, and shows you how to prepare based on your specific track. Google SRE interviews vary significantly: a Google SRE SE interview (systems-heavy) looks very different from a Google SRE SWE interview (software-heavy). This breakdown helps you figure out which one you are facing and what to do about it.

---

The biggest gotchas: What catches candidates off guard

Gotcha 1: Google SRE is not one uniform interview

Google has long treated SRE as a hybrid of software engineering and operations, with distinct tracks: SRE-Systems Engineer (SRE-SE) and SRE-Software Engineer (SRE-SWE). This distinction directly affects your interview.

Some Google SRE loops are heavily coding-focused with multiple algorithmic rounds. Other loops, particularly Systems Engineer tracks, include scripting, troubleshooting, NALSD (non-abstract large system design), Unix/Linux deep dives, and Googleyness rounds with much less algorithmic emphasis.

This explains why candidate reports seem contradictory. One person says "it was all LeetCode," another says "it was all Linux and troubleshooting." Both are true because they were on different tracks.

Confirm your track with your recruiter early. Ask explicitly whether your loop is systems-heavy or software-heavy. This determines everything else about your preparation.

Gotcha 2: It tests whether you can operate across both coding and ops

The Google Site Reliability Engineer interview is often underestimated because candidates prepare for one mode and get tested on both. Coding and algorithmic thinking show up, but so do Linux internals, troubleshooting, networking, and practical scripting.

In systems-heavy tracks, the interview is closer to "can you think like a reliability engineer who can also code?" than "can you solve interview puzzles?" Even in software-leaning tracks, operational mindset matters. You are evaluated on whether you think about failure modes and production behavior while you code.

Gotcha 3: There is no single fixed loop

There is no universal five-round format. Some Systems Engineer / SRE loops include Scripting, Troubleshooting, NALSD, Googleyness, and Unix/Linux, all on Google Doc. Other loops are coding-heavy. Both are real Google SRE interviews.

Prepare for recurring categories and adapt based on what your recruiter tells you about your specific loop.

Gotcha 4: You may have to code without an IDE or even a problem statement

Many Google SRE rounds happen in a shared Google Doc with no execution and no autocomplete. Some candidates report that interviewers did not paste the problem statement at all; everything was explained verbally.

This tests whether you can listen, restate, clarify, and solve without tooling to catch mistakes. Practice writing code you can trace through manually, and get comfortable solving problems explained out loud.

---

What makes Google SRE unique

Linux and OS internals are first-class pillars, not side material

For systems-heavy Google SRE tracks, Linux, Unix, and operating-systems internals are central preparation pillars, not a miscellaneous review section to skim at the end.

Candidates report being asked about inodes, filesystem behavior, performance commands, signals, processes, virtual memory, system calls, shell parsing, boot sequences, and more. Recruiter guidance for systems-heavy tracks explicitly emphasizes processes vs threads, context switching, concurrency primitives, scheduling, deadlock and livelock, kernels and libraries, system calls, file systems, permissions, and memory management.

The bar is not surface-level familiarity with commands. It is mechanistic understanding: not merely "I know the command," but "I understand what is happening in the kernel, filesystem, network stack, or shell when this operation happens."

Networking deserves its own prep lane

Networking is important enough that it should not be treated as a quick subsection under Linux or troubleshooting. It deserves dedicated preparation time.

Candidates report questions on the OSI model, TCP handshake, packet capture with tcpdump, DNS and tools like nslookup, dig, ping, and traceroute, SSH diagnosis, ports, proxies, and basic web/networking fundamentals. Networking often appears as part of a larger diagnostic conversation in troubleshooting or architecture rounds rather than as isolated trivia.

If you are on a systems-heavy path, do not underweight networking.

Troubleshooting rounds reward structured reasoning, not instant answers

The troubleshooting round is especially important because the uncertainty is often deliberate. You may be evaluated on how you reason when the answer is not immediately obvious.

Public reports describe architecture-based scenario rounds where the interviewer asks the candidate to isolate causes across performance, memory, storage, I/O, load balancing, and security layers. The expectation is that you discuss multiple hypotheses, prioritize them, explain what evidence would confirm or falsify each one, and converge on a fix.

Good troubleshooting answers look hypothesis-driven and prioritized, not like an unstructured command dump. The interview may not reward instant answers as much as calm, structured diagnosis.

System design / NALSD is more concrete and operational than classic product design

When system design or NALSD appears in Google SRE loops, it is usually more concrete and operational than many classic product-system-design interviews. The examples are not abstract "design Instagram" conversations. They include migrating live users from NoSQL to SQL with no performance impact, designing a caching server, designing a Netflix streaming engine, and proposing a 3-tier architecture plus debugging strategy with Linux and network-level diagnosis.

If this round appears, the bar is usually operational concreteness: traffic flow, failure modes, monitoring, debugging, reliability tradeoffs, and how the system actually behaves in production.

---

How Google evaluates SRE candidates

Based on candidate reports and recruiter guidance, Google SRE interviews evaluate these dimensions:

• Problem understanding under ambiguity: Can you make sense of a vague or verbal prompt?
• Systems depth: Do you understand OS, networking, and infrastructure at a mechanistic level?
• Coding and scripting fluency: Can you write clean code under constrained tooling?
• Troubleshooting methodology: Do you debug with structured, hypothesis-driven process?
• Operational judgment: Do you think about failure modes and production safety as you design?
• Communication clarity: Can you explain reasoning in a way that builds confidence?
• Googleyness: Do you show ownership, collaboration, and judgment under pressure?

Validation discipline matters

A Google L5 candidate reported being rated only "Lean Hire" because they discussed tests instead of writing them. Finishing the implementation is not enough. Validate it visibly: write test cases, dry-run your code, show you are checking your own work.

---

Google SRE interview rounds: Core topics and what they're really testing

This section breaks down the recurring round types in Google SRE interviews, what you should prepare for each, and what the interviewer is actually evaluating. Understanding these rounds is essential for anyone preparing for a Google Site Reliability Engineer interview.

Recruiter / initial screen

Core topics to prepare: role fit and track alignment, projects you have worked on, why Google, why SRE, high-level communication and clarity, baseline exposure to reliability, on-call, production systems, or infrastructure.

What this round is really checking: whether your background matches the flavor of SRE they are hiring for, whether you sound like someone who understands the role beyond buzzwords, and whether you communicate clearly enough to move forward.

Example questions:

• "What was the last thing you worked on?"
• "What have you done in the past?"
• "Why Google?"
• "Tell me about yourself."

Coding / scripting round

Core topics to prepare: data structures and algorithms fluency, practical coding and scripting, arrays, strings, hash maps, intervals, traversal, graph basics (breadth-first search, depth-first search), filesystem-flavored utilities, stream processing, writing clean code in plain text, tracing through code without execution, edge cases and validation, explaining why you chose a method.

For systems-heavy tracks: expect more practical scripting and utility-building flavor. Emphasis may be more on logic, correctness, and reasoning than fancy optimization.

For software-leaning SRE tracks: this may look much closer to a normal Google coding round.

What this round is really checking: whether you can think clearly and code under constrained tooling, whether your solution is understandable and defensible, and whether you validate your work instead of just stopping after implementation.

Example questions:

• "Find average of last n elements in a stream; follow-up: ignore a few highest values."
• "Room booking: book(start_time, end_time) returns True/False."
• "Given filesystem APIs like fs.GetDirectoryChildren() and fs.Delete(), implement deleteDirectoryTree(path)."
• "Add numbers as strings; return without leading zeros."
• "Write a script to find duplicates."

Linux / Unix / operating systems round

Core topics to prepare: processes vs threads, process lifecycle, concurrency primitives (locks, mutexes, semaphores, monitors), deadlock and livelock, scheduling basics, context switching, system calls, kernels and libraries, memory management, permissions, file systems, shell behavior, signals, boot and process internals, practical command-line reasoning.

What this round is really checking: whether you understand systems under the hood, not just commands by habit. Whether you can reason about behavior, performance, and failure modes. Whether your systems knowledge is mechanistic rather than superficial.

Example questions:

• "What is an inode? What information does it store?"
• "What is the significance of SIGKILL / kill -9?"
• "Code the tail command in Linux when handling a large dataset."
• "What will happen if you run ls *?"
• "How does the shell parse your input and execute a command like rm?"

The Google SRE troubleshooting interview

The Google SRE troubleshooting interview is one of the most distinctive parts of the systems-heavy loop. Here is what to prepare and what interviewers are really evaluating.

Core topics to prepare: hypothesis-driven debugging, narrowing scope, isolating layers of failure, SSH/debug access failures, process/memory/disk/I/O bottlenecks, network path diagnosis, service dependency failures, observability mindset, what to check first, second, third, and why.

What this round is really checking: whether you stay calm under uncertainty, whether you can reason without needing the answer immediately, whether your debugging process is structured and prioritized, and whether you can collaborate with the interviewer in a back-and-forth diagnosis.

Example questions:

• "What if I can't SSH into a remote machine? What steps would you take?"
• "How would you capture and analyze network traffic?"
• "A system is running out of PIDs. How would you detect the issue and stop it?"
• Scenario-based infrastructure debugging covering performance, I/O, memory, storage, load balancing, and firewalls.

Networking round

Core topics to prepare: OSI model, TCP/IP basics, TCP handshake, DNS, HTTP methods and web basics, packet loss, routing path issues, proxies (including transparent proxies), packet analysis tools, SSH and ports, basic network troubleshooting commands.

What this round is really checking: whether you can reason about traffic moving through a system, whether you know how to isolate where along the path a problem may exist, and whether you understand common tools well enough to use them intentionally.

Example questions:

• "Explain the OSI model."
• "How does the TCP handshake work?"
• "What are the HTTP methods?"
• "Basic networking commands: nslookup, dig, ping, traceroute. When would you use each?"
• "How would you capture and analyze network traffic with tcpdump?"
• "How would you identify packet loss along a network path?"
• "How can you tell whether a proxy, including a transparent proxy, is in use?"

System design / NALSD / architecture and debugging round

Core topics to prepare: concrete system design, reliability tradeoffs, migration and rollout thinking, caching, scaling, debugging strategy tied to architecture, operationalization, monitoring and observability, failure modes, production readiness, numbers and constraints, how traffic and data flow through a real system.

What this round is really checking: whether you can reason about real production systems, not just draw boxes. Whether you can connect architecture to debugging, monitoring, and operations. Whether you can discuss tradeoffs in a grounded, concrete way.

Example questions:

• "Design a 3-tier architecture and propose a debugging strategy."
• "Design a caching server."
• "Design a Netflix streaming engine."
• "Migrate live users from NoSQL to SQL without affecting users or performance."

Googleyness / leadership round

Core topics to prepare: teamwork, conflict handling, feedback, working in diverse teams, ambiguity, pivoting when circumstances change, positive impact, ownership, judgment under pressure, learning from failure, why Google and why this role.

What this round is really checking: whether people would trust you in high-stakes collaborative environments, whether you can work well during incidents and ambiguity, and whether you show maturity, reflection, and ownership.

Example questions:

• "What does diversity mean to you?"
• "Tell me about a time when you had to pivot midway at your workplace."
• "Tell me about a time your actions had a positive impact on your team."
• "Tell me about a time when you worked in a diverse team. What benefits did you get? How did you handle conflicts and feedback?"

Hiring manager / role-knowledge round (when present)

Core topics to prepare: incident response experience, postmortems, on-call ownership, infrastructure as code, security for deployed services, networking fundamentals in real systems, reliability improvements you have driven, scaling or hardening production systems.

What this round is really checking: whether you have real operational maturity, whether your past experience maps to the role, and whether you can speak concretely about production ownership.

Example questions:

• IaC tools such as Terraform, Ansible, Puppet
• "Tell me about troubleshooting real incidents during on-call or postmortem handling."
• "How does the TCP handshake work?"
• "When you deploy a web server, what security measures do you consider?"

---

Past Google SRE interview questions by round

These are real Google SRE interview questions candidates have reported facing, organized by category. For each, we have included what the interviewer is actually testing. Use these to practice for your Google Site Reliability Engineer interview.

Google SRE Linux, Unix, and operating systems questions

What is an inode? What information does it store, and what does it not store?
This is not just a vocabulary test. The interviewer is often checking whether you actually understand how Unix-like file systems work under the hood. A strong answer should explain what metadata lives in the inode, what is stored elsewhere (like the filename, which lives in the directory entry), and why that distinction matters in practice.

What is the significance of SIGKILL / kill -9? When would you use it, and what are the downsides?
This tests whether you understand signals as part of real process management rather than as a memorized command. Strong candidates usually explain not just what kill -9 does, but why it bypasses cleanup handlers and why that matters operationally.

Implement or explain how you would implement the Linux tail command for a very large file.
This is a good example of how Google SRE questions can blend systems thinking with coding. The interviewer is not only testing whether you know the command, but whether you understand efficient file access, memory constraints, and how to reason about large inputs.

What happens if you run ls * in the shell?
This kind of question is more revealing than it may first appear. It tests whether you understand shell expansion, argument passing, and what happens before the called program even receives control.

How does the shell parse input and execute a command like rm?
This pushes deeper into system behavior. The interviewer may be probing whether you understand parsing, wildcard expansion, option handling, process creation, and how user input becomes an executing program.

Google SRE coding and scripting questions

Find the average of the last n elements in a stream. Follow-up: now ignore a few of the highest values.
This is a good example of a Google-style question that starts simple and then evolves. The interviewer is often checking whether you can handle changing constraints cleanly, choose appropriate data structures, and explain the tradeoffs in your approach.

Given a file system structure, find the size of a folder.
This looks straightforward, but it is useful because it combines traversal, recursion or iteration, and practical systems-flavored reasoning. It is a good example of coding that feels more relevant to infrastructure and real systems than a purely abstract puzzle.

You are given filesystem APIs like fs.GetDirectoryChildren() and fs.Delete(). Implement deleteDirectoryTree(path).
This is exactly the kind of systems-flavored coding question that can show up in SRE loops. The interviewer can use this to test recursion, correctness, ordering, edge cases, and whether you think about operational safety.

Implement book(start_time, end_time) returns True/False for a room booking system.
This is a more classic interval-style problem, but still very realistic in interview settings because it tests reasoning, edge cases, and correctness in a format that is quick to discuss and extend.

Write a script to find duplicates.
In systems-heavy SRE tracks, scripting questions like this may matter just as much as classic algorithmic questions. The interviewer is usually looking for practical logic, clarity, and whether you can think through inputs, outputs, and edge cases without overcomplicating things.

Google SRE troubleshooting interview questions

The Google SRE troubleshooting interview tests structured diagnosis under uncertainty. Here are real questions candidates have faced:

You cannot SSH into a remote machine. What steps would you take?
This is a classic troubleshooting prompt because it tests whether you can reason in layers rather than panic. A strong answer usually works from the outside in: network path, DNS, routing, port reachability, credentials, host state, SSH daemon state, firewall rules, and so on.

How would you capture and analyze network traffic to debug an issue?
This lets the interviewer test whether you know when and how to use tools like tcpdump, and whether you understand what evidence you are actually trying to gather rather than just naming tools mechanically.

A system is running out of PIDs. How would you detect the issue and how would you stop it?
This is a great example of a systems-heavy debugging question. It tests whether you can move from symptom to diagnosis, identify likely causes such as runaway process creation or limits misconfiguration, and think about both immediate containment and root-cause prevention.

Here is an architecture / infrastructure scenario with performance, memory, storage, I/O, load-balancing, or firewall symptoms. Talk me through how you would isolate the issue.
This kind of prompt is valuable because it reveals whether the candidate can form hypotheses, prioritize likely causes, and use a structured debugging flow instead of jumping randomly between guesses.

Google SRE networking questions

Explain the OSI model.
This may sound basic, but it is often used to check whether the candidate can reason cleanly across layers when diagnosing issues. Strong answers usually stay practical rather than becoming a memorized lecture.

How does the TCP handshake work?
This is a classic networking fundamentals question and often appears because it connects directly to real production troubleshooting. A good answer should be crisp, accurate, and tied to practical consequences such as connection establishment failures or latency.

What are nslookup, dig, ping, and traceroute used for? When would you use each?
This is more useful than just "define these commands" because it checks whether you know what kind of signal each tool gives you and where it fits into a diagnostic workflow.

How would you identify packet loss along a network path?
Questions like this are good because they test whether the candidate can reason about where in the path an issue may be happening, what evidence would confirm that, and what tool or measurement is appropriate.

How can you tell whether a proxy, including a transparent proxy, is in use?
This is a strong systems/networking interview question because it checks whether the candidate can reason about observed behavior, headers, path differences, and unexpected intermediaries in real network flows.

Google SRE system design and NALSD questions

Design a caching server.
This is a good example of a systems design question that is concrete enough to surface real tradeoffs: eviction policy, consistency, invalidation, failure handling, memory pressure, and observability.

Design a Netflix streaming engine.
This is broader, but it lets the interviewer assess whether the candidate can think about content delivery, scale, latency, buffering, reliability, and end-to-end system behavior under realistic production constraints.

Migrate live users from NoSQL to SQL without affecting users or performance.
This is a very strong SRE-flavored system design prompt because it goes beyond architecture diagrams and forces the candidate to think about rollout safety, migration strategy, consistency, fallbacks, and operational risk.

Design a 3-tier architecture, then explain how you would debug issues across it.
This is especially good because it connects design with operations. The interviewer is not only asking whether you can describe the architecture, but whether you can reason about traffic flow, dependencies, bottlenecks, and what to inspect when something goes wrong.

Google SRE Googleyness and leadership questions

Tell me about a time you had to pivot midway through a project or change direction at work.
This tests adaptability, judgment, and communication under changing constraints. Strong answers usually show how the candidate reassessed the situation, aligned stakeholders, and kept execution moving.

Tell me about a time your actions had a positive impact on your team.
This helps the interviewer assess ownership and whether the candidate creates leverage around them rather than operating in a narrow individual-contributor silo.

Tell me about a time you worked in a diverse team. What benefits did that bring? How did you handle conflict or feedback?
This is important because Googleyness rounds are not fluff. For SRE roles, trust, communication, and mature collaboration matter in high-pressure situations like incidents and cross-team operational work.

What does diversity mean to you?
This kind of question may appear directly, and candidates should be ready to answer it thoughtfully rather than dismissing it as a generic corporate prompt.

---

---

Recommended framework by round type

Coding / scripting approach

Restate the problem, especially if it was delivered verbally. Many Google SRE rounds do not paste the problem statement. You need to demonstrate that you understood the prompt correctly before you start solving.

Clarify constraints and edge cases upfront. Ask about input size, expected behavior on invalid input, whether duplicates matter, what should happen at boundaries. This shows mature engineering thinking.

Write clean, readable code without relying on execution. You may be in a Google Doc with no syntax highlighting or autocomplete. Structure your code so it is easy to follow and easy to dry-run manually.

Validate with dry runs and test cases. Do not stop after writing the code. Walk through at least one example input step by step. Write out a few test cases explicitly if time allows. This is often the difference between "Leaning Hire" and "Strong Hire."

Linux / OS approach

Explain what happens under the hood, not just command names. If you mention a command, be ready to explain what it does at the system level. What system calls are involved? What kernel behavior is triggered?

Connect behavior to the kernel, filesystem, or process model. When asked about signals, explain the process lifecycle. When asked about inodes, explain filesystem structure. When asked about context switching, explain scheduler behavior.

Be ready for "why" follow-ups. The interviewer will often push past your initial answer. Why does it work that way? What are the tradeoffs? What would happen if X instead of Y?

Troubleshooting approach

Start broad, narrow systematically. Do not jump to a specific cause immediately. Start with the most likely categories of failure and systematically narrow down.

Form hypotheses and prioritize by likelihood. Explain what you suspect and why. Prioritize based on frequency, impact, and ease of checking.

Explain what signal would confirm or falsify each hypothesis. This is what separates structured debugging from random guessing. For each hypothesis, describe what evidence would prove it right or wrong.

Collaborate with the interviewer. Troubleshooting rounds are often a dialogue. Ask clarifying questions. Respond to hints. Treat it as a joint investigation, not a performance.

System design / NALSD approach

Ground everything in operational reality. Do not just draw boxes. Explain what happens when traffic flows through them, what fails, how you detect failure, and how you recover.

Connect architecture to debugging, monitoring, and failure modes. For every component, you should be able to explain what metrics you would watch, what alerts you would set, and what you would check first if something went wrong.

Discuss migration, rollout, and production readiness. Especially for SRE-flavored design prompts, the interviewer often cares about how you would safely deploy, roll back, and operate the system, not just how it works in the happy path.

Be concrete about numbers and constraints. Estimate traffic, storage, latency. Use numbers to justify decisions rather than hand-waving.

Googleyness approach

Use structured storytelling. Situation, action, result. Keep it concise. Do not ramble.

Show ownership, judgment, and reflection. The interviewer wants to see that you take responsibility, make thoughtful decisions under pressure, and learn from experience.

Connect examples to reliability-relevant traits. For SRE roles, the most compelling examples often involve incident handling, on-call ownership, cross-team collaboration, or making hard tradeoffs under time pressure.

---

How to prepare for the Google SRE interview

Effective Google SRE interview prep is simulation-based, not syllabus-based. Here is a phased approach.

Phase 1: Confirm your track

Ask your recruiter whether your loop is systems-heavy or software-heavy. This fundamentally changes what to prioritize. Preparing for the wrong track is the most common avoidable mistake.

Phase 2: Foundational knowledge

Once you know your track, build depth in the relevant areas.

For systems-heavy tracks:

• Linux/OS internals: processes, threads, concurrency primitives, system calls, memory management, file systems, signals, shell behavior
• Networking: TCP/IP, OSI model, DNS, HTTP, packet analysis tools, routing, proxies
• Troubleshooting methodology: hypothesis-driven debugging, isolating layers of failure, observability mindset
• Practical scripting: file manipulation, parsing, automation, utility-building

For software-leaning tracks:

• Data structures and algorithms: arrays, strings, hash maps, trees, graphs, breadth-first and depth-first search, dynamic programming
• System design fundamentals: scalability patterns, caching, sharding, reliability tradeoffs
• Operational awareness: failure modes, monitoring, production readiness

Phase 3: Simulate realistic conditions

The best Google SRE interview prep is practicing under interview conditions:

• Coding without an IDE: Write in a plain text editor or Google Doc with no execution or autocomplete
• Verbal problem delivery: Have someone read problems aloud without showing you the text
• Troubleshooting role-play: Work through failing system scenarios out loud, forming hypotheses
• Behavioral storytelling: Practice Googleyness stories in two minutes or less with clear structure

Phase 4: Mock interviews

Once comfortable with patterns, shift to performance mode. Solve problems under time pressure. Google SRE mock interviews with experienced interviewers can reveal blind spots and calibrate whether your performance would actually pass.

---

Frequently asked questions about the Google SRE interview

Q: Is it more like a coding interview or an ops interview?
A: Depends on your track. Systems-heavy leans toward Linux, troubleshooting, networking. Software-heavy leans toward classic coding. Most test both.

Q: How do I know which track I'm on?
A: Ask your recruiter explicitly. They should tell you whether your loop is systems-heavy or software-heavy.

Q: What if my rounds differ from what's described here?
A: Normal. Round composition varies by team, level, and location. These are recurring categories, not a fixed template.

Q: How much Linux/OS depth do I need?
A: For systems-heavy tracks, it is a first-class pillar: processes, threads, concurrency, system calls, file systems, signals, memory management at mechanistic depth. For software-heavy, less central but still valuable.

Q: Can I use AI tools during the interview?
A: Assume you will need to interview without AI assistance unless your recruiter explicitly says otherwise.

Q: What if the problem is delivered verbally?
A: Common and intentional. Practice restating and clarifying before solving.

Q: How important is Googleyness?
A: Very. One candidate was rejected specifically because the Googleyness round was weak despite strong technical performance.

Q: What's the biggest mistake candidates make?
A: Preparing for the wrong track.

---