AO
Back

Graph Search / BFS / DFS Coding

CodingPhone, OnsiteSoftware Engineer, Machine Learning EngineerLast reported April 2026Low Frequency

Problem Overview

Waymo coding rounds consistently feature graph search problems (BFS and/or DFS).

Full problem statement

Waymo coding rounds consistently feature graph search problems (BFS and/or DFS). The specific problem is typically novel and not seen in standard LeetCode problem sets. In one reported instance, the problem was explained via a diagram rather than a text description, requiring extra time to understand before coding. Problems span graph traversal variants and may be combined with other algorithmic concepts (e.g., one round described as similar to a known LeetCode problem combined with a 'sliding window' style approach; another round described as a DFS problem similar to LeetCode 959). The candidate is expected to identify the correct traversal strategy, implement it correctly, and run it to completion within the interview time.

Follow-up Arc

Interviewers escalate through these phases. The order varies, but most candidates see at least one from each bucket.
Trade-off discussion · 2
Trade-off discussion

Can you walk me through the time and space complexity of your solution?

Probes for: After initial solution is presented

How would you handle cycles or disconnected components in this graph?

Probes for: Candidate completes the basic traversal

Approach Trade-offs

Approaches actually attempted in reports — including ones that lost candidates time. Pick deliberately.
ApproachNotes
BFS for shortest-path variantsGuarantees shortest path in unweighted graphs; uses more memory (queue + visited set) than DFS but avoids stack overflow on large inputs.
DFS with recursionSimple to implement for connectivity/reachability problems; risk of stack overflow on very deep graphs; may explore non-optimal paths first.

What Reports Emphasize

Common mistakes: The problem was explained via a diagram rather than a text description, and understanding the problem itself consumed significant time, leaving insufficient time to finish coding. The candidate felt their approach was correct but did not finish, which likely did not meet the bar.; In the system design round, one candidate spent most of the 45-minute session just trying to understand the problem (which was directly tied to the interviewer's own project), leaving almost no time to actually design — suggesting the same risk exists in novel coding problems explained without written descriptions.

Interviewer hints: The interviewer described the problem using a diagram rather than pasting a text description, requiring the candidate to spend extra time understanding it before writing any code.; All three coding rounds across one candidate's full loop were graph-search related, suggesting the interviewer team deliberately focuses this area regardless of which specific problem is used.

What passers do: Candidates who felt confident described being able to immediately recognize the traversal direction (BFS vs DFS) from the problem structure, then work through implementation details and run the code to completion — consistent daily LeetCode practice was credited over relying on interview reports.; One candidate described a coding round as 'not hard, just do it normally' — suggesting that clean, direct implementation without overcomplicating mattered more than cleverness.

Waymo · Coding · Reported 2× across candidate reports
Is this helpful?