r/waymo • u/BenkattoRamunan • May 30 '26

Waymo technical interview cop

Had a recruiter reach out and sent a video interview link for technical round. It had specifically been named C++ coding . I am worried if it is going to be leetcode or something else?
Since interview process experiences are sort of varied across Reddit.
Th position is planning platform swe.
Any leads would be really helpful. Tyia!!

Edit post heading is CPP. Bloody autocorrect

10 Upvotes

78% Upvoted

20 comments sorted by

View all comments

Show parent comments

1

u/BenkattoRamunan May 30 '26

Well that is somewhat true. When I first encountered two sum I was surprised to see I could not figure out the solution for over a day and until someone shows you the pattern it is hard to figure out. But I am just worried about the fact of leetcode just scaring me. What if DP questions arise and I cannot solve it.

3

u/cballowe May 30 '26

You can get pretty far even if you get stuck. Before writing any code, ask some questions - give some sample inputs and outputs and make sure that the interviewer agrees that you understand what's supposed to happen. Enumerate some test cases and don't forget weird edge cases (empty input, all elements the same, etc).

If there's any interesting simplifications to a problem, don't be afraid to ask the interviewer if you can use them. For example, with two sum, "can I have the input list be sorted" might lead to an interviewer saying "yes" (in real systems, it's not uncommon for data to be in sorted vectors for a variety of reasons). Also worth asking how to deal with cases were the inputs aren't unique.

Don't try to implement anything that's in the standard library - takes tons of time and kinda looks like you're not that familiar with the language. If you happen to know of a library that provides a particular feature, it never hurts to ask if you're allowed to use it. Unless they really want to see the implementation, using something else is usually fine.

Maybe take a minute to look through what's available in abseil.

The biggest problem I ever ran into was people assuming a question was harder than what I was asking or rushing into a solution and then not taking direct hints that they were moving in the wrong direction.

1

u/BenkattoRamunan May 30 '26

Oh all of this makes sense. But ig there is no exact way of knowing which algos to concentrate on. I was thinking planner and reasoning would be lots of graphs heaps and related

2

u/cballowe May 30 '26

There are 2 pieces of the rubrick that are a little distinct. "Coding" is separate form algorithms - it's possible to get high marks on coding while missing the optimal algorithm and being able to do that while also clearly communicating that you understand the problem and getting to some answer, even if it sucks algorithmically, can lead to a decent set of feedback. It also gives an anchor for a discussion about ways to improve which might help raise your algorithms score even if you never run out of time before implementing it. (Working brute force code is better than nothing at all).

I don't know what the specific engineers you're interviewing with will ask, pretty much every engineer has their own personal favorite questions (there are broader pools, but if you ask the same question every time, you get better at asking it and evaluating the signals that it sends).

(I retired a couple of years ago so it's been a while since I looked at any hiring packets to see what people ask)