What Is the Waymo Interview Process Like? (Round by Round)

Waymo's software engineering interview typically runs four to five rounds of 45 to 60 minutes over three to five weeks: a recruiter screen, a technical phone screen in a collaborative editor, and a virtual onsite combining coding, system design or low-level design, and a distinctive behavioral round in which you present a complex past project and are expected to critique your own architectural decisions without being prompted. The process carries its Alphabet inheritance: a Google-caliber coding bar, structured evaluation, and hiring-committee-style calibration, with timelines occasionally stretching on feedback cycles.

The domain flavors everything: coding problems arrive framed in autonomous-vehicle contexts (geometry, sensor streams, graph traversal over road networks), design rounds model on-vehicle and fleet systems, and the behavioral evaluation screens explicitly for safety mindset.

Quick Overview

Stage 1 and 2: Screens

The recruiter screen covers background and motivation (prepare it with How to answer "Why do you want to work at Waymo?") and routes you by specialty: onboard software, perception and ML, simulation, or fleet and cloud infrastructure run meaningfully different loops. The phone screen is classic Alphabet: one substantial coding problem in a shared editor, graded on correctness, complexity reasoning, and communication.

Stage 3: Onsite Coding

Google-difficulty algorithms wearing AV clothing: geometric problems (closest obstacles, path intersection, bounding boxes), sensor-stream processing (merging timestamped detections, sliding windows over telemetry), and graph work (road networks, route search). The framing rewards candidates who translate domain descriptions into clean abstractions quickly; the grading underneath remains fundamentals: correct, efficient, well-communicated code. C++ fluency helps for onboard roles; Python dominates ML-adjacent ones.

Stage 4: System Design and Low-Level Design

Two flavors by level and team. System design runs latency-aware and AV-scaled: fleet telemetry ingestion, simulation infrastructure, map data pipelines, and rider-facing service backends, with reliability probed hard (details in What to expect in the Waymo system design interview). Low-level design models real on-vehicle systems, with reported prompts including 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 correctness, timing, and failure behavior all count.

Stage 5: The Behavioral and Self-Critique Round

Waymo's signature. You present a complex past project, and the evaluation centers on something unusual: whether you critique your own architectural decisions unprompted. Interviewers are explicitly looking for self-awareness: candidates who volunteer what they would do differently today, where the design's weaknesses live, and what the failure modes taught them stand out significantly; candidates who present flawless retrospectives miss the round's entire point. Safety mindset, collaboration under pressure, and engineering judgment thread through the conversation; full preparation in Top Waymo behavioral interview questions.

Timeline and Decision

Three to five weeks, with committee-style calibration at the end. Leveling follows Alphabet conventions; feedback cycles occasionally add tail time, and polite recruiter check-ins are normal.

How to Prepare

• Google-bar coding with domain reps: Grokking the Coding Interview for pattern fluency, then deliberate practice on the AV shapes: geometry problems, interval and stream processing, and graph search. Translating word problems into abstractions fast is the trainable edge.
• Two-altitude design: Grokking the System Design Interview and Grokking System Design Fundamentals for the base; then LLD reps on the reported prompts (state machines, pub-sub, scene graphs) with failure behavior designed in.
• Prepare the self-critique presentation deliberately: pick your most complex project and write the critique before anyone asks: three decisions you would change, the weakness you knew about and shipped anyway, and what the incident taught you. This preparation inverts the usual instinct and wins the round.
• Safety-critical vocabulary: if your background lacks it, learn the basics of validation, redundancy, and fail-safe design; the domain conversation assumes the vocabulary.