Interview Experience - 89 - Doordash | Software Development Engineer
Summary:
Job Role: Software Development Engineer
Number of Rounds: 5
Offer Status: Rejected
Location:
Candidate Name: Not disclosing due to signed NDA
Interview Process
The interview process at Doordash consisted of a phone screen followed by a virtual onsite. The onsite included two coding rounds, a hiring manager round, and a system design and domain knowledge round. Each round tested different skills including problem solving, algorithmic thinking, system design, and behavioral alignment with the company.
Preparation Guide
I thank all LC members for sharing posts which helped me in my preparation. The community resources were immensely valuable. After this experience, I need to go back and analyze what I could have done better in each round to improve my performance.
Interview Rounds
Round 1: Phone Screen
Duration: 60 minutes
Difficulty Level: Medium
Experience:
This round involved solving a modified version of the classic LeetCode problem Maximum Profit in Job Scheduling. The interviewer added an extra layer to the problem—introducing a start and end time constraint for dashers, which changed the dynamics of the scheduling and profit computation.
I approached the problem using dynamic programming combined with binary search. The additional constraint required careful consideration when constructing the state transitions. I was able to articulate my thought process and code the solution within the allotted time.
Key Learnings:
It’s important to quickly identify the core logic of the standard problem and be able to adapt to problem variations on the fly. Custom constraints can fundamentally change problem assumptions.
Round 2: Virtual Onsite - Coding Round 1
Duration: 60 minutes
Difficulty Level: Medium
Experience:
This round had two questions:
KAnagrams of Array of String — A variation of Minimum Number of Steps to Make Two Strings Anagram
I completed the first problem successfully. All test cases passed and I was able to discuss the logic confidently. For the second problem, I wrote the core logic but ran into an out-of-bounds exception due to improper handling of edge cases.
The interviewer was encouraging and said that given a couple more minutes, I would have completed the second problem as well. This feedback left me with a positive feeling about the round.
Key Learnings:
Be mindful of edge cases and array bounds, especially when dealing with strings. It’s essential to handle nulls, empty inputs, and string length mismatches to avoid runtime exceptions.
Round 3: Virtual Onsite - Coding Round 2
Duration: 60 minutes
Difficulty Level: Hard
Experience:
This was a variation of Binary Tree Maximum Path Sum, where the concept of "live nodes" was introduced. Several follow-ups were included:
Leaf node = Live node
Valid path must contain only two live nodes
Any node can be a live node
The valid path must strictly contain only two live nodes
I managed to implement the base problem and handled some of the variations correctly. However, I missed certain edge cases, like when a tree has only one live node. After the interviewer pointed it out, I was able to adjust my code. I also discussed testing strategies and wrote a small driver function to validate the logic.
The final condition—handling multiple live nodes in the same path—was tricky, and I wasn’t able to implement it fully due to time constraints. The interviewer was calm and focused on edge cases, and gave feedback that I did fine despite missing the last variation.
Key Learnings:
Edge cases in tree traversal problems can be subtle and often involve structural corner cases. Prepare for follow-up questions that layer additional constraints onto known problems, as they can significantly affect the complexity.
Round 4: Hiring Manager Round
Duration: 45 minutes
Difficulty Level: Medium
Experience:
This round was focused on behavioral aspects and team fit. Questions included:
A proud moment in life
Conflicts within a team and how they were resolved
What I expect from my team
Why Doordash?
I typically perform well in behavioral interviews as I keep a set of well-prepared stories covering various common themes. The hiring manager had a list of questions and the session felt more like structured Q&A than an open conversation. However, I felt the answers resonated with the interviewer, and the round went smoothly.
Key Learnings:
Prepare stories in advance for behavioral rounds. This preparation helps maintain composure and confidence, especially in rounds that follow a strict question-answer format rather than open-ended discussion.
Round 5: System Design and Domain Knowledge Round
Duration: 60 minutes
Difficulty Level: Hard
Experience:
The prompt was to design a donation platform for a 3-day event targeting $100 million in donations. Key constraints:
30 static donation organizations
Average donation = $35
Payment handled via a third-party API (e.g., Stripe), and we could store tokens but not credit card details
I approached the problem by starting with requirement gathering and diving into scenarios around payment API reliability and load. Then I:
Designed tables for users and payments
Calculated storage and QPS based on provided data
Created a system architecture: User → Web Server → Load Balancer → Application Server → Cache, DB, Payment API
Discussed synchronous vs. asynchronous flows
Covered retry strategies, circuit breakers, cron-based email notifications
Addressed failure scenarios like DB connection issues and API timeouts
Added a write-ahead log before each transaction
Proposed master-slave DB setup and distribution using consistent hashing
Suggested how different companies could reuse the system securely using per-tenant configurations or isolated deployments
The interviewer was engaged and seemed satisfied with the coverage. There was no pushback or counter-arguments, and the discussion remained productive and aligned.
Key Learnings:
System design interviews require a blend of structured thinking and creative problem solving. Consider reliability, fault tolerance, and scalability. Being thorough in explaining trade-offs and failure scenarios makes a strong impression.
Final Thoughts
This was a comprehensive interview process that tested both problem-solving and design abilities. A few key takeaways for future candidates:
Prepare for problem variations, not just direct LeetCode problems
Be ready to discuss and adapt in system design rounds—there is no one correct answer
Behavioral questions matter—have stories ready
Edge case handling is often what distinguishes an average solution from a great one
Learn to think aloud and clarify assumptions proactively
While I did not receive an offer, I found the process insightful and appreciated the feedback and professionalism of the interviewers. I plan to revisit and improve the areas I missed, especially around edge case detection and system design depth.


