What to Expect in the Swiggy System Design Interview

Design at Swiggy is tested in two separate rounds, and the first one is graded on working code. Candidates report a machine coding round of about 120 minutes where you build a small running program, and a separate design round follows it.

For SDE-1 and SDE-2 that round is usually low level design, which means classes and their relationships. For senior roles it is a system design discussion about Swiggy's own problems: order flow, delivery partner assignment, live tracking, and catalog.

The Machine Coding Round Comes First

A machine coding round is a timed session where you build a small working program from a written requirement, and candidates report about 120 minutes at Swiggy, with no internet access and no outside code. Reported problems include a Snake and Ladder game, a parking lot ticketing system, an expense splitting application, and CRUD APIs for a small service. One senior report describes building a service with its own database design and unit tests.

Three things are graded: the program must run and handle the stated cases, the classes must separate responsibilities clearly, and a new requirement must fit without a rewrite.

This round is different from a discussion round, and the difference is explained in system design versus low level design. For the shape of the round itself, see what a machine coding round is.

The Low Level Design Round

Candidates report a separate design round that stays at the class level. One reported question asks for a catalog system with restaurants, items, categories, variant groups such as size, variants such as small and medium and large, and add-on groups. Another reports an object oriented design for hotel room booking. Several candidates report a rejection here after clearing the coding rounds, so prepare it as seriously as the coding rounds.

The System Design Question Types

Order lifecycle. Design the path from cart to delivered order, where the hard parts are payment, restaurant acceptance, cancellation, and refunds, so a state machine, meaning an explicit list of allowed states and transitions, is the usual answer.

Delivery partner assignment. This is the signature Swiggy question: find an available partner near the restaurant, offer the order, and handle a decline or a timeout.

Live location and tracking. Thousands of partners send location updates continuously, so the question tests geospatial indexing, which means storing locations so that nearby ones can be found quickly.

Catalog and menu. Restaurants change items, prices, and availability all day, so the question tests reads at high volume against frequent writes.

Quick commerce inventory. Swiggy Instamart serves orders from dark stores, so design which store serves an address and how stock counts stay correct under concurrent orders.

A Walkthrough: Delivery Partner Assignment

1. Requirements (5 minutes). An order is confirmed, so one partner must be assigned within seconds, and the assignment should be fair across partners and should survive a decline.

2. The data. Partners publish location updates every few seconds, so store current locations in an in-memory store with a geospatial index, and keep the durable record of each partner in a database.

3. Candidate selection. On a new order, query partners within a radius of the restaurant, filter by availability, vehicle type, and current load, and then rank the remainder by expected pickup time.

4. The offer. Offer the order to the top candidate with a short timeout, and on a decline or a timeout, offer it to the next candidate. Never assign one order twice, so make the assignment operation idempotent.

5. Asynchronous flow. Publish order events to a log such as Kafka, from which notifications, restaurant updates, and analytics all read, so that the customer does not wait for them.

6. Peaks. Demand rises sharply at lunch and dinner, so queue assignment requests, widen the search radius when no partner is free, and degrade the estimated time rather than failing the order.

What the Interviewer Grades

State the requirements before you draw anything, and name the trade-off in each choice out loud. Connect each decision to the customer result: a slow assignment means cold food.

Discuss failure cases directly, including a partner who goes offline mid-delivery, because depth is graded more than the number of boxes in your diagram.

Common Mistakes in This Round

• Treating assignment as a simple nearest search. Declines, timeouts, and fairness are what the interviewer asks about.
• Ignoring peak load. A design that works at an average rate fails at dinner time.
• Skipping the state machine. Without explicit states, cancellation and refund questions have no answer.
• Coding too late in the machine coding round. A clean design with nothing that runs scores poorly.

How to Prepare

• Practice class design under a timer. Grokking the Object Oriented Design Interview covers the exact problems reported here.
• Learn the building blocks. Grokking the System Design Interview covers queues, caches, and location search.
• Rehearse the walkthrough. Say the six steps above out loud in under 40 minutes.
• Study the full loop. Check the Swiggy interview process, prepare the motivation question, and plan for the wait described in how long it takes to hear back.