Swiggy System Design Interview: What the Bar Actually Tests
- Machine coding is a full filter at Swiggy, not a warmup: expect 60-90 minutes of working, extensible code with real class design
- HLD questions are domain-specific: order management, Kafka-driven dispatch, Instamart inventory, and multi-restaurant orders, not generic Twitter or URL shortener designs
- Kafka semantics matter: at-least-once delivery, idempotency, and consumer group behavior come up in roughly half of reported HLD rounds
- The order state machine (placed, accepted, preparing, picked up, delivered, cancelled) is foundational knowledge for almost every Swiggy design question
- CP vs AP tradeoffs must be named explicitly: payments and inventory need strong consistency, catalog and search can be eventually consistent
- SDE-2 candidates must drive the HLD conversation unprompted and handle follow-up challenges on failure modes and scale
- Loop timeline is fast: 3 to 5 weeks from OA to offer decision, faster than most FAANG loops
You studied "design Twitter." You read the Designing Data-Intensive Applications book cover to cover. You can sketch a consistent hashing ring in your sleep. You walk into the Swiggy HLD round feeling dangerous.
Then the interviewer asks: "How do you guarantee exactly-once inventory decrement when Kafka only promises at-least-once delivery, and the restaurant marks an item unavailable between payment confirmation and the kitchen ack?"
Right. That kind of dangerous.
Swiggy's system design interview is the Godzilla frame. Generic prep books had you expecting the plush toys.
Swiggy is one of India's largest tech employers, and its system design interview has a reputation for being the most demanding part of the loop. Not because the questions are algorithmically exotic. Because they are domain-specific. Candidates who walk in with only generic templates get caught fast. This guide covers what actually comes up, round by round, and what separates the hires from the "we'll keep you in mind."
How the Loop Is Structured
Swiggy runs a five to six round loop for most backend and full-stack SDE roles.
| Round | Format | Duration | Appears At |
|---|---|---|---|
| Online Assessment | 3 DSA problems on HackerEarth | 90 min | SDE-1, SDE-2 |
| Technical Round 1 | DSA (arrays, trees, graphs) | 45 to 60 min | All levels |
| Technical Round 2 | Low-Level Design / Machine Coding | 60 to 90 min | SDE-1, SDE-2, SDE-3 |
| Technical Round 3 | High-Level System Design | 45 to 60 min | SDE-2, SDE-3 |
| Hiring Manager Round | System design depth + decision-making | 45 to 60 min | SDE-2, SDE-3 |
| HR Round | Values, compensation | 30 min | All levels |
The HLD round is mostly absent for SDE-1. From SDE-2 upward, it is a core filter. SDE-3 candidates often see two system design conversations: one in the technical round and one with the hiring manager that doubles as a design deep dive.
The OA Is a Gate, Not a Differentiator
The OA runs on HackerEarth and gives you 90 minutes for three problems. Difficulty is medium-heavy: expect one easy warm-up, one medium (sliding window, binary search on answer, heap), and one harder problem involving graphs or dynamic programming.
The OA is a threshold gate, not a differentiator. Clearing it gets you into the loop. What happens next is what matters.
If you are preparing from scratch, spend a week on the patterns that show up most: BFS/DFS on grids, two-pointer sliding window, binary search on answer, and priority queue problems. The OA does not test system design at all.
DSA: Medium Difficulty, Domain Context
Swiggy's DSA rounds are firmly medium difficulty. Interviewers prefer problems where the brute-force approach is obvious and the interesting part is optimization, because that reveals whether you understand complexity, not just patterns.
Common topics:
- Graph traversal and shortest paths
- Interval problems (merging, scheduling)
- Sliding window on strings
- Binary search on answer (rate limiting, order batching problems)
- Two-pointer on sorted arrays
A few candidates have reported Swiggy wrapping DSA problems in delivery-domain context: "given N delivery partners and M orders, find the minimum total travel distance." The underlying algorithm is standard, but you are expected to translate the business scenario into a graph or optimization problem without being prompted. This is not a trap. It is a preview of every conversation you will have for the rest of the loop.
Swiggy interviewers score problem-solving process, not just correctness. Communicate your approach before you code.
Machine Coding Is a First-Class Filter
This is where Swiggy separates itself from most Indian product companies. The machine coding round is serious: 60 to 90 minutes, expected to produce working code with reasonable class design, not pseudocode.
Confirmed machine coding problems from candidates:
- Design a Splitwise-style expense sharing system
- Design a calendar application that handles recurring meetings and conflict detection
- Design a Top-K Restaurant Discovery System: given a customer location and a discount threshold, return the K nearest eligible restaurants
- Design a Swiggy Fleet Management System (assign delivery partners to orders, handle reassignment)
- Design a Snake and Ladder game with OOP principles and extension hooks
The pattern is: Swiggy gives you a system that is close to their real infrastructure, then adds one or two extension requirements partway through to see how you adapt. Yes, while the clock is running. Yes, they are watching.
What gets scored:
- Class design and encapsulation (interfaces before implementation)
- Handling edge cases without being reminded
- Extensibility (can you add a new order status without rewriting core logic?)
- Working code, not a skeleton
Practice LLD problems by writing full implementations, not diagrams. If you cannot get Splitwise done in 75 minutes with unit-testable classes, spend more time here before the loop opens.
Swiggy System Design Interview: What the HLD Round Actually Tests
This is the core filter for SDE-2 and SDE-3.
"I studied generic system design templates for six months. I still don't know what the fuck is going on." The Swiggy HLD round, summarized.
Swiggy asks you to design systems that are recognizable as pieces of their actual infrastructure. Generic "design Twitter" prep does not map cleanly onto food delivery. You will find out the hard way.
Confirmed HLD questions from candidates:
- Design a catalog system for a food delivery platform: restaurants, items, categories, variant groups (Size), variants (Small, Medium, Large), add-on groups, and add-ons. Handle menu updates at scale.
- Design a system to process 200,000 events per minute with strict ordering per
orderId, at-least-once delivery, and idempotent downstream effects. Fan-out to inventory and dispatch services. - Design a multi-restaurant order system: a customer places one order containing items from multiple restaurants. Internally, split into child orders linked by a
parentOrderId. Handle partial failures. - Design a warehouse management system for Instamart: inventory, stock movements, supplier batches, product SKUs, expiry tracking.
- Design a real-time dispatch system: match delivery partners to orders with ETA-based scoring, handle partner going offline mid-delivery.
These are not generic "design Twitter" questions. They are Swiggy-domain problems. Candidates who walk in with only generic system design prep get caught by specifics: how do you handle a restaurant marking a menu item unavailable mid-order? What happens when the assigned delivery partner cancels after pickup? How do you ensure exactly-once inventory decrement when at-least-once Kafka delivery is the transport?
If you cannot answer those on the spot, the interviewer knows you have not thought about food delivery. That is a problem when the company is, in fact, a food delivery company.
What Swiggy Evaluates in HLD
Scalability. Swiggy processes millions of orders per day and runs Instamart at 10-minute delivery SLAs. Any design that cannot plausibly handle 10,000 concurrent orders in a metro will get challenged.
Consistency vs. availability tradeoffs. Payments and inventory need CP guarantees. Catalog browsing can be AP. Name your choices explicitly.
Event-driven thinking. Swiggy's backend is heavily Kafka-driven. Modeling order state transitions as events, handling consumer failures, and ensuring idempotency is worth more here than at most companies.
Domain awareness. Know how a dark store differs from a restaurant, what the order state machine looks like (placed, accepted, preparing, picked up, delivered, cancelled), and why dispatch uses ETA not distance.
The Hiring Manager Round Tests Ownership
For SDE-2 and above, there is a hiring manager conversation that covers three things: a technical deep dive into one of your past projects, a system design extension (usually a follow-up on your earlier HLD round), and behavioral questions about ownership and decision-making.
Interviewers probe for similar signals: did you drive decisions yourself or execute someone else's plan? How did you handle a disagreement with your tech lead?
Prepare two or three projects where you were the decision-maker, not just the implementer. Know the tradeoffs you made and what you would change. "We used Postgres because it was the default" will not cut it.
What Each Level Actually Requires
SDE-1: No HLD required. DSA must be solid. LLD is expected to be functional, not necessarily elegant. Interviewers are looking for strong fundamentals and growth potential.
SDE-2: HLD is the central filter. You need to drive the design conversation, propose components unprompted, and handle follow-up challenges on failure modes and scale. LLD code quality standards are higher than SDE-1.
SDE-3: The design must demonstrate operational maturity. Monitoring, deployment strategy, data migration, and failure recovery are in scope. You should be able to defend every tradeoff. Generic answers ("use Kafka for async") without reasoning get pushed back hard.
Common Mistakes That Cost Offers
Designing for the wrong domain. Candidates who practice only "design Twitter" or "design YouTube" come in and try to apply those templates to food delivery problems. The fit is bad. Order management has stricter consistency requirements than social feeds. Dispatch systems have real-time constraints that URL shorteners do not.
Skipping the order state machine. Almost every Swiggy HLD problem touches order lifecycle eventually. If you cannot name the states fluently, you will stumble when the interviewer adds "now what happens if the restaurant rejects the order five minutes after the customer pays?"
Weak on Kafka semantics. At-least-once delivery and idempotency come up in roughly half of reported HLD questions. Know what at-least-once vs. exactly-once means in practice and how to make downstream services idempotent.
Under-specifying the data model. If you say "store orders in a database" without talking about schema, indexes, or partitioning, expect follow-up pressure until you do.
Treating LLD as a side question. The machine coding round is a full filter. Candidates who treat it as a sketch to rush past arrive underprepared.
How to Prepare by Level
SDE-1 (6 to 8 weeks): DSA fundamentals first (weeks 1 to 3), then LLD practice on Splitwise, Parking Lot, and Meeting Scheduler (weeks 4 to 6), then timed mock coding (weeks 7 to 8).
SDE-2 (8 to 10 weeks): DSA refresh plus medium-hard problems, then two weeks of full LLD implementations, then three weeks on food delivery HLD (dispatch, inventory, event pipelines). Save the last two weeks for mock interviews and Swiggy domain study: read about how Instamart works and what a dark store is.
SDE-3 (10 to 12 weeks): Same as SDE-2, plus deeper distributed systems fundamentals (Kafka, consistent hashing, CAP), two to three project stories with full tradeoff narratives, and out-loud practice for the hiring manager round.
For HLD specifically, practice the food delivery order lifecycle end to end before you walk in. Placement through payment, kitchen confirmation, dispatch assignment, pickup, and delivery with failure handling at each stage. If you can narrate that fluently, you will be better prepared than most candidates who walk in.
SpaceComplexity lets you practice this out loud with an AI interviewer that asks domain-specific follow-ups. Typing a design on paper is not the same skill as narrating it under pressure. You find that out at the worst possible time if you do not practice it first.
How Fast the Loop Moves
- Application to OA: 1 to 2 weeks
- OA results to first technical round: 3 to 7 days
- Full loop (all technical rounds): 1 to 2 weeks
- Offer or reject: 1 week after final round
Total: 3 to 5 weeks from OA to decision. The pace is faster than most FAANG loops. Once you are in the loop, rounds tend to be scheduled quickly. Do not book yourself a 12-week prep plan once the OA invite lands.