Recruiter call: overall this was standard - basic info questions, no BQ really came up in this round. I recall being asked why DoorDash. Passed in a day or two, then got scheduled for the next round quickly - pretty efficient.
Code Craft: a simplified version of Dasher Pay, simplified in that there was no coding extension like a double pay rate window. Instead, after finishing the basic coding, they asked some simple system-design follow-up questions, like what to do if a downstream service goes down. The questions were all within the range already covered by write-ups on the forum, nothing unexpected. My overall impression across all the interviews was that DoorDash cares more about system design thinking than about the ability to write code line by line. There was no starter code at all in this round - completely empty. If you used Java, you had to write your own Main class to call the methods in your own classes and print the results to test them. The test cases were simple, a few given up front, without too many corner cases. Adding one or two corner-case inputs yourself is probably a plus. After passing this round, next was a 4-round technical loop, and scheduling was efficient - lots of time slots and combinations to choose from, so I was able to spread it across 2-3 days as a virtual onsite.
Debugging: this was a random variant of the Dasher Picker problem. Forum write-ups on this variant are limited, and I wasn't fully prepared for it either - I'd mainly prepared Round Robin and Consistent Hashing. The starter code structure was actually an index-to-dasher map. Every add assigns the new dasher an incrementing index based on the current dasher count; remove has to fully delete the entry, and it's done by swapping with the last element, then giving the removed dasher's index to that last element (that's how you keep the remaining indices contiguous). Pick just generates a random number within the current index range.
The logical bugs were similar to what's already on the forum. What the write-ups don't mention is some multithreading bugs - like needing to add synchronized to a method, whether to synchronize the whole method or use a synchronized block, and the problem you get from calling an external API inside a synchronized method (a downstream timeout locks up the whole object). After fixing the basic logical bugs, you need to watch for these instead of continuing to hunt for minor logical bugs (deduplication, validation, that kind of thing). My multithreading experience is limited, and I hadn't prepared for it on top of that, so I didn't do well here. Honestly, with some prep this should be manageable. There was also a follow-up about how you'd turn this into a distributed system and what challenges that brings, similar to existing write-ups. Time was limited in this round, so you really need to stay calm while debugging under pressure.
HM + BQ: this round only had 2-3 BQs, with a lot more follow-up digging into your answers, so the point of preparing isn't having lots of stories - it's being able to hold up under detailed follow-ups. The BQ direction focused on ownership - what projects you drove yourself, found and solved problems on your own initiative, what the business impact was, how you measured it. There was also a question about how you use AI. Overall the interviewer was very friendly, kept affirming and summarizing, and didn't make it feel too tense. They left a good chunk of time for me to ask questions, so it's genuinely worth prepping 4-5 questions to ask back.
System Design: this round actually had two parts. The first part was talking through one of my own projects, with the interviewer asking some system-design-related follow-ups. But since time was limited (about 25 minutes), after your own introduction there isn't much room to go deep. If you prepare some of the questions already mentioned in write-ups - like where you'd optimize if you did it again - you should be fine. The second half was a simplified version of an Alert Notification System, simplified in that it doesn't send notifications directly to the end user but instead notifies downstream services. Then they asked in detail about how Retry is implemented, and finally asked about handling failure and some scalability questions.
The interview interface has two panels - one looks like a coding interface where the problem statement also lives, and it's best to write down both the functional and non-functional requirements in detail after asking your clarifying questions. This was my first system design interview, and I was so focused on asking questions that I forgot to write things down in detail, then had to spend extra time going back to fill it in later - a rookie mistake. I personally find the diagramming interface hard to use, nowhere near as good as Excalidraw, but it's not worth wasting time chasing a pretty diagram. The other thing to watch for is that whatever system design techniques you know need to hold up under detailed implementation follow-ups. For example, with MQ Retry, you actually need to be able to explain how it's implemented, not just know that you throw the failed message into a Retry Queue and retry it. Overall this round wasn't hard, and the interviewer was pretty friendly, actively trying to give hints.
AI Coding: this was the vaguest round during prep, because nobody had described the starter code in much detail. The problem I got had no starter code at all. The requirements were similar to what's on the forum but somewhat simpler. In short, you needed a DAG-represented workflow to handle refund logic, but you also had to write the service that fetches the order and the service that receives the refund yourself. What the interviewer seemed to actually be evaluating was whether you could get these three services running locally within the time limit and have them call each other's APIs and actually interact - not how complex the DAG logic itself was.
This round also didn't require writing any tests - getting it running mattered more. Every time I wanted to take a closer look at the AI's output, the interviewer kept pushing me to just accept it and move on, maybe because they were anxious about my pace.
My main problem was that at the start I understood it as the LeetCode-style approach of writing a few classes and mocking calls between them, but what the interviewer actually wanted was to really run several services on different ports, with real HTTP endpoints, really talking to each other. This needs to be confirmed clearly at the start - don't assume based on your first impression. Even though I eventually had the AI power through and change it to that approach, the change was too large and I didn't have time to review it carefully, which I'd count as a significant point deduction. Hopefully people after me can learn from this.
Some time later I got the rejection letter. Overall I think the outcome was fair - I didn't perform well in the two coding rounds, and it exposed some things I wasn't familiar with. DoorDash moves the interview process forward efficiently, the process is clear, and the prep materials are detailed. Combined with some existing write-ups to work from, prepping wasn't a total shot in the dark - overall I got a lot out of it. Hope people coming after me can learn from this and prepare better.
Discussion
Loading comments…