Dasher Max Profit (Maximum Profit in Job Scheduling variant, LeetCode 1235). You are a Dasher with a list of deliveries each having a start time, end time, and dollar payout. Assuming you can only do one delivery at a time, find the maximum total payout for the day.

The key insight is that this is a weighted interval scheduling problem, directly isomorphic to LeetCode 1235. Sort deliveries by end time, then apply DP: dp[i] = max(dp[i-1], profit[i] + dp[last non-overlapping delivery before i]). Use binary search to find the last non-overlapping job in O(log n). Overall O(n log n) time, O(n) space. Interviewers commonly follow up by asking you to handle ties on end time or negative payouts, and to walk through the binary search boundary conditions explicitly. Dynamic programming fluency and ability to recognize the classic weighted job scheduling reduction; clean binary search implementation without off-by-one errors.

Restaurant Search Engine using a Trie (LeetCode 208 Implement Trie variant). Given a list of restaurant names (e.g. 'panda express', 'panera bread'), build a search engine that returns k matching restaurant names for a given prefix query.

Build a standard Trie where each node stores children and an optional count or list of complete restaurant names. For prefix search, walk the trie to the prefix endpoint then DFS or BFS to collect up to k matching names. Time O(L) per insert where L is name length; O(L + k) per query. A strong follow-up is handling fuzzy search or ranking by popularity, which leads to augmenting trie nodes with a max-heap of scores. Ability to implement a trie from scratch cleanly in an interview setting and to reason about memory/time tradeoffs; handling multi-word restaurant names (spaces) correctly.

Binary Tree Maximum Path Sum (LeetCode 124). Find the maximum sum path between any two leaf nodes in a binary tree. Follow-up: extend to any two 'active' nodes, not just leaves.

Use a post-order DFS that returns the best single-arm gain from each node; track a global maximum updated at each node as left_gain + node.val + right_gain. The follow-up to restrict to 'active' nodes requires checking a predicate at each step and propagating 0 if neither child qualifies, which tests whether the candidate truly understands the algorithm versus pattern-matching. Clean recursive thinking and handling of negative values; adaptability when the interviewer modifies the problem constraints mid-interview.

Design the DoorDash Dasher Dispatch System. Match available Dashers to ready orders in real time, handling millions of active deliveries, sub-500ms assignment latency, and peak-load surges.

Start by scoping: order lifecycle states, Dasher availability states, geospatial matching radius. Core components: an order queue (Kafka topic partitioned by geo-region), a location service ingesting GPS pings (write-heavy, use Redis geo-sorted sets or a purpose-built geo-index), and a dispatch engine that runs matching on a configurable interval. Matching algorithm: a greedy nearest-available with constraints (dasher load, prep ETA, drive time). Key trade-offs: consistency vs latency in assignment (optimistic locking vs distributed lock), idempotency for double-assignment prevention, and region-based sharding to avoid hot partitions. Interviewers probe: what happens when a Dasher accepts and then cancels, and how do you handle the thundering herd on large order spikes. Geo-partitioning strategy, event-driven design, idempotency in assignment, and clear articulation of the CAP trade-offs in a time-sensitive matching system.

Design a Real-Time Dasher Location Tracking System. Ingest high-frequency GPS pings from millions of active Dashers, expose low-latency location queries, and power live ETAs for customers.

Ingestion: mobile clients push GPS every 3-5 seconds; use a write-optimized pipeline (WebSocket gateway -> Kafka -> location store). Storage: Redis Geo for live position (TTL-evicted), time-series store (Cassandra or InfluxDB) for historical path. ETA computation: a background stream processor (Flink or Spark Streaming) joins location with order state, calls a routing API, and writes ETA updates to a cache read by the customer-facing API. Key trade-offs: eventual consistency in ETA vs. strong freshness guarantee; batching pings to reduce write load vs. staleness. Follow-up: how do you detect a Dasher who has gone offline (heartbeat timeout + requeue). Write-heavy architecture reasoning, appropriate storage tier selection for geo data, and honest acknowledgment of the eventual-consistency ETA trade-off.

Design DoorDash's Item Review and Rewards System. Users can post reviews on menu items from completed orders, other users can upvote/downvote reviews, and users earn monthly rewards based on review quality (e.g., up to $50/month, $500 accumulated lifetime cap).

Schema: reviews table (user_id, order_id, item_id, content, images, created_at), votes table (user_id, review_id, vote_type), rewards_ledger (user_id, review_id, amount, month). Review quality scoring: heuristic (text length, presence of images, specificity) or ML model producing a quality_score. Reward payout: a scheduled job (monthly) aggregates quality scores, applies cap logic, and writes to the ledger. Anti-fraud: rate-limit reviews per user per item, detect sockpuppet upvote rings. Feed ranking: weight by upvote delta and quality score. Follow-up: how do you prevent reward gaming with low-effort reviews. Data modeling for a social + financial system, cap enforcement without race conditions (idempotent job with a unique monthly key), and fraud/abuse thinking.

Tell me about your biggest failure on a project. How did you handle it and what did you learn?

Use STAR but weight heavily toward the Action and the Result/Learning: what specifically you did when things broke, not just that things went wrong. DoorDash values 'We are learners' and 'One percent better every day', so the interviewer expects a concrete behavioral change you made afterward. Avoid failures that sound like humble-brags; pick something with real impact and show genuine reflection. Close with a specific, measurable thing you now do differently. Intellectual honesty and accountability; evidence of a growth mindset rooted in data and reflection rather than blame-shifting.

Tell me about a time you had a conflict with a teammate or stakeholder. How did you resolve it and what did you learn?

Be concrete about the nature of the disagreement (technical decision, scope, timeline) rather than vague. Show that you sought to understand the other perspective before advocating for your position, and that you resolved it through evidence or structured process (design doc, data, escalation with context) rather than politics or persistence. DoorDash values 'Make room at the table', so demonstrate that the resolution created a better outcome for both parties, not just a win for you. Maturity in handling disagreement, evidence of collaborative problem-solving, and respect for others' perspectives while still advocating effectively.

Describe a time you had to move quickly on a project despite incomplete information. What was the outcome?

This maps directly to DoorDash's 'Bias for action' and 'Dream big, start small' values. Show the reasoning behind your decision to proceed: what you knew, what you acknowledged you did not know, what reversible vs. irreversible decisions you made, and how you built in learning checkpoints. Quantify the outcome where possible. Avoid framing speed as recklessness; frame it as calibrated risk-taking with a feedback loop. Evidence of structured judgment under ambiguity, not just a willingness to move fast; ability to distinguish reversible from irreversible decisions.

DoorDash Interview Questions

DoorDash runs a 3-5 round virtual onsite loop for SWE roles (E4/SWE II through E6/Staff). The loop typically includes a Code Craft coding round (collaborative, real-logistics OOP problem, not vanilla LeetCode), a standard algorithms coding round, a system design round (45-60 min, required for E5+ and often E4), and a behavioral/hiring manager round. A phone screen (often another Code Craft or a classic LeetCode medium) precedes the loop. As of 2024-2025 DoorDash has also added a dedicated debugging round at some levels, where candidates read unfamiliar code, trace execution, and explain defects. The process moved from centralized to team-decentralized, so exact round composition varies by team.

16 real questions across 3 rounds

Reported via LeetCode Discuss confirmed reports: 'DoorDash US Phone screen Maximum Profit in Job Scheduling' (LC thread 4797207, Feb 2024); 'DoorDash E5 December 2024' (LC thread 6144451) reporting Dasher Max Profit variation and Trie restaurant search; 'DoorDash Staff SWE Feb 2024 Virtual Onsite' (LC thread 4835997) reporting Max Path Sum and Making a Large Island; 'Doordash onsite SDE2 Backend Reject' (LC thread 5876691) reporting Code Craft Dasher payout; Glassdoor QTN_7040477 confirming Dasher Max Profit as a real interview question; LeetCode Discuss thread 1745511 confirming Maximum Profit in Job Scheduling at DoorDash phone screen; Glassdoor DoorDash SWE interview reviews confirming K Nearest Restaurants (coordinates-based) as a real question, corroborated by prachub.com candidate aggregation.

Run a DoorDash mock with the AI interviewer. It asks questions like these, follows up on your answers, and tells you exactly what to fix. The only score that means anything is the one on your real answers.

Continue with Google

Keep prepping

All company interviews