What the round is like
The round usually starts with a deep dive into your most challenging project, then the design question. One candidate said their round had a lot of back-of-the-envelope math, database choices, and sync vs async communication between services. Another said the interviewer skipped the API and pushed hard on tables, indexes and partition keys.
What people have been asked
These come up in candidates' own write-ups of their interviews. The donation app is the one people mention most. We wrote the example prompts ourselves, so the wording you get will be different.
Build a three-day donation app
A short fundraising campaign for a fixed list of about 10 charities. Millions of donors give money, and a third-party provider handles the cards. Candidates say the frontends are already built and you only store payment tokens.
Huge traffic in a short window, and you can't lose or duplicate anyone's donation. Interviewers push hard on reliability.
How it might be asked
Design a donation app for a three-day fundraising campaign. Expect around 10 million users and $100 million in donations. Card payments go through a third-party provider.
Key concepts to know
Try this Interview
Design a food review system
Customers review specific menu items at a restaurant, other people vote on the reviews, and in some versions good reviewers earn rewards.
Votes pile up fast on popular restaurants, so you need a plan for hot spots, and rewards have to be counted exactly once.
How it might be asked
Design a review system for DoorDash. Customers can review a specific item on a restaurant's menu, others can upvote or downvote reviews, and reviewers get a reward based on how good their review is.
Key concepts to know
Try this Interview
Design a job scheduler
A service that runs jobs at a set time or on a schedule. The interviewer cared most about the data model.
Every job has to run once, on time, even when workers crash. Your tables, indexes and partition keys get picked apart.
How it might be asked
Design a job scheduler. Clients submit jobs to run at a given time or on a repeating schedule, and the system runs them reliably.
Key concepts to know
Try this Interview
Design an ads click aggregator
Collect ad clicks as they happen and serve click counts for reporting.
A huge stream of tiny events, and advertisers want counts that are both fresh and right.
How it might be asked
Design a system that collects ad click events and lets advertisers see click counts per ad over different time windows.
Key concepts to know
Try this Interview
What's really being tested
| Topic | What you're being asked, basically |
|---|---|
| Money | How do you make sure nobody's charged twice or lost? |
| Data model | What are your tables, indexes and partition keys? |
| Hot spots | What happens when one restaurant or one ad gets all the traffic? |
| Peaks | What happens when a three-day campaign all lands at once? |
How to work through a question
- Figure out what you're building. Who's using it, what does it need to do, and what can you ignore?
- Do some rough math. How many requests, how much data, more reads or more writes? Those answers decide a lot.
- Walk through one request. Draw the simplest thing that works before you add anything fancy.
- Pick storage last. Once you know what gets read, how often and how fresh it has to be, the choice gets a lot easier.
- Then try to break it. What happens in a traffic spike? What if a server dies?
Key concepts to know
If you're rusty on any of these, start here.
- Idempotency and retriesMake sure a retried request doesn't happen twice.
- Message queues and event streamsKeep services from depending on each other, and handle traffic spikes.
- Relational vs non-relational databasesPick a database based on how you'll actually use it.
- Rate limitingStop too much traffic with token buckets and sliding windows.
- Caching strategiesMake reads faster, and figure out what to do when data changes.
- Sharding and consistent hashingSplit data across machines and keep it balanced.
- Stream processing and windowingCount things in data that never stops coming in.
- Load balancing and replicationSpread traffic across servers and keep copies so one failure isn't an outage.
Sources
We pulled this together from candidates' own write-ups of their interviews. They don't always agree, and things change over time.
- Roundz: DoorDash SDE phone screen and virtual onsite (2025)
- LeetCode Discuss: E4 onsite, donation SD, code craft, debugging (2025)
- LeetCode Discuss: Closest DashMart phone screen (2025)
- LeetCode Discuss: E5 onsite, review and reward SD (Dec 2024)
- LeetCode Discuss: E4 phone screen and onsite (Feb 2024)
- LeetCode Discuss: E4 offer, food review SD (Apr 2024)
- LeetCode Discuss: phone screen and virtual onsite (Dec 2025)
- LeetCode Discuss: senior, code craft and review SD (Feb 2026)
Practice Loop is an independent practice tool and isn't affiliated with or endorsed by DoorDash.