DoorDash·Software Engineer·Onsite - System Design / Architecture
Jun 2026
System design round at DoorDash for a software engineer role. The prompt was a dual-surface design covering a read-heavy food item detail page and a month-end driver payout pipeline, and the contrast between those two surfaces was basically the whole point of the exercise.
- Design the backend for a food delivery marketplace covering two surfaces: a customer-facing food item detail page with ratings, posts, and likes, and a monthly driver settlement and payout pipeline.
- How do you maintain the rating aggregate for a food item as users submit and update their ratings, without recomputing the average from scratch on every read?
- How would you handle like counts on posts at scale, given that hot posts could create write contention on a single counter row?
- How do you paginate the post feed under a food item at large scale?
- Design the month-end driver payout pipeline so that each driver is paid exactly once, even if the job retries or reruns partway through.
- The payment processor times out and you don't know if the payment went through. What's your policy?
- Tips can be edited by customers for up to a week after an order. How does that affect your month-end cutoff and your ledger model?
- You find that the cached rating aggregate for some items has drifted from the sum of actual rating rows. How did this happen and how do you fix it without taking the page down?
- How would you give a user read-your-own-writes consistency on the rating average right after they submit a rating, even though the aggregate is eventually consistent for everyone else?
“This is a single prompt but it's really two different problems stapled together, and the interviewers clearly care that you notice the tension.” The rest of the author's notes on Software Engineer interview at DoorDash, Onsite - System Design / Architecture round, covers how they worked through the question, what the panel pushed back on, and what they would do differently.
View Post