Waymo Data Scientist interviews reported here combine statistics and experimentation with practical coding, applied ML, data fluency, and role-specific problem discussions.
$187K
Avg. Base Comp
$278K
Avg. Total Comp
5 rounds
Typical Rounds
3-5 weeks
Process Length
Waymo Data Scientist candidates in these reports encountered interviews tied to practical product and simulation problems rather than a single generic analytics format. One candidate described a technical assessment followed by four onsite rounds, with much of the discussion centered on simulation, evaluation, statistics, experimentation, and the assumptions behind statistical tests. Prepare to explain how you choose and interpret a test, including when its assumptions matter.
A separate candidate described a recruiter screen followed by a loop of roughly 45-minute conversations with a hiring manager, an engineering manager, and data science partners. Their technical work included dynamic-programming coding, using a supplied dataset to propose a solution, transformer fundamentals, and long-tail imbalance. Practical coding and statistical reasoning both appear prominently in these accounts. Another candidate reported data-fluency, machine-learning, coding, and data-system-design conversations in a virtual onsite, including a conceptual K-means question and a project walkthrough.
The evidence is limited to three candidate accounts, so team focus may vary. Build concise stories about prior projects, then practice applying statistical and ML judgment to an unfamiliar dataset or simulation-style problem while communicating your tradeoffs clearly.
Synthesized from 3 candidate 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 process was pretty smooth and professional overall. It started with a recruiter screen, and after that I went into a loop that was about 45 minutes per interview with the hiring manager, an engineering manager, and data science partners. Everyone I spoke with was nice and informative, and the questions felt very tied to the role rather than generic interview trivia. I interviewed for a simulation team focused on scenario creation, so a lot of the discussion was about how I would think through real product and data problems in that space.
The first technical round I had was a programming interview, and it leaned heavily on dynamic programming. I was able to solve the question, but that still wasn’t enough to move forward in my case. Another round was more applied: they gave me a dataset and asked me to come up with a way to resolve a problem using only that data, which felt like a practical case study rather than a textbook exercise. I also had a round with some ML fundamentals, including a quick check on how a transformer works, plus questions about handling long-tail distributions and data imbalance. One of the more unusual things was being asked to sample 3D bounding boxes of different orientations in numpy, which was very specific and definitely tested comfort with implementation details. There was also a behavioral question about why I wanted to work at Waymo, and in the HM-style discussion I was asked to think through building a feature for creators, which was more open-ended and product-oriented. I didn’t get the offer, and my main takeaway was that strong stats/ML intuition and comfort with practical coding both seem important here.
Prep tip from this candidate
Be ready for a dynamic programming coding round, plus applied ML questions on transformers, long-tail imbalance, and working directly from a dataset to propose a solution. It would also help to practice numpy-style implementation questions like sampling 3D bounding boxes with different orientations.
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
Write a function to return the value of the nearest node that is a parent to both nodes.
| Question | |
|---|---|
| Car Recommendation Architecture | |
| Location Frequency | |
| Pathfinder in Maze | |
| Shortest Path Algorithms | |
| Azure Kubernetes Infrastructure | |
| Statistically Significant Test | |
| Empty Neighborhoods | |
| 2nd Highest Salary | |
| Top Three Salaries | |
| First Touch Attribution | |
| First to Six | |
| Merge Sorted Lists | |
| Experiment Validity | |
| String Shift | |
| 500 Cards | |
| Last Transaction | |
| Button AB Test | |
| Top 3 Users | |
| Raining in Seattle | |
| Third Purchase | |
| Job Recommendation | |
| Minimum Change | |
| Impression Reach | |
| Jars and Coins | |
| Lazy Raters | |
| WAU vs Open Rates | |
| Find the First Non-Repeating Character in a String | |
| Network Experiment Design | |
| Bucket Test Scores |
Synthesized from candidate reports. Individual experiences may vary.
Candidates report an initial recruiter or phone screen that covered the role and prior work. One candidate was asked to describe a past project, so prepare a concise account of your contribution, technical choices, and outcome.
One candidate reported a technical assessment followed by onsite discussions focused largely on simulation, evaluation, statistics, and experimentation. They were asked about statistical tests, including assumptions and when to apply different methods.
Candidates report coding that ranged from a conventional data-structures-and-algorithms format to dynamic programming. One account also involved proposing a solution from a supplied dataset, while another mentioned numpy-style 3D bounding-box sampling.
Reported ML topics included explaining K-means conceptually, transformer fundamentals, and long-tail imbalance. Data-fluency conversations may also ask candidates to reason through project context and practical data decisions.
One candidate described approximately 45-minute conversations with a hiring manager, engineering manager, and data science partners. Their discussion included a simulation-team scenario and an open-ended feature problem, suggesting team-specific context may shape these conversations.
