Machine coding round
Food Delivery Order Status Tracker Coding Problem
What this interview round tests
The food delivery order tracker — the Swiggy / DoorDash-style order lifecycle — is one of the most common warm-up rounds in backend interviews, and the cleanest possible test of one skill: implementing a state machine properly. An order moves placed → accepted → preparing → out for delivery → delivered, cancellation is legal only from some states, and history must record every step.
Interviewers use it because status fields are where real codebases quietly rot. A delivered order that slides back to preparing, a cancelled order that keeps progressing, a status history with gaps — all of these come from validating transitions ad hoc at every call site instead of in one place. The round checks whether you make illegal states unrepresentable rather than merely unlikely.
The scenario
You are handed the order-tracking service of a food delivery backend. Status updates, cancellations, and history queries all exist — and the test suite shows the lifecycle is full of holes.
Orders skip states and move backwards, cancellation succeeds from states where it should be refused (and fails where it should work), the status history misses transitions or records rejected ones, and listings come back in unstable order. Your job is to enforce the lifecycle exactly and keep the history a faithful record.
What you’ll practice
- Modelling an order lifecycle as an explicit state machine with a transition table
- Rejecting illegal transitions: no skips, no backward moves, no leaving terminal states
- Cancellation rules: allowed only from specific states, refused cleanly elsewhere
- Status history: an append-only record of every successful transition
- Clear error semantics for rejected updates versus unknown orders
- Deterministic listings and histories so tests and clients always agree
How to approach it
Write the transition table before writing code: for each state, exactly which states are reachable next, and from which states cancellation is legal. Then funnel every status change through one transition method that consults the table, rejects violations, and appends to history — call sites should be unable to bypass it.
Keep terminal states truly terminal (nothing leaves delivered or cancelled), make the history append-only and written in the same step as the transition so the two can never disagree, and sort listings explicitly. It is an EASY-rated problem — which is exactly why interviewers expect it airtight, not just working.
The starter repository ships with a failing test suite and a bundled verify.sh. Reviewed reference solutions are part of Gronex Pro — this page stays spoiler-free on purpose.
FAQ
Why do interviews ask an "easy" order tracking problem?
Because it exposes habits fast. Free-string statuses, scattered if-checks, and missing history tell an interviewer everything about how a candidate structures real services. A tight transition table with one enforcement point signals maturity in ten minutes.
What edge cases get probed in an order lifecycle round?
Backward moves (delivered → preparing), skipped states, cancelling after delivery, double-cancelling, updates to unknown orders, and whether the history reflects exactly the successful transitions — no more, no fewer.
Do I need to set anything up to try it?
No. Open the problem to read the full brief with no signup, then solve it in the browser workspace or download the starter repo and run the bundled verify script locally in Java, Python, or C++.