Waymo System Design Interview Questions

Waymo's system design interview questions are steered toward the company's own problem rather than textbook consumer-tech clones. The recurring prompts are an AV data pipeline (petabyte-scale multi-sensor logs from ingestion to durable storage) and scene-similarity retrieval (find every driving scene like this one). There is also a simulation and visualization platform that replays that data to engineers, and an org-chart service on the more familiar distributed and object-design track. ML seats get a conversational ML system design round. Senior and staff loops carry a dedicated design round; earlier-career loops may see design only as a follow-up to a coding problem.

This section covers all of those and points you at three worked designs. For the rest of the loop, see the coding interview questions and behavioral interview questionssections. Read the interview process and how leveling and decisions work to place your req in its track before you prep.

The prompt is where this round diverges. Waymo is an Alphabet company, so the coding bar is Google-grade and the loop feels Google-shaped. The system design conversation does not default to the usual consumer-tech prompts, though. You are unlikely to be asked to scale a photo feed to a billion users or size a cache tier for a chat app. The round bends toward the problem Waymo has. A fleet of vehicles produces a staggering volume of sensor and log data, and the company has to store all of it, move it, replay it, and search it.

Two things follow from that. First, the design surface is data-heavy and retrieval-heavy rather than traffic-heavy. The interesting constraint is rarely requests per second. It is petabytes of multimodal readings, and how you find the one driving scene you need inside all of them. Second, the exact prompt tracks the role. A simulation and infrastructure seat, a perception and ML seat, and a full-stack seat are close to different interviews, and their design conversations diverge just as far. Set your expectations by the seat you are interviewing for, not by a canned reference design.

The Waymo angle

The bar here is data volume, retrieval, and reliability. Web virality does not come into it. A self-driving fleet does not go viral. But every mile it drives lands another pile of camera frames, lidar point clouds, radar returns, and vehicle telemetry. The company keeps all of it forever, because that data is how the driver gets better. So the design question that carries weight is different from "how do you survive a traffic spike." It is closer to this: you have millions of miles of multi-sensor logs sitting in storage. How do you let a thousand engineers find, replay, and annotate exactly the scenes they care about? And how do you guarantee you never lose a byte of it? Aim your prep at that shape. Reason out loud about volume, ingestion, indexing, and durability, and you are speaking the language this round rewards.

What system design questions does Waymo ask, and how do they split by role?

Waymo titles are namespaced by team, and you interview for a specific one. The design round follows that org. The table below describes what the conversation tends to cover on each track. None of it is published as a rubric, so treat these as the terrain rather than a fixed script. A strong candidate can usually move between them, because a real Waymo system touches several at once.

• Infrastructure and simulation: Petabyte data pipelines and scene retrieval. The seat where the signature AV-data prompt lives. Expect to design the systems that ingest, store, index, and serve the fleet's sensor logs, or a platform that renders that data back to engineers and lets them replay and annotate it. Waymo runs a large in-house simulation stack, so simulation, data infrastructure, and distributed storage are the center of gravity.
• Perception and ML roles: A conversational ML system design round. For machine-learning seats the design round is usually a spoken conversation with light diagramming rather than a whiteboard performance. You design a user-facing algorithm or an ML platform end to end, and you are graded on structured reasoning and on justifying each choice. The framing is often not Waymo-specific, so classic ML system design fundamentals carry you.
• General and full-stack seats: A more familiar distributed or API design. The less common path. Some general backend and product-facing seats see a design closer to what you would meet elsewhere: model a service, define its API, and reason about a data model and how it scales. It is real, and it is the one track where standard distributed-systems practice maps cleanly.
• Across every track: Level sets the weight. Early-career loops may touch design only as a follow-up to a coding problem, while senior and staff loops carry a dedicated design round. The heavier the level, the more the conversation expects you to drive the ambiguity and defend trade-offs on your own.

The signature: petabyte sensor data, retrieval, and simulation

Two prompt shapes recur often enough to be the headline. The first is a cloud platform that renders the fleet's driving data back to people. It takes the multimodal stream from a vehicle: several high-resolution camera feeds, raw lidar point clouds, radar, GPS, and the vehicle's own bus telemetry. It serves that to a browser for a large internal audience, with smooth replay, fast-forward, annotation, and the ability to save a session. The second is a retrieval system. Given a massive database of recorded driving, find scenes similar to a given one, so an engineer can pull every example of, say, a pedestrian stepping off a curb at dusk. The surfaces differ, but the underlying problem is the same. An enormous, multi-sensor corpus has to be stored durably and queried in a way humans and models can use.

Treat any specific numbers you hear as illustrations of the shape, not a fixed spec. The point is the register: volume measured in petabytes and millions of miles, several sensor modalities at once, and a hard requirement that nothing is lost and that the interactive views feel immediate. A handful of concerns come up almost every time, whichever surface you land on.

The Waymo angle

The recorded fleet is the asset, so losing it is the failure mode that matters most. At a consumer company a dropped write is an annoyance the user can redo. Here, a driving log captured on the road exists exactly once, and no rerun brings it back, so durability is a headline requirement, not a footnote in the design. That reframes the whole conversation. Write the raw data down once, immutably, before you do anything clever with it. Build every index, every derived signal, and every visualization as a rebuildable layer on top of that durable base, so a bug in the fancy part never costs you the irreplaceable part. A candidate who protects the raw corpus first, then adds retrieval and rendering on top, reads as someone who understands what Waymo is actually storing and why.

The ML system design conversation

If you are interviewing for a machine-learning seat, expect a different texture. The design round is a discussion rather than a whiteboard drill, and it often is not tightly Waymo-specific. You might be asked to design a recommendation system or an experiment-tracking platform. The grading is on how you structure the problem. How do you frame the objective, choose features and data, and pick a model and a training and serving path? How do you reason about metrics, feedback loops, and failure modes? The AV flavor shows up in the surrounding rounds more than in this one. Prepare it the way you would prepare ML system design anywhere, with a clear method and honest trade-offs, and let the conversation carry it. Where the prompt does turn toward driving data, the concerns above apply. The same volume, ingestion, and retrieval questions sit underneath any perception or prediction pipeline.

How to approach an AV-data prompt in the room

The prompts arrive under-specified on purpose, and your first job is to turn "design a system to store and search our driving data" into something you can actually draw. Ask what the data is and how much of it there is, who reads it and how fast they need it, and what "correct" means for durability and freshness. Then work outward from the raw store. The contrast below is what separates an answer tuned to this round from one that reaches for the wrong template.

The Waymo angle

Reason from the data, not from a memorized design. The thing this round is checking is whether you can look at an unfamiliar, physically enormous dataset and build something sane on top of it, rather than pattern-matching to a diagram you rehearsed. So make the data the first thing you talk about. State what a vehicle emits, estimate how much of it there is, decide what must be kept hot and what can go cold, and only then draw the pipeline. When you get to retrieval, be concrete about what you index and why a lookup beats a scan. That habit, starting from the real constraints of sensor data instead of a template, is what marks you as someone who could own a piece of the systems that make Waymo's data usable.

The worked designs in this section

Three worked designs carry the section, one for each shape the round tends to take. Design an AV Data System is the signature infrastructure prompt and the place to start. It puts the whole shape on the table at once. You size petabytes of multi-sensor logs, ingest them durably, index them for retrieval, and serve both an interactive tool path and a batch training path from the same corpus. Design a Scene Similarity System works the retrieval half on its own, turning "find every scene like this one" into an embedding index rather than a scan. Design an Org Chart System works the more familiar object-design and API track, the one general and full-stack seats are likelier to meet. Study one end to end rather than skimming all three.

Common questions