Google Software Engineer System Design Interview

The coding rounds decide whether Google believes you can do the job. The system design round plays a large role in deciding what level that job is.

This is one of the few interviews where the same answer can produce different outcomes depending on the level being assessed. An L4 candidate and an L6 candidate may be given exactly the same prompt, but they are not being evaluated against the same expectations. A clean architecture, sensible trade-offs, and a reasonable deep dive can be enough for a strong L4 performance. The same answer from an L6 candidate is one of the most common paths to a down-level decision.

There is a second distinction that changes how this round should be prepared for. Most guides describe Google's system design interview as though it were a single interview format. In practice, there are two. Depending on the role and the interviewer's background, candidates are usually assessed through either a classic distributed-systems design discussion or an ML system design discussion. The structure is different, the areas of depth are different, and the mistakes that matter are different.

Understanding which version you are likely to face is every bit as important as understanding the prompt itself.

Most system design preparation assumes there is a single Google system design interview. One of the more useful corrections from the mock interviews behind this guide is that there are really two, and they reward different kinds of depth.

The classic distributed-systems version is the one most software engineers expect. Prompts tend to involve messaging systems, storage systems, rate limiting, real-time communication, scheduling, or other large-scale infrastructure problems. The discussion gradually narrows toward the engineering decisions underneath the architecture. Storage choices, consistency guarantees, partitioning strategy, latency budgets, failure modes, and operational trade-offs become increasingly important as the interview progresses.

The ML version starts from a different set of questions and often stays there. Search, recommendations, ranking systems, retrieval pipelines, and generative AI products are common territory. The conversation spends less time on replication strategy and more time on objectives, labels, model architecture, training, serving, evaluation, and the quality of the feedback loops that improve the system over time.

The distinction matters because the overlap is smaller than many candidates assume. A distributed-systems interview rewards a deep understanding of how data moves through a system and how the system behaves under failure. An ML interview rewards a deep understanding of how information becomes predictions and how those predictions are measured. Both are system design interviews. The places where they generate signal are different.

In many cases you can predict which version is coming. The role is one clue. The interviewer's background is another. Recruiters will often tell you directly if asked.

One pattern from a recent mock interview on Prepfully is worth keeping in mind. A candidate interviewing with a conversational AI team expected the discussion to center on conversational AI. The interviewer instead spent most of the session exploring the recommendation systems the candidate had built previously. Interviewers are often looking for depth in a domain you already know well, which means your own experience can influence the shape of the interview almost as much as the team description.

The distributed-systems and ML versions of the interview diverge quickly, but they tend to reward the same underlying behaviours.

The first appears in the opening minutes. Requirements gathering is not a formality before the design begins. It is part of the design. Several of the weaker performances reviewed for this guide stemmed from the same pattern: a candidate recognized the system immediately, started designing immediately, and discovered twenty minutes later that they had optimized for the wrong problem. At Google's scale, a missing non-functional requirement can invalidate an otherwise reasonable architecture. Expected traffic, latency requirements, availability targets, consistency expectations, and read-write patterns shape the design that follows, which is why experienced interviewers pay close attention to how those assumptions are established.

The second is proactivity.

One of the clearest differences between levels is not technical knowledge but who is driving the conversation. Strong candidates do not wait for the interviewer to identify the difficult parts of the problem. They identify them themselves. They surface trade-offs before being asked. They call out risks before the interviewer goes looking for them. Across both interview formats, much of the senior signal comes from demonstrating judgment without requiring prompts.

The third is pacing.

The sections that carry the most weight tend to arrive late in the interview. In the distributed-systems version, that usually means trade-offs, bottlenecks, and failure modes. In the ML version, it often means evaluation. Candidates who spend too much time refining requirements or expanding the initial architecture frequently discover that the highest-signal discussion is compressed into the final few minutes. The strongest interviews generally leave enough time for the interviewer to explore the consequences of the design, because that is often where the most useful signal is generated.

These themes show up repeatedly because they sit above the specifics of the prompt. Whether the discussion is about message queues, recommendation systems, ranking models, or retrieval pipelines, the interviewer is still evaluating how you handle ambiguity, how you make decisions, and how you navigate the trade-offs that follow from them.

Ex-Google interviewers described a fairly consistent shape to these conversations. Requirements come first, followed by a high-level architecture, a deeper discussion of one or two critical components, trade-offs and failure modes, and a brief wrap-up. Most candidates can navigate the first two phases. The deep dive and the trade-off discussion are where levels begin to separate.

Requirements: Finding the Real Problem

The first few minutes often determine whether the rest of the interview is productive.

In one pub/sub mock, the candidate quickly established scale, scoped authentication and subscription management out of the discussion, and started designing the system. The interviewer immediately pulled the conversation back toward delivery guarantees, message ordering, and throughput ceilings. Authentication mattered. Subscriptions mattered. Neither was likely to shape the architecture as much as the messaging guarantees at the center of the system.

That pattern shows up repeatedly in Google system design interviews. Strong candidates are not gathering requirements mechanically. They are identifying which requirements will eventually dominate the design. A messaging system lives or dies on different constraints than a storage platform or a recommendation engine, and interviewers expect those distinctions to emerge early.

The level signal often appears before the architecture. An L4 candidate works effectively with the requirements provided. An L5 candidate begins surfacing important requirements independently. An L6 candidate frequently identifies the constraint that will drive most of the design before the interviewer has to point toward it.

The Deep Dive: Where Architecture Stops and Engineering Starts

Most system design preparation focuses on building a vocabulary. Consistency models, caching strategies, partitioning schemes, storage systems, delivery guarantees. By the time a candidate reaches a Google system design round, interviewers usually assume that vocabulary exists. The discussion is more interested in whether the decisions behind it hold together.

Consistency is a common example. Most engineers understand the difference between strong consistency and eventual consistency. The deeper discussion begins once the interviewer asks whether the consistency requirement established at the start of the interview survives contact with the architecture that follows. If writes are acknowledged before replicas catch up and the primary fails, some acknowledged writes may disappear. Whether that outcome is acceptable depends entirely on the requirement the system was designed around in the first place.

Storage decisions are often explored the same way. One candidate in a mock reached for a time-series database to back a message queue. The interviewer pushed immediately on the access pattern. A message queue behaves like a durable, ordered log with delivery guarantees. A time-series database is optimized for a different workload. The discussion was never about remembering database categories. It was about choosing a storage model that matched the behavior the system required.

Caching discussions tend to follow a similar path. Most candidates can explain where a cache might sit and how data reaches it. The more revealing question is what happens once the cache becomes responsible for holding a latency target under peak load. A cache stampede caused by hot keys expiring simultaneously can create more damage than the latency problem the cache was introduced to solve. Candidates who proactively discuss invalidation, request coalescing, expiry jitter, or the trade-offs between write-through, write-back, and write-around strategies tend to sound like engineers who have operated systems rather than simply studied them.

Messaging systems produced some of the clearest distinctions across the mock interviews. One candidate proposed using timestamps to establish ordering across queue instances running in multiple regions. The interviewer stopped there and challenged the assumption underneath the design. Clocks across distributed systems are not synchronized closely enough to provide a reliable global ordering guarantee. The conversation moved toward partition-based sequencing and explicit handling of cross-partition ordering. Another candidate described slowing retries when consumers fell behind. The approach was correct. What elevated the answer was recognizing the problem as back pressure and discussing it in those terms. Delivery guarantees, idempotency, ordering, and consumer lag all sit in the category of concepts most experienced engineers have encountered before. The interview is exploring whether those concepts remain useful once they become design constraints.

A good deep dive usually feels less like defending a diagram and more like defending the assumptions hidden underneath it. A queue that looked obvious in the architecture diagram suddenly becomes fifteen minutes of discussion around ordering, retries, throughput ceilings, and consumer behavior. A storage layer becomes a conversation about consistency, access patterns, and operational trade-offs. The component itself is rarely the point. The engineering decisions attached to it are.

The Latency Budget

The most instructive moment across all of the distributed-systems mocks came from a live chat design.

The candidate routed messages through a queue, then a worker, then a NoSQL database, and finally relied on change-data-capture events to distribute messages to connected viewers. On the whiteboard the architecture looked entirely reasonable. The problem only became visible once the interviewer started tracing the latency budget.

Every step added delay. Time entering the queue. Time spent waiting in the queue. Time writing to a database optimized for durability. Time waiting for a CDC process to observe that write and emit an event. None of those decisions were unreasonable in isolation. Together they formed a critical path that had no realistic chance of satisfying a 500 millisecond delivery target.

The persistence path and the delivery path had become the same path.

Once the discussion shifted from architecture to latency, the fix became obvious. Message delivery and durable storage were serving different requirements. Delivery could happen directly from the queue while persistence happened in parallel, off the user-facing path. The architecture changed very little. The latency budget changed completely.

That pattern is worth internalizing because it applies well beyond chat systems. Every major component consumes part of a latency budget. Candidates who trace those costs explicitly before committing to a design often discover problems while they are still inexpensive to fix. Candidates who do not are frequently left defending an architecture whose latency target became unattainable several decisions earlier.

Trade-Offs, Failure Modes, and the Regional Reframe

The strongest candidates tend to make trade-offs visible as the design develops instead of waiting for the interviewer to uncover them.

After choosing a consistency model, they explain what they gain and what they give up. After introducing a cache, they discuss invalidation and failure behavior. After partitioning data, they identify the keys most likely to create load concentration. The interviewer still probes those decisions, but the conversation starts from a higher baseline because the reasoning is already on the table.

One of the most valuable moments from the mock interviews came from the same live chat design. The discussion had already covered replication, distribution, and global scale when the interviewer introduced a much simpler observation. Most live stream hosts are regional. Most viewers are in the same region as the host.

That single assumption changed almost every major decision in the design.

Global replication became far less important. Regional caching became practical. Replication factors could be reduced. The message queue remained the primary global component while much of the surrounding infrastructure could be optimized around local traffic patterns.

What makes this example memorable is that the design did not improve because another layer of infrastructure was added. It improved because an assumption was challenged.

Many candidates respond to scale by introducing more systems. The interviewer in this mock responded to scale by asking whether the traffic pattern justified those systems in the first place. That is the closest thing to a staff-level pattern that emerged consistently across the interviews. The strongest designs were not necessarily the most sophisticated. They were the ones built around the constraints that were real, not the ones that were merely possible.

The ML version follows a different structure from the distributed-systems interview, and the places where it generates signal are different as well.

A staff-level MLE mock that informed this guide followed a fairly consistent progression: business objective, data and labels, model architecture, training and serving, and evaluation. What stood out was not the structure itself but how unevenly the interview's weight was distributed across it. Some sections existed mainly to establish context. Others carried most of the discussion.

Business Objectives: Establish the Goal and Move On

One of the first pieces of feedback from the mock was that candidates often spend too much time here.

Business objectives, ML objectives, and success metrics are usually the same conversation viewed from slightly different angles. Define what success looks like, translate it into an ML problem, identify how it will be measured, and move forward. Click-through rate, watch time, retention, recall@K, NDCG, and mean reciprocal rank all matter. They rarely determine the outcome of the interview.

The stronger candidates established the objective quickly and spent their time on the decisions that followed from it.

Data and Labels: The Quality of the Signal

The discussion becomes more interesting once labels enter the picture.

For recommendation and search systems, shown-and-clicked is often treated as a positive example while shown-and-not-clicked becomes a negative example. Most candidates know that. The deeper conversation begins when the interviewer starts probing how much confidence you should place in those labels.

A shown-and-not-clicked result may be irrelevant. It may also be perfectly relevant and simply never seen. Treating every non-click as a hard negative introduces noise into the training data. The same pattern appears throughout ML system design interviews. Defining the label is rarely the difficult part. Understanding where the label becomes unreliable is usually more interesting.

The strongest candidates approached labels, metrics, and evaluation sets with the same mindset. Before using a signal, they examined the ways it could be misleading.

Model Architecture: Justifying the Funnel

Retrieval, ranking, and reranking appear so frequently in recommendation and search interviews that many candidates prepare them as a sequence to memorize.

Interviewers tend to view them as a resource-allocation problem instead.

Retrieval exists because it is impossible to run an expensive personalized model across billions of candidates while staying inside a realistic latency budget. The objective is to reduce the search space aggressively while preserving recall. Two-tower architectures remain common here, with one tower embedding the query and another embedding the item. Serving typically combines those embeddings with approximate nearest-neighbor search because exact nearest-neighbor search becomes prohibitively expensive at scale. HNSW remains a common choice because query performance stays efficient even as the candidate pool grows. Many systems also combine vector retrieval with a lexical path to preserve exact-match signals before merging the candidate sets.

Ranking exists because retrieval alone cannot produce a useful final experience. Once the candidate set has been reduced to a manageable size, richer features become affordable. User history, context, engagement signals, and personalization enter the picture. This is usually where the system begins making decisions that feel individualized.

Reranking exists because relevance alone rarely produces the experience a product wants. Diversity, freshness, business objectives, and content balance all compete with pure relevance. Techniques such as maximal marginal relevance or determinantal point processes appear here because they help manage those competing objectives.

The strongest architecture discussions spent surprisingly little time reciting the stages themselves. Most of the depth came from explaining why each stage existed, where the computational budget was being spent, and under what conditions the architecture could be simplified. Several interviewers responded positively when candidates described scenarios where a three-stage funnel would be unnecessary. A small catalog with limited personalization needs often does not require the same machinery as a billion-item recommendation system.

That distinction matters because it separates pattern recognition from judgment.

Biases and Failure Modes

Position bias and popularity bias appeared repeatedly in the mock interviews, often without the interviewer needing to raise them.

Position bias emerges when users click highly ranked results regardless of their actual relevance, gradually teaching the model that position and quality are the same thing. Popularity bias creates a different distortion by repeatedly amplifying already popular content, which can make newer or niche items increasingly difficult to surface.

What mattered in the interviews was not the ability to define these biases. It was the ability to recognize how they affected the specific system being designed and what corrective mechanisms would be introduced. Position-aware training, randomized exposure, inverse propensity weighting, and logQ correction all appeared in discussions, but they were rarely the center of the signal. The signal came from noticing the distortion before the interviewer had to point at it.

The pattern mirrors what happens in the distributed-systems interview. Candidates who identify the failure modes attached to their design decisions tend to score higher than candidates who only respond once those failure modes are introduced by someone else.

Cold Start

Cold start remains one of the most reliable follow-ups because it exposes whether the architecture depends too heavily on historical interaction data.

New users and new items create the same problem from opposite directions. The system lacks the information it normally relies on to make decisions. In the mock interviews, stronger answers combined content-based features, dedicated candidate-generation paths for fresh content, and reranking strategies that allowed new items to gather interactions without overwhelming the rest of the system.

The exact implementation mattered less than understanding where the problem emerged. Candidates who treated cold start as a retrieval problem often missed that it usually becomes more visible in ranking, where historical interaction features contribute a much larger share of the signal.

Evaluation: Where the Interview Has Moved

The most important update from the ML mocks concerns evaluation.

For traditional recommendation and ranking systems, evaluation is one phase of the interview among several. For LLM and agentic systems, evaluation increasingly becomes the center of the discussion.

The reason is straightforward. Once a candidate chooses an off-the-shelf foundation model, much of the traditional model-design conversation disappears with it. The interviewer still needs a way to determine whether the system works, and evaluation becomes the place where that determination happens.

As a result, discussions that once centered on architecture increasingly shift toward evaluation datasets, annotation quality, metric selection, human review processes, LLM-as-judge frameworks, and the reliability of those evaluation methods. Agentic systems add another layer, introducing goal-success rate, friction rate, contextual correctness, and factual correctness as first-class concerns.

One theme appeared repeatedly across the mocks. Interviewers became noticeably more interested once the discussion shifted from building the system to measuring whether it worked. Metrics, labels, evaluation sets, annotation quality, and feedback loops often generated more depth than model architecture alone.

That shift becomes even more visible when offline and online performance diverge. Improving offline metrics while degrading the live user experience is a common failure mode, and candidates who discussed experimentation, online validation, and rollout strategy generally produced stronger answers than candidates who treated offline evaluation as the final word.

For candidates preparing specifically for LLM and agentic design questions, this is probably the single most important adjustment to make. Several years ago it would have been unusual for evaluation to dominate the conversation. In 2026, candidates who treat it as a closing discussion are often surprised by how much of the interview happens there.

Trade-offs are probably the clearest example. A candidate chooses strong consistency, a cache strategy, a ranking approach, or a storage system. The interviewer asks what was given up to get that benefit, and the candidate answers well. That is a perfectly good discussion. The stronger version starts one step earlier. The candidate explains the trade-off while making the decision. By the time the interviewer gets there, the reasoning is already on the table.

The same thing happens with failure modes. A slow consumer in a messaging system, a cache stampede, a hot partition, cold start, data drift. Candidates often handle these well once they are raised. The pattern that consistently read more senior was identifying them before they became questions. Interviewers are partly evaluating whether you can solve a problem when somebody points at it. They are also evaluating whether you notice the problem yourself.

A different category of mistake comes from spending time in places that generate very little signal. In one mock, a candidate spent several minutes discussing REST responses and status codes. Nothing they said was wrong. The problem was that the conversation was consuming time that would have been better spent on architecture, bottlenecks, trade-offs, or failure handling. System design interviews reward judgment about where to go deep. The candidates who perform best tend to spend very little time on details that do not meaningfully affect the design.

Several candidates also ran into trouble by reaching for implementation details before the system had been scoped properly. One discussion became stuck on WebSockets versus gRPC while the functional requirements were still being worked out. The interviewer kept pulling the conversation back toward the product requirements because there was no way to evaluate the transport choice without understanding the system it was supporting. The order matters more than people think. Good requirements make later decisions easier. Weak requirements force you to revisit those decisions repeatedly.

A few mistakes appeared often enough to be worth calling out directly. In one distributed-systems mock, a candidate proposed ordering messages by timestamp across multiple regions. The interviewer stopped there because the assumption underneath the solution was wrong. Distributed systems do not have a reliable global clock, which means timestamps cannot provide the ordering guarantee the design required. In another mock, a candidate selected a time-series database for a message queue. The database was familiar, scalable, and technically impressive. The problem was that the access pattern looked much more like a durable commit log than a time-series workload. Both candidates understood the technology. Both answers still read below level because the design was being driven by familiarity instead of the constraints of the system.

Drawn from candidate reports across L4, L5, and L6 loops.

Classic distributed-systems design

• Design a managed pub/sub or message queue used internally across Google.
• Design a live chat that delivers messages to all connected viewers of a YouTube live session.
• Design a real-time global leaderboard for a game at the scale of Pokemon Go.
• Design a Google-scale web crawler for Search indexing.
• Design a rate limiter for a public API at millions of requests per second.
• Design a distributed job scheduler for cron jobs across machines with variable CPU and RAM.
• Design Google Drive: distributed file storage with versioning, sharing, and sync.
• Design a notification system routing time-sensitive alerts across push, email, and SMS.

ML system design

• Design a personalized search feature for YouTube Shorts.
• Design a recommendation and ranking system for a feed at billions of users.
• Design a retrieval-augmented generation pipeline for a large-scale search product.
• Design serving infrastructure for an LLM under low-latency, high-throughput requirements.
• Design a skills discovery and matching system for AI agents.

Most of the changes to Google's interview process in 2026 affect coding interviews more than system design interviews.

The Gemini code comprehension pilot, covered in the coding guide and the main Google interview guide, replaces a coding round for some junior and mid-level candidates on select teams. It does not replace the system design round, so the preparation described here remains largely unchanged.

The one update that may affect your preparation is Google's reported return to some in-person interviews. If your system design round is in person, spend at least a little time practicing on a physical whiteboard. The design conversation is the same, but organizing a diagram, managing space, and keeping your architecture readable while talking through it is a skill that feels slightly different from working in a digital tool.

Confirm the format with your recruiter and rehearse in the environment you are most likely to use on the day.

Most candidates prepare for system design by collecting answers. The stronger preparation habit is collecting trade-offs.

By the time most engineers reach a Google system design interview, they already know the building blocks. Databases, caches, queues, load balancers, retrieval systems, ranking systems, and serving layers are rarely the limiting factor. The mock interviews behind this guide pointed to a different pattern. Candidates generally knew the components. The differentiator was whether they could explain why a decision was made, what it cost, what alternative was rejected, and what would break if the underlying assumptions changed.

That starts with preparing for the right interview. Google's system design process now spans two distinct formats, classic distributed-systems design and ML system design, and the overlap is smaller than many candidates expect. A candidate preparing for consistency guarantees, partitioning, and messaging systems is preparing for a different discussion from someone preparing for retrieval architectures, evaluation frameworks, and ranking systems. Ask the recruiter. Use the role and the interviewer's background as signals. Prepare one version deeply and understand the other well enough that it does not come as a surprise.

The strongest preparation also tends to happen at the level of system categories rather than individual prompts. Interviewers change requirements constantly. A memorized answer for a leaderboard, recommendation engine, or chat system starts losing value the moment an assumption changes. Engineers who understand the trade-offs behind storage systems, messaging systems, search systems, ranking systems, and real-time systems can usually adapt because the reasoning survives even when the prompt changes.

One pattern appeared repeatedly in the stronger mock performances. Candidates were unusually selective about where they spent their depth. They identified the two or three decisions most likely to determine the architecture and concentrated their attention there. The weaker designs often contained more components, more detail, and more boxes on the diagram, but less discussion of the decisions that mattered. System design interviews are not won by designing more of the system. They are often won by identifying which parts deserve ten minutes of serious discussion and which parts can remain high level.

The same principle applies to requirements. Several of the strongest designs in the mocks became simpler before they became more sophisticated. A candidate challenged an assumption, narrowed the problem, or identified a traffic pattern that removed the need for an entire category of infrastructure. The regional reframe from the live-chat example earlier in this guide is a good illustration. The most valuable requirement is often the one that removes complexity rather than adding it.

One theme appeared across both versions of the interview. Decisions mattered more than technologies. Storage discussions quickly became conversations about access patterns, consistency requirements, and failure modes. Caching discussions moved toward invalidation strategy and behavior under load. Messaging discussions moved toward delivery guarantees, ordering, idempotency, and back pressure. Product names can start a conversation. They rarely carry it very far.

The single most useful habit from the distributed-systems mocks was tracing latency budgets before committing to a design. The live-chat example failed because every individual decision looked reasonable while the end-to-end path violated the SLA by construction. Walking a request through every hop, accounting for where time is spent, and separating the critical path from the persistence path catches a surprising number of design problems before they reach the whiteboard.

Time management deserves deliberate practice as well. Many of the highest-signal discussions happen after the architecture exists. Trade-offs, bottlenecks, failure modes, evaluation, operational considerations, and scaling decisions usually arrive later in the conversation. One of the most common failure patterns in the mocks was reaching those sections with only a few minutes remaining. Practice full sessions against a visible clock. Rehearse in the drawing tool you expect to use. If your round is in person, spend time on a physical whiteboard. Diagramming skill is not being evaluated, but moving efficiently through a design discussion is.

For every major component in a design, there is a second question worth practicing: how would you know this was failing? Strong candidates often discussed queue depth, consumer lag, latency distributions, saturation, error rates, model drift, or evaluation degradation without prompting. Operational thinking becomes increasingly important as the target level rises, particularly for L6 and above.

The final habit is the one that appeared most consistently in high-scoring interviews. After every major design decision, explain what alternative you considered, why you rejected it, and what could go wrong with the approach you chose. Candidates are rarely down-levelled because they lack an answer. More often, the interviewer has to work too hard to uncover their reasoning. The strongest candidates make that reasoning visible from the beginning.

For distributed-systems preparation, Designing Data-Intensive Applications remains the resource current Google engineers mention most often, particularly the chapters on replication, partitioning, and consistency. The value is not the technologies it describes. The value is the habit of evaluating every distributed-systems decision through the lens of trade-offs, failure modes, and recovery. The Bigtable and Spanner papers are useful for the same reason.

For ML system design, the recurring theme throughout the mocks was evaluation. Know your retrieval and ranking metrics, understand the limitations of the signals you train on, and be prepared to discuss how you would build, maintain, and trust an evaluation framework for an LLM-based system. In many 2026 interviews, that discussion carries more weight than the model architecture itself.

Prepfully Google Software Engineer Interview Guides:

• Google Software Engineer Interview Guide
• Google Software Engineer Technical Phone Screen Interview Guide
• Google Software Engineer Coding Interview Guide
• Google Googleyness and Leadership Interview Guide
• Google Software Engineer Interview Question Bank
• Google Software Engineer Mock Interview Coaches
• Mock Interviews: Google Job Interview Success

System design preparation:

• Designing Data-Intensive Applications — Martin Kleppmann (chapters on replication, partitioning, and consistency)
• The System Design Primer — Donne Martin (GitHub)
• System Design Interview Volumes 1 and 2 — Alex Xu
• Google Bigtable paper
• Google Spanner paper
• The Anatomy of a Large-Scale Hypertextual Web Search Engine
• Google's Site Reliability Engineering book

Related interview guides:

• Meta Software Engineer Interview Guide
• Amazon Software Engineer Interview Guide
• Netflix Software Engineer Interview Guide
• Spotify Software Engineer Interview Guide

Google resources:

• Google Careers
• How We Hire at Google
• Google's approach to structured interviewing
• Google Tech Dev Guide