How the interviewer opens it
“Design a food delivery app like DoorDash. Customers order from nearby restaurants, restaurants accept and prepare orders, and couriers pick up and deliver the food. Customers should be able to track their delivery.”
The prompt is vague on purpose. The first few minutes are yours: narrow it to the core features and agree on the numbers before you draw anything.
What to clarify first
- scale and geography
- read:write mix
- restaurant discovery and ordering
- courier assignment
- payment and cancellation
- latency
- consistency versus availability
- durability
- retention and privacy
- scope boundaries
The answers stay with the interviewer. In a SysRound round, Alex answers them as an interviewer would.
Scope of a strong answer
Core requirements
- Find nearby restaurants and view their menus
- Place an order, process payment, and let the restaurant accept, reject, and mark it ready
- Assign an eligible courier to pick up and deliver an order
- Show order progress and live courier location to the customer
Usually out of scope
- Batched deliveries and orders spanning multiple restaurants
- Building payment processing or road-routing services
- Promotions, ratings, restaurant payouts, and courier compensation
- Detailed food inventory, fraud detection, and proof-of-delivery disputes
What interviewers probe
- A reliable order across customer, restaurant, and payment failures
- Acceptance, cancellation, payment, and physical preparation happen in different systems. A timeout does not tell us whether an action happened, and a database rollback cannot undo cooking or a completed charge.
- Preparation-aware dispatch and exclusive courier offers
- Nearby candidates change constantly, restaurants finish at different times, and couriers can ignore offers. Dispatch must avoid both unnecessary courier waiting and late pickup. Matching can use stale information, but assignment ownership cannot.
- Live tracking from noisy, high-volume location updates
- GPS traffic is much larger than order traffic and is delayed, duplicated, or reordered by mobile networks. Customers need a useful current view without treating every coordinate as durable truth or exposing courier location to unrelated users.
Common mistakes
- Spending most of the interview on restaurant search while leaving acceptance, dispatch, and delivery transitions unspecified.
- Treating nearby restaurants as serviceable without checking delivery areas, or treating cached menu availability as authoritative at checkout.
- Choosing the nearest courier without preparation timing, offer acceptance, expiry, or an exclusive assignment invariant.
- Mixing high-volume GPS telemetry with durable transactional order state.
- Retrying checkout or payment with new identifiers after a timeout.
- Adding many services, Kafka topics, and database shards before estimating a workload that fits a simpler transactional core.
The bar by level
- Senior (L5/E5)
- Defines the invariants and their database enforcement. Handles accept-versus-cancel races, expiring offers and late acceptance, outbox delivery, uncertain payment outcomes, preparation-aware dispatch eligibility, and stale or reordered GPS. Uses estimates to justify a relational core and a separate location path.
- Staff (L6+/E6+)
- Makes ownership and recovery rules explicit across dispatch, payment, restaurant, and courier failures. Distinguishes replaceable telemetry from durable business decisions, explains safe reassignment before versus after pickup, and proposes bounded degradation during outages. Can extend to batching or multiple regions without weakening assignment invariants, while identifying operational recovery and cost trade-offs.