Doordash Software Engineer Onsite Interview Experience and Insights

There were four rounds in total.

Coding Codecraft The Dasher payment question used a scanline approach. Everything had to be written from the class definition onwards. Using Java meant I was incredi

There were four rounds in total.

Coding Codecraft The Dasher payment question used a scanline approach. Everything had to be written from the class definition onwards. Using Java meant I was incredibly focused, and time was tight. Remember to confirm with the interviewer whether the input events were sorted. The Followup question involved calculating double payments during peak hours (with a peak hour start and end added to the input). The Debug question basically involved implementing the LC umbrella functionality, though the logic was a bit convoluted. Remember to confirm whether it was single-threaded or multi-threaded when modifying it. The Followup will ask you to switch to multi-threaded, and similar code review questions, asking what modifications you could make if following industry-standard code review practices. Both rounds included some SD-related questions. For example, the Debug round asked how to recover map data if the server crashed; you could say something like periodic snapshots + WAL. Those who have prepared for SD should find these answers easy. The SD 3-day donation question itself wasn't particularly noteworthy. However, during the subsequent Q&A session, my interviewer provided information I believe can be used as a reference for the wrong order question in the behavioral question round. He essentially mentioned that in Direct Development (DD), you often need to modify other teams' codes. Direct support from other teams is very limited. The basic behavioral question questions, two of which stood out: 1) Describe your most demanding project and why? 2) When were you least motivated? I still find this question quite tricky; it's worth preparing for it beforehand. The wrong order question was also asked. I think a crucial point is to confirm your role with the interviewer. The approach to problem-solving differs between an Integrated Development Team (IC) and a Tech Lead. Based on information provided by the third-round interviewer, I believe that even if you identify a problem within a specific team, you should drive the problem-solving process, rather than simply issuing an issue to that team. (Personal opinion, use your own judgment). Two days after the interview, the recruiter called to say they wanted to catch up, and that the feedback was pretty strong, but they were still in team matching. I'm posting this to hopefully get some good karma, and also to ask for some points to read other interview experiences, because I still have more interviews to go 😭 Copy as Markdown