Zomato-Style Machine Coding Round: Format, Tips & Practice Problems
Written and reviewed by Sahil Srivastav
Zomato-style machine coding rounds borrow their scenarios from a backend where every order is a race against a clock: restaurant acceptance, delivery-partner assignment, live status, and an SLA that keeps ticking. You get a delivery-flavoured problem and a fixed window to hand back a service that runs and keeps its state consistent as events fire.
The domain is operational and real-time, so state machines and concurrency carry the round. An order moves through a strict lifecycle, a partner assignment can race a cancellation, and status queries must stay truthful mid-flight. This page breaks down the commonly reported shape of Zomato-style rounds, how they’re graded, and Gronex problems in the same style you can rehearse in a real repository.
What a Zomato-style machine coding round looks like
The typical shape is around 90 minutes, solo. You get a delivery-slice problem — an order status tracker, a partner-assignment flow, an SLA-clocked ticket — with functional requirements and the edge cases called out. You produce a small, runnable service demoed at the end.
Working code is the entry ticket. Zomato-style rounds then probe the operational reality: "what if the order is cancelled while a partner is being assigned", "what if a status update arrives out of order", "what if two updates race the same order". Your lifecycle model is the real subject.
The follow-up adds a state or rule — a re-assignment path when a partner drops, a new SLA tier, a batching rule for nearby orders. The round checks your state machine absorbs it without a rewrite.
How you’re evaluated
A running demo
Requirements implemented and the order flow executable end to end without crashing while the interviewer drives it.
Lifecycle modelling
The order as a real state machine — placed, accepted, assigned, picked up, delivered, cancelled — with illegal transitions blocked.
Race resolution
Cancel-versus-assign and out-of-order updates resolve to one consistent state, never a half-assigned or ghost order.
Extensibility under change
A re-assignment path or new SLA tier at minute 70 slots into a clean seam instead of forcing a rewrite.
Common mistakes that fail this round
- Modelling the order as loose booleans instead of an explicit state machine, so illegal transitions slip through.
- Reaching the demo with a design but no runnable order flow.
- Ignoring the cancel-versus-assign race, so a cancelled order still holds a delivery partner.
- Assuming status updates arrive in order — they don’t, and the round tests exactly that.
- Hard-coding the assignment rule so the inevitable "re-assign when a partner drops" extension needs a rewrite.
Quick tips for the room
- Get an end-to-end skeleton running in the first 30 minutes, then iterate.
- Model the order as a state machine and make illegal transitions unrepresentable.
- Decide the cancel-versus-assign winner explicitly — don’t let it be timing-dependent.
- Keep a two-minute buffer to rehearse the demo before you present it.
How to prepare
Practise the loop under a timer: take an order-lifecycle or assignment problem, set 90 minutes, and drive it to a runnable demo with the key race handled. Zomato-style rounds separate candidates on keeping a fast-moving order in exactly one legal state.
The Gronex problems below mirror the format from the other side — real backend repositories with failing tests over order lifecycles, assignment races, and SLA clocks, so you rehearse the exact muscle the round grades. Start with the free ones, then take the assignment race problem.
Practice problems in the Zomato-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.
Food Delivery Order Status Tracker
An order lifecycle as a state machine: legal transitions only, with consistent status queries as events arrive.
Open the challenge →Delivery-Partner Assignment Race Resolution
The contested-partner race: exactly one assignment wins, cancellations resolve cleanly, no order left half-assigned.
Open the challenge →Customer Support Ticket SLA System
SLA clocks over a ticket workflow: state transitions, escalation, and deadlines that stay correct as it moves.
Open the challenge →Offer & Coupon Application Engine
Eligibility, stacking rules, and idempotent redemption — the offers layer every delivery checkout runs.
Open the challenge →Notification Preference & Delivery
Preference-aware, idempotent order-update delivery across channels without duplicate sends. Free to try.
Open the challenge →Seat Reservation System
Holds as a state machine: reserve, cancel, and list availability deterministically. Free to try.
Open the challenge →FAQ
Were these problems actually asked at Zomato?
No. Every problem here is a Gronex original built in the same style — food-delivery lifecycles, assignment races, and SLA logic with working-code grading. We never republish any company’s actual interview questions, and Gronex is not affiliated with Zomato.
Is this round different from a Swiggy-style round?
They share a domain — hyperlocal delivery — so the shape is similar: order state machines, partner assignment, and SLA clocks. Practising either prepares you for both; the invariants transfer.
Which language should I practise in?
The one you’ll interview in. Gronex repositories run the same racing test suites in Java, Python, and C++.
Related
Gronex is not affiliated with, endorsed by, or sponsored by Zomato. 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 Zomato.