What to Expect in the Waymo System Design Interview

Waymo's system design evaluation runs at two altitudes, and knowing which your loop includes shapes preparation more than any other fact. Low-level design rounds model real on-vehicle systems: reported prompts include a traffic-signal state machine, an in-vehicle pub-sub message broker, and a sensor scene graph tracking objects around the vehicle: object modeling where timing, memory, and failure behavior are graded alongside structure. System design rounds run at fleet and platform scale: simulation infrastructure (Waymo's billions of simulated miles are its core validation asset), fleet telemetry, map data pipelines, and rider-service backends, all with the latency-awareness and reliability bar of safety-critical operations.

Across both, the register is distinct from consumer-scale design: correctness and fault tolerance are non-negotiable requirements rather than tradeoff currency, and the strongest candidates treat the safety case (how you know the system behaves) as part of the architecture.

The Low-Level Design Territory

• Traffic-signal state machine. Model signals, their states and transitions, sensor-input handling, and the failure semantics: what the system reports when a signal's state is unknown or conflicting, because "unknown" is a first-class state in a vehicle that must act on the answer.
• In-vehicle pub-sub broker. Bounded-latency message delivery between onboard modules: topic management, backpressure when a subscriber lags (drop-oldest versus block, per topic class), priority lanes for safety-critical messages, and zero-allocation discipline on hot paths.
• Sensor scene graph. Track objects around the vehicle from noisy detections: object lifecycle (tentative, confirmed, stale), spatial indexing for fast queries ("obstacles within the planned path"), timestamp handling across sensors, and memory bounds on a compute-constrained platform.

What is graded: clean interfaces, explicit state semantics (especially unknowns and failures), real-time awareness (bounded work per cycle, no unbounded queues), and evolution under the follow-up twist.

The System Design Territory

• Design the simulation platform. Waymo's most important infrastructure: run millions of driving scenarios against new software versions: scenario storage and versioning, massive parallel execution with deterministic replay, results comparison across versions (did the new planner regress on any scenario class?), and the economics of compute at that scale.
• Design fleet telemetry and event pipelines. Vehicles generating enormous sensor volumes: what uploads in real time (health, incidents) versus at depot (full logs), event triage, and the incident-reconstruction requirement: complete data around any event, always recoverable.
• Design the map pipeline. High-definition maps as versioned data: change detection from fleet observations, validation before release (a wrong map is a safety issue), staged rollout to vehicles, and consistency between map version and software version.
• Design rider-facing services. The Uber-shaped surface (matching, ETAs, ride state) with an AV twist: no driver to absorb ambiguity, so pickup-spot resolution, remote-assistance escalation, and fleet positioning carry the design.

What Interviewers Are Probing

1. Determinism and replay instincts. The domain's superpower and requirement: given the same inputs, produce the same outputs, so incidents can be reconstructed and fixes validated against history. Candidates who design log-and-replay in from the start (timestamped inputs, versioned everything, seeded randomness) speak the native language: the same register as our DeepMind evaluation-harness guidance, with physical stakes.
2. Latency budgets with hard edges. On-vehicle paths have cycle deadlines, not p99 targets: bounded work, priority preemption, and explicit behavior when a deadline is missed (a late obstacle detection is a safety event, not a slow request). Fleet-side paths relax to conventional percentiles; knowing which regime you are in is the fluency test.
3. Unknown-state honesty. Perception is probabilistic; systems downstream must handle "I don't know." Designs that surface confidence and degrade explicitly (slow down, request remote assistance) rather than forcing false certainty match the company's whole engineering philosophy.
4. Validation as architecture. For any component you design, expect "how do you know it works?": scenario coverage, regression gates, staged rollout with automatic rollback. At Waymo the answer is part of the design, not a testing afterthought.
5. Scale with safety asymmetry. Fleet infrastructure runs at big-tech scale, but the tradeoff logic inverts in places: availability can yield to correctness (a vehicle that pulls over safely beats one acting on stale data), and candidates who reason that asymmetry explicitly stand out.

Walkthrough Sketch: The Scenario Simulation Platform

Requirements first: validate every software release against, say, tens of millions of scenarios (recorded drives, synthetic variations, incident reconstructions) within hours, with results comparable across versions and total reproducibility. The foundational decision: scenarios and software are both immutable, versioned artifacts, and a simulation run is a pure function of (scenario version, software version, seed): state it early, because everything else derives from it.

Architecture: a scenario store (content-addressed, with metadata: scenario class, provenance, tags for the behaviors it exercises); an execution fleet running containerized simulations in massive parallel, scheduled by priority (release-gating suites first, exploratory sweeps opportunistically) with spot-capacity economics since individual runs are preemptible-safe by determinism; and a results store keyed by the full input tuple, making unchanged combinations cache hits: the same insight as build caching, applied to validation, and it is where the compute bill becomes tractable. Comparison is the product: per-scenario-class dashboards diffing versions (collision metrics, comfort metrics, rule violations), automatic triage routing regressions to owning teams, and release gates defined as invariants over scenario classes ("zero regressions on the incident-reconstruction suite"). Failure handling: nondeterminism is treated as a bug of the platform itself, detected by duplicate-run spot checks; a flaky scenario quarantines with an owner rather than eroding trust in the suite. Close with the cultural point: this platform is the company's safety case in executable form, so its own correctness gets the highest engineering bar in the building, and saying that sentence in the interview demonstrates you understand where you are applying.

How to Prepare

• Foundations and depth: Grokking the System Design Interview for method, Grokking System Design Fundamentals for blocks, and Advanced System Design Interview, Volume II for the ordering, replication, and consistency depth both altitudes reach.
• Drill the LLD trio: state machine, bounded-latency pub-sub, and scene graph, each with explicit unknown-state and failure semantics. These are reported prompts; practicing them is direct preparation.
• Rehearse the simulation platform once end to end: determinism, caching by input tuple, and regression gating. Its vocabulary transfers across Waymo's infrastructure prompts.
• Practice the validation pass: for every design, answer "how do you know it works?" as architecture. At Waymo that pass is the differentiator.

For the full loop, see What is the Waymo interview process like?, and prepare the self-critique round with Top Waymo behavioral interview questions and your answer to "Why Waymo?"