Order state machines, delivery partner assignment and ETA under real-world messiness.
Swiggy design rounds revolve around a single hard property: an order passes through many states across several actors - customer, restaurant, delivery partner - and every one of them can fail or stall. Designing that as a state machine with explicit timeouts and compensating actions is exactly what interviewers want to see, and it is what most candidates skip.
Assignment and ETA questions follow. How do you pick a delivery partner when the optimal choice for one order is not optimal for the batch, and how do you produce an ETA that stays believable when a restaurant is running thirty minutes late? Peak-hour load is a third axis: dinner rush is a predictable multiple of baseline, which makes capacity planning a fair question.
45-60 min
Medium problems, frequently graphs and heaps given the domain.
60-90 min
Model an order flow or assignment system with clean class boundaries.
60 min
Order lifecycle, partner assignment, ETA, and peak-hour capacity.
45 min
Ownership and how you handled a production issue under time pressure.
Design the order lifecycle end to end. The strong answer models it as an explicit state machine with timeouts and compensating actions for every stall - restaurant not accepting, partner not arriving, payment failing after confirmation.
A real round at medium difficulty, weighted toward graphs, heaps and interval problems - which is unsurprising given the routing and assignment domain.
Commonly, yes. Like most Indian product companies, Swiggy runs a build round where you model a domain in code with clean class boundaries and then extend it when a new requirement is added.
Practise the rounds Swiggy actually runs, and get scored on where you stand.