Swiggy-Style Machine Coding Round: Format, Tips & Practice Problems
Hyperlocal delivery companies run some of the most operationally intense backends in India: every order fans out into restaurant acceptance, delivery-partner assignment, live status tracking, and SLA clocks — all racing each other in real time. Machine coding rounds in the style of Swiggy and similar logistics companies pull their scenarios straight from that world.
That makes them distinctive: less about pricing rules, more about state machines, dispatch and matching, and time-based logic. This page covers the commonly reported format, what evaluators look for, and Gronex repository problems in the same style — order trackers, driver matching, assignment races, and SLA engines.
What a Swiggy-style machine coding round looks like
Expect roughly 90–120 minutes to build a working slice of a delivery system: an order-lifecycle tracker, a delivery-partner assignment service, or a rider–order matching engine. The statement usually specifies a strict status flow (placed → accepted → picked up → delivered, with cancellation rules) and a matching policy (nearest available partner, or a rating/priority rule with tie-breaks).
The domain forces two things most other machine coding rounds only hint at. First, state machines with illegal transitions: an order must not go from delivered back to preparing, a cancelled order must release its assigned partner. Second, contention: two orders wanting the same delivery partner, or a cancellation arriving while assignment is in flight. Interviewers in this round style routinely ask "what happens if these two things occur at once?" even in single-threaded solutions.
Time is often part of the spec — SLA deadlines, delayed-order escalation, partner availability windows. Strong candidates inject a clock instead of calling the system time inline, which keeps behaviour testable and usually earns an explicit nod in the design discussion.
How you’re evaluated
A correct state machine
Every allowed transition implemented, every illegal one rejected, and status history preserved. This is the backbone of the demo.
Matching and assignment logic
Deterministic candidate selection with explicit tie-breaking, and release-on-cancel so partners are never leaked or double-booked.
Behaviour under contention
Two orders, one nearby partner; a cancel racing an assign. You should be able to say precisely who wins and why.
Testable time handling
SLA breaches and expiry logic driven by an injected clock — deterministic in tests, not sleep-based or wall-clock-coupled.
Common mistakes that fail this round
- Encoding order status as a free string and validating transitions ad hoc at every call site.
- Matching logic that depends on hash-map iteration order, so the "nearest partner" changes run to run.
- Forgetting release paths: cancelled orders that keep their delivery partner assigned forever.
- Calling the system clock inline, making SLA logic untestable within the round.
- Ignoring the tie-break rule in the statement — evaluators test it explicitly with equidistant partners.
Quick tips for the room
- Write the transition table from the statement before writing any code.
- Make every listing and selection explicitly sorted — determinism is graded.
- Handle cancel-and-release in the same commit as assign; they are one feature.
- Inject the clock on day one; retrofitting time is expensive mid-round.
How to prepare
Rehearse the two core patterns until they are muscle memory: an explicit state-machine (enum states, a transition table, a single transition method that validates and records history) and a select–assign–release matching loop that stays deterministic. Most Swiggy-style statements are one of these two patterns wearing different clothes.
The problems below are real backend repositories with failing test suites in exactly these domains. The order-status tracker and driver-matching problems map one-to-one onto the round; the assignment-race problem takes the same scenario to its HARD concurrency version — the follow-up question you will get if you do well.
Practice problems in the Swiggy-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
The core order-lifecycle state machine: legal transitions, cancellation rules, and status history.
Open the challenge →Ride Booking Driver Matching
Dispatch mechanics: candidate selection, deterministic assignment, and release-on-cancel — the delivery-partner problem in ride clothing.
Open the challenge →Driver Assignment Race Resolution
Two orders race the same partner: make exactly one win, with ordered locking and no deadlock.
Open the challenge →Notification Preference & Delivery
Order-update notifications with channel preferences, quiet hours, and idempotent delivery. Free to try.
Open the challenge →Support Ticket SLA System
SLA clocks done right: first-response and resolution tracking with an injected clock and breach evaluation.
Open the challenge →FAQ
Are these the actual questions asked in Swiggy interviews?
No. These are Gronex originals in the same style — logistics state machines, matching, and SLA logic — the kind of problem asked in rounds like Swiggy’s. We never claim any problem was asked at a specific company, and Gronex is not affiliated with Swiggy.
Do I need multithreading in a Swiggy-style round?
Usually not in the initial build, but you must be able to reason about contention — two orders competing for one partner — and say where a lock or atomic check-and-set would go. The HARD race-resolution problem above is that follow-up made concrete.
What language should I use?
Whatever you are fastest in. Java is the most common choice in India for this round style; Gronex repositories support Java, Python, and C++ with the same test suites.
How is this different from a Flipkart-style round?
The grading rubric is nearly identical — working demo, then design. The domain shifts from pricing and inventory to dispatch, state machines, and time-based logic, which changes what edge cases get probed.
Related
Gronex is not affiliated with, endorsed by, or sponsored by Swiggy. 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 Swiggy.