# Waymo’s interview loop, and why the safety round decides it

Source: https://www.techinterview.org/post/3233476865/waymo-interview-loop-safety-round/
Updated: 2026-07-26 · techinterview.org

Waymo's technical phone screen looks like any other Alphabet phone screen. One algorithm problem, 45 minutes, a shared editor, an interviewer who wants to hear the approach before you start typing. The onsite is where it stops looking generic, because at least two of those rounds are shaped by the fact that the code you write runs on a vehicle carrying a passenger through an intersection at 35 mph.

Candidate reports on [Blind](https://www.teamblind.com/company/Waymo/posts/waymo-interview) and [Glassdoor](https://www.glassdoor.com/Interview/Waymo-Interview-Questions-E1635890.htm) through 2026 agree on the shape: a recruiter call, one technical phone screen, then a virtual onsite of four to five rounds at 45 to 60 minutes each, then team match. Three to five weeks end to end when scheduling cooperates. Often longer for onboard roles, since those loops pull interviewers off vehicle software teams that are shipping against hard deadlines.

## The loop, round by round

Nothing here is exotic. What changes is the weighting. The design round and the behavioral round carry more of the decision than they would at a general-purpose product company, and a strong coding performance will not rescue a vague answer about what the system does when a component stops responding.

| Stage in the Waymo software engineer loop | Typical length | Format candidates describe | What decides the outcome |
| --- | --- | --- | --- |
| Recruiter screen | 30 minutes | Call covering background, target level, and which org has openings | Whether your experience maps cleanly onto a specific team's req |
| Technical phone screen | 45–60 minutes | One algorithm problem in a shared collaborative editor | A working solution with stated time and space complexity, written in the language your track expects |
| Onsite coding rounds (two) | 45–60 minutes each | Algorithms weighted toward grids, intervals, geometry, and timestamped data | Edge-case correctness; onboard candidates are expected to write C++ and discuss allocation |
| System design (ML system design for ML roles) | 45–60 minutes | Design a vehicle-scale or fleet-scale system, or an ML pipeline for perception or evaluation | Reasoning about failure modes and degraded operation rather than throughput and sharding alone |
| Behavioral and values | 45–60 minutes | Stories about disagreement, ambiguity, and safety tradeoffs | A concrete example of slowing something down for a correctness or safety reason |
| Team match | 30–45 minutes | Conversations with hiring managers after the loop closes | Whether a team with headcount wants your specific background |

## Onboard, infra, and ML are three different interviews

The most common preparation mistake is studying for "Waymo" rather than for a track. The three tracks share a phone screen and diverge sharply after it.

Onboard roles cover perception, planning, behavior prediction, and controls. These run in C++, and somebody in your loop will ask what your solution allocates and when. Solving an onboard-track problem in Python reads as a signal that you have not worked in this kind of stack. Expect the conversation to drift toward bounded latency, fixed-capacity buffers, and why you would never put an unbounded queue in a hot path that has to produce an answer every cycle whether or not the upstream data arrived.

Infrastructure and simulation roles use Python and Go alongside C++. The work is petabyte-scale sensor logs, replay, simulation fleets, and evaluation pipelines. Design rounds here look like distributed data problems with an unusual constraint: re-run millions of miles of logged driving against a new planner build overnight, and surface only the cases where the new build behaves differently from the old one. Determinism matters more than raw speed, because a replay that cannot be reproduced bit for bit is not evidence of anything.

ML and perception research loops replace the generic rounds with ML coding, ML fundamentals, and ML system design. One candidate described a May 2026 loop as a standard algorithm phone screen followed by exactly those three plus behavioral. The fundamentals round is oral and unforgiving on the topics that matter for a detector where rare events dominate the risk: calibration, label noise, class imbalance, and how you evaluate a model whose tail failures matter far more than its average precision.

## The coding rounds have a spatial and temporal accent

You will still see recognizable medium and hard problems. The selection just skews toward anything with position or time in it. Interval merging and sweep line, BFS on an occupancy grid, nearest-neighbor lookups over points, ring buffers, and merging streams that arrive with timestamps. Sensor fusion, restated as an interview question.

That last one shows up often enough to be worth having in your fingers:


```
import heapq

def merge_by_timestamp(streams):
    """Each stream yields (timestamp, reading) in nondecreasing order."""
    heap = []
    for i, s in enumerate(streams):
        it = iter(s)
        first = next(it, None)
        if first is not None:
            heapq.heappush(heap, (first[0], i, first[1], it))
    while heap:
        ts, i, reading, it = heapq.heappop(heap)
        yield ts, i, reading
        nxt = next(it, None)
        if nxt is not None:
            heapq.heappush(heap, (nxt[0], i, nxt[1], it))
```


O(n log k), and the interviewer already knows that. The follow-up is the actual interview: one sensor's clock drifts by 20 ms, or a stream stalls entirely. Do you block the whole fusion pipeline waiting for it? Almost never. You want a bounded lateness window, a watermark past which you emit what you have and mark the missing input as stale, and a defined behavior downstream for consuming a frame with a gap in it. Candidates who jump straight to that follow-up before being asked tend to pass this round comfortably.

## Design rounds that assume the system is a car

Reported prompts stay close to the product:

- Design the in-vehicle publish-subscribe broker that moves sensor frames between onboard modules

- Design a scene graph that tracks every object around the vehicle and answers spatial queries in real time

- Design fleet dispatch and rebalancing across a city with charging and depot constraints

- Design the remote assistance path for a vehicle that has stopped and needs guidance from a human operator

- Design the pipeline that validates and ships updated map tiles to vehicles already on the road

The separator is degraded operation. For every component you draw, be ready to answer what happens when it fails to respond within 100 milliseconds, and the answer cannot be that the vehicle waits. Timeouts should resolve to a defined safe default. Map tiles should be versioned with a rollback path and a vehicle-side check that refuses a tile that fails validation. The onboard broker should be a bounded ring buffer that drops the oldest frame under pressure, because a planner acting on a 400 ms old obstacle position is worse than a planner that knows it missed a frame.

Bring up minimal risk condition on your own if the interviewer does not. A system that degrades into a controlled stop at the curb is a design decision with real engineering behind it, and being able to name it tells your interviewer you have read something about how this industry actually works.

## The safety question is a real round

The behavioral interview covers the usual ground on disagreement, ambiguity, and cross-functional friction, with one recurring trap. Asked to describe a time you compromised, many candidates reach for a story about accepting a lower reliability bar to hit a date. That answer lands badly here. Compromise on scope, on schedule, on architectural elegance, on your preferred language. Have a story ready where you slowed something down and can name precisely what would have gone wrong if you had not.

The cross-functional questions are also less abstract than they sound. Waymo runs a physical service in specific cities with depots, vehicles, and field operations staff, so software engineers regularly argue with people who own hardware and rider operations rather than with other software teams. A story about negotiating with a fleet operations lead over a deployment window will do more for you than another story about a code review.

## Levels, equity, and the team match step

Waymo maps onto the Alphabet ladder, so you will hear L3 through L6 and above, calibrated much like Google's. The compensation structure is where candidates get surprised. Waymo raised outside capital and grants its own equity rather than Alphabet RSUs, which means the equity component of your offer is a different instrument with different liquidity behavior than public stock. Ask the recruiter to break out base, bonus, and equity separately, ask what instrument the equity actually is, ask about the vesting schedule, and ask how and when it becomes liquid. Check current bands on levels.fyi before you talk numbers, since public ranges shift and the ones circulating on forums are frequently a year or two stale.

Team match is a genuine gate rather than a formality. Passing the loop puts you in a pool; an offer requires a team with open headcount that wants your background. Ask before the onsite which orgs your loop is calibrated for, and if the answer is vague, ask again. Candidates who pass technically and then sit in team match for six weeks usually interviewed against a generic req.

Give yourself two weeks of real preparation. Rewrite twenty problems in C++ if you are on the onboard track, drill the interval and grid and timestamped-stream families rather than grinding random mediums, read Waymo's published safety framework closely enough to discuss operational design domain and disengagement reporting without hand-waving, and write down three stories about times you pushed back. The strongest candidates answer the dropped-frame question as though a passenger were sitting in the back seat, which at Waymo is the entire point.