Hey everyone, I went through the DoorDash loop around two months ago. It ended up bittersweet, but I still count it as a win for me.
Application
A referral got me in for the Software Engineer, Product role (E4), and the recruiter got back to me about what came next.
Technical screen
The opening round was what they call a code craft round. They hand you a practical problem and you solve it with algorithms. There is some LeetCode-style thinking, but nothing exotic like DP or tree problems. Mine was a sliding window problem about computing a dasher's payout. Similar DoorDash questions float around online. The interviewer changes the problem a bit on the day, so thinking carefully about edge cases matters. Their test suite was not elaborate: once I finished coding, the interviewer had two or three cases in a notepad, pasted them in, and had me run my code to compare against their answers. Mine matched. Because the round was about code craft, I split my solution into small separate methods, and I think keeping it clean helps.
The final 15 minutes were follow-ups plus time for my questions about the company and role. The follow-ups were all about edge cases: they wanted me to come up with edge cases for the problem and say how I would deal with them. No coding there, just talking through the logic. It felt smooth and I answered everything. At the end the interviewer said I would hear about the next round soon and wished me luck, so I was feeling good.
Onsite
Debugging round
This was billed as debugging but it had a fair amount of coding too. The prompt was to build a dasher assignment system under a few constraints, and I got boilerplate code with gaps to fill. One method had a small bug that I had to fix, and the other methods I wrote myself. The key decision was which data structure to use for holding the dasher assignments. A list or a hash map would both work and give the same complexity, though the list is slightly more optimal. I did not see during the interview that a list could get the optimal complexity, so I went with a hash map. Right after I typed the map, the interviewer cut in and asked why. I said a list would be suboptimal on time complexity and that the map was simpler and cleaner. They did not look convinced and told me to keep going. I figured that would be what sank me. I finished the remaining methods, wrote my own tests, and thought through edge cases.
The last 20 minutes went to follow-ups and my questions. This time the follow-ups were about what I would change to run the service in production. I said I would keep the assignment map in Redis, which let me justify the hash map I had picked, although Redis works with a list as well. There were a few scalability questions, but nothing deep, only high-level system design. My read is that the whole round was about how well you explain your thinking, handle edge cases and think about production.
Honestly I walked out not feeling confident. Because of scheduling conflicts, the other two onsite rounds were pushed to the next day, which gave me a chance to clear my head, forget the data structure slip and start fresh.
System design and project deep dive round
This round was unusual, about 1.5 hours long. The first 20 minutes are a deep dive into a project of your choice from your resume, so it helps to prep it with the STAR method. The questions I got were:
- Why did you choose a certain technology, and did you consider alternatives?
- How did you pick between the alternatives?
- Were there any trade-offs you had to make?
- What challenges came up, and what would you do differently next time?
That part went really well and I explained everything with confidence.
The next hour was a full system design interview, and it was the first full one I had ever done. I was nervous and had practiced a lot beforehand. The question was a standard DoorDash one: design a food review and reward system. I used the structured framework I had learned in my practice, and it kept my design clean and made sure I covered what interviewers look for. Since the role was a product-focused software engineer one, the second half leaned toward product. Ahead of the interview I had also done two mock system design sessions, one with an engineer from a FAANG company and another with a DoorDash engineer. The DoorDash engineer told me what they look for in a product engineer, and that was very useful.
Before designing anything I asked three or four clarifying questions. On two of them the interviewer told me to make a call and justify it, since they were testing product thinking. I then covered the first few parts of the design. During the deep dives the interviewer stopped me to ask their own questions, which were product questions, mostly about how I would shape the reward system. That differs from the usual deep dives. They did not care about every deep dive and wanted to test me on this instead. I was not happy with my answers on the reward system, since they told me it was not very practical, though they also said there is no perfect answer and they just wanted to see my approach. Saying your thoughts out loud and showing how you reached a conclusion matters a lot here.
Apart from that last follow-up I was quite satisfied. I started with product questions before even thinking about the design, and for two of my early questions the interviewer said they were good ones.
HM interview
Nothing special here. It was a normal behavioral round where I talked about a project, and they asked about trade-offs I made and how I worked with other teams and PMs. It went pretty well.
Overall I felt good after the second day, even though I was unhappy with the first onsite round the day before. I felt I had bounced back and given my best on day two.
How did I prepare?
- For the coding and debugging rounds, I practiced sliding window problems on LeetCode and worked through previously reported questions I found online.
- For system design, which is the part I enjoyed most, I had almost no interview experience going in. A friend pointed me to an online platform that has an interactive system design practice tool. My routine was: pick a system design question, go through the video or article and learn what was new to me, take a 15-20 minute break, then try the AI-powered practice tool. You can either type your answer or record your voice and have it transcribed. I started with typing, then pushed myself to answer by voice, which recreated real interview conditions and showed me how I sound while walking through a design. When I did badly, I waited two days, came back and did it again. I made mistakes early on but adapted fast and learned to speak clearly. I ended up loving system design and felt more confident as an engineer, and I would suggest this kind of practice even without an interview coming up, since it reinforces engineering concepts. I also read other people's designs for popular questions to collect ideas before the interview.
Verdict
The recruiter contacted me to say they had feedback. It was great overall, and a hiring manager wanted to talk to me because the manager who had interviewed me had already been hired by then. We discussed my compensation expectations and immigration details.
The next day I talked with the hiring manager, who had only good things to say about my interviews. The best part was hearing that I scored quite high on system design and that they were impressed. She wanted to hire me, and I was excited about the team and its work. It was a real high.
But, as I said at the start, it is bittersweet. The very next day the recruiter emailed to say that an internal re-org closed the position, so the hiring manager could not hire me. The recruiter looked for another team that could take me, found none, and put the process on hold. It was a rough day, and the next few were no better, mostly because I had come so far and the feedback had been so warm. Still, I am grateful for the experience. Hearing that feedback was a big confidence boost. I feel much more sure of my system design skills now, and I did well in system design interviews at other companies afterwards. That is the sweet part.
I believe nearly any skill can be learned if you put in the effort and have a good teacher to learn from.
Discussion
Loading comments…