Waymo AI Research Scientist interview typically runs 4 rounds: 2 coding rounds, 1 ML design round, and 1 ML basics/research round. The process takes about one virtual onsite and is research-heavy, with an informal first chat.
$178K
Avg. Base Comp
$261K
Avg. Total Comp
4
Typical Rounds
2-4 weeks
Process Length
Our candidates report that Waymo is looking for researchers who can defend their work, not just describe it. The most revealing pattern is how much time gets spent on papers and prior projects: one interviewer reportedly walked through a candidate’s paper from motivation to implementation details, while another spent the bulk of the conversation on background and published work. That tells us the bar is less about polished talking points and more about whether you can explain why your approach made sense, what tradeoffs you made, and how you would justify those choices under scrutiny.
A second theme is that Waymo seems to value applied mathematical reasoning with an efficiency mindset. The standout coding problem wasn’t a generic algorithm exercise; it centered on a 2D trajectory with time-indexed motion, then quickly escalated into shortest-path geometry and how to reduce computation as the number of segments grows. That combination is telling: they care about candidates who can move from a clean answer to a scalable one without losing the thread. In the ML portion, the questions stayed foundational but were used as a filter for depth, not memorization. We’ve seen that the non-obvious make-or-break factor here is the ability to connect research intuition, geometric problem-solving, and basic ML theory into one coherent technical narrative.
Synthetized from 1 candidates reports by our editorial team.
Had an interview recently?
Share your experience. Unlock the full guide.
Real interview reports from people who went through the Waymo process.
The whole process was four 45-minute video interviews, and the virtual onsite was basically split into 2 coding rounds, 1 ML design round, and 1 ML basics/research round. The first interview felt more like an informal chat with a research scientist than a true screen. He introduced his team’s work and Waymo’s broader research direction, and then spent most of the time asking about my background and papers. It was relaxed and didn’t go very deep, so I wasn’t even totally sure what the goal of that round was.
The second interview was the coding round that stood out the most. I was given a 2D trajectory represented by (x, y, t) tuples, with t increasing monotonically and straight-line motion between points. The first part was straightforward: given any time t, return the coordinates at that moment. After that, he pushed it further and asked for the shortest path from an arbitrary point on the plane to the trajectory. Once the trajectory had many segments, he also wanted to know how to reduce the computation cost, so there was a clear follow-up about efficiency rather than just getting a correct answer.
The third interview was much more serious and felt like a research deep dive. The interviewer spent about half the time going through my paper, from motivation and high-level ideas all the way down to implementation details. The other half was basic ML theory. I was asked to explain dropout, including how it works during training versus testing and why it helps reduce overfitting, and then to define overfitting and underfitting and how you tell them apart. I also remember a possible ensemble-related question, though I can’t recall the exact wording.
Overall, the process felt very research-heavy and less like a standard LeetCode loop. I didn’t get an offer, but the main takeaway was that Waymo seemed to care a lot about whether I could defend my paper work clearly and reason through geometry/efficiency questions on the spot.
Share your own interview experience to unlock all reports, or subscribe for full access.
Sourced from candidate reports and verified by our team.
Topics based on recent interview experiences.
Featured question at Waymo
Design an end-to-end ML system for personalized car recommendations at Cars.com, supporting real-time and batch inference, data distribution shift detection, and CI/CD for frequent model updates.
| Question | |
|---|---|
| Pathfinder in Maze | |
| 2nd Highest Salary | |
| Experiment Validity | |
| Merge Sorted Lists | |
| String Shift | |
| Friendship Timeline | |
| Button AB Test | |
| P-value to a Layman | |
| Nearest Common Ancestor | |
| Job Recommendation | |
| Minimum Change | |
| Radix Addition | |
| Hurdles In Data Projects | |
| Non-Normal Probability Distribution | |
| Network Experiment Design | |
| Complete Addresses | |
| Delivery Estimate Model | |
| Random Bucketing | |
| Find Bigrams | |
| Success Measurement | |
| RMS Error | |
| The Brackets Problem | |
| Testing Price Increase | |
| Good Grades and Favorite Colors | |
| N-gram Dictionary | |
| Cyclic Detection | |
| Overfit Avoidance | |
| Type-ahead Search | |
| Basic Regex |
Synthesized from candidate reports. Individual experiences may vary.
The first conversation felt like an informal discussion with a research scientist rather than a strict screen. The interviewer introduced the team’s work and Waymo’s broader research direction, then spent most of the time asking about the candidate’s background and papers.
This round focused on a geometry and efficiency problem involving a 2D trajectory represented by (x, y, t) tuples with monotonically increasing time. The candidate first had to return the coordinates at a given time, then extend the solution to find the shortest path from an arbitrary point to the trajectory and discuss how to reduce computation cost for many segments.
This round was part of the virtual onsite and was described as one of the more serious interviews. It likely centered on machine learning system or research design, though the experience specifically emphasized that the overall onsite included an ML design round.
The interviewer spent about half the time digging into the candidate’s paper, from motivation and high-level ideas down to implementation details. The other half covered ML fundamentals such as dropout, training versus testing behavior, overfitting and underfitting, and possibly an ensemble-related question.