Zepto-Style Machine Coding Round: Format, Tips & Practice Problems
Quick commerce compresses the entire e-commerce stack into a ten-minute promise: inventory accuracy at the dark-store shelf, picker task queues, dispatch, and delivery — with almost no slack for error. Machine coding rounds in the style of Zepto and other quick-commerce companies borrow their scenarios from exactly this pipeline.
The distinguishing flavour is inventory truth under speed: stock counts that must be exact while orders, restocks, and expiries mutate them concurrently, and fulfilment work that must be scheduled, prioritised, and never done twice. This page covers the commonly reported format, evaluation criteria, and Gronex problems in the same style.
What a Zepto-style machine coding round looks like
Expect a 90–120 minute build of a fulfilment slice: a dark-store inventory service (reserve stock on order, release on cancellation, receive replenishment), an order-fulfilment state machine (placed → picking → packed → dispatched → delivered), or a task queue that hands pickers the right job at the right time. Statements usually pin down capacity rules — reservation versus on-hand stock, substitution when an item is short, priority for express orders.
The inventory core is a reservation problem: on-hand, reserved, and available quantities that must stay consistent through every order, cancellation, and receipt. Interviewers probe the same three edges every time: overselling the last unit to two orders, cancelling an order that was already partially picked, and receiving stock while a reservation is pending. If your model separates "reserved" from "on-hand" cleanly, all three fall out naturally.
The scheduling flavour shows up as delayed and priority work: an order becomes pickable only when due, express orders jump the queue, ties break first-come-first-served. Like the best rounds, it sounds trivial and is graded on determinism — the same inputs must always produce the same dispatch order, which rules out iteration-order accidents and wall-clock coupling.
How you’re evaluated
Inventory consistency
on-hand = reserved + available holds through every operation, and the last unit is never sold twice.
Fulfilment state machine
Legal transitions only, with compensating actions — a cancelled order releases its reservation and its picker task.
Deterministic scheduling
Priority and due-time ordering with explicit tie-breaks, driven by an injected clock — reproducible in tests.
Throughput thinking
You can point at the contention hot spot (the per-SKU stock record) and say how you would protect it under real concurrency.
Common mistakes that fail this round
- Modelling stock as one integer, so reservations, cancellations, and receipts silently corrupt each other.
- Decrementing stock at order placement instead of reserving — making cancellations and payment failures unrecoverable.
- A priority queue that ignores due time, dispatching scheduled work early.
- Non-deterministic picking order from map iteration, failing the same test intermittently.
- No compensation path: cancelled orders that leave reservations and picker tasks orphaned.
Quick tips for the room
- Separate reserved from on-hand stock in your very first data structure.
- Reserve at placement, commit at dispatch, release on cancel — say this out loud early.
- Inject the clock; quick-commerce specs are full of due-times and expiries.
- State your tie-break rule and encode it in one comparator.
How to prepare
Build the reservation model once, properly: three quantities per SKU, four operations (reserve, release, commit, receive), and tests for the three classic edges above. Then practise a scheduling kata — delayed jobs plus priority with FIFO tie-breaks — because it appears in quick-commerce rounds far more often than candidates expect.
The repositories below cover the pipeline end to end: the flash-sale problem is the oversell scenario at full concurrency; purchase-order receiving covers the replenishment side; the order tracker is the fulfilment state machine; and the job-queue extension (free) is precisely the delayed-plus-priority dispatch kata. The distributed scheduler is the follow-up question — exactly-once execution across workers — as a full problem.
Practice problems in the Zepto-style round format
Each is a real backend repository with a failing test suite — the same working-code standard the round applies. Open the brief and read the full problem, no signup required.
Flash Sale Inventory Purchase System
The oversell problem under full concurrency: sell exactly the stock you have when buyers race the same SKU.
Open the challenge →PO Receiving & Three-Way Match
The replenishment side of the dark store: cumulative receipts, over-receipt tolerance, and PO/receipt/invoice matching.
Open the challenge →Order Status Tracker
The fulfilment lifecycle as a state machine: legal transitions, cancellation rules, and status history.
Open the challenge →Job Queue: Delayed & Priority
The dispatch kata: delayed jobs dispatchable only when due, priority ordering, FIFO tie-breaks. Free to try.
Open the challenge →Distributed Job Scheduler
Exactly-once execution when several workers race to claim the same scheduled job — the scale-out follow-up.
Open the challenge →FAQ
Were these problems asked at Zepto?
No. All problems are Gronex originals in the style of quick-commerce machine coding rounds — the kind of problem asked in rounds like Zepto’s. Gronex is not affiliated with Zepto.
How much concurrency is expected in the round itself?
The initial build is usually single-threaded, but the inventory scenario makes contention unavoidable in discussion: two orders, one unit of stock. Being able to upgrade your check-and-reserve into an atomic operation — as the flash-sale problem forces — is the differentiator.
Reservation or direct decrement — which should I implement?
Reservation. Decrementing on order placement breaks the moment a cancellation, substitution, or payment failure appears — and one of them always appears in the follow-up requirements.
Is this round different at fast-growing startups versus larger companies?
The rubric is similar; the pace differs. Startup-style rounds tend to weight visible progress and pragmatic scoping — a working core in an hour — slightly above exhaustive polish, so practise against a hard timer.
Related
Gronex is not affiliated with, endorsed by, or sponsored by Zepto. All company names and trademarks belong to their respective owners. The problems on this page are Gronex originals written in the style of such interview rounds — not actual interview questions from Zepto.