Swiggy Onsite Interview: Every Round, What It Tests, and How to Prepare

You made it past the HackerEarth OA. Congratulations. Now comes the actual interview: four or five back-to-back rounds, virtual, covering algorithms, a live coding build, system design with a delivery-domain twist, and a hiring manager who wants to see you sweat over your own past decisions.

This guide covers the full Swiggy onsite loop for SDE-1 and SDE-2, what each round is actually testing, and how to prepare without wasting two months of evenings on the wrong things.

How the Swiggy Onsite Is Structured

The OA (HackerEarth or HackerRank, two to three DSA problems, 90 minutes) is a filter. If you cleared it, the onsite typically runs virtual and looks like this:

Round	Duration	What's Tested
DSA Round 1	60-90 min	Pattern recognition, clean code, complexity
DSA Round 2 (SDE-2+)	60-90 min	Harder problems, multiple approaches
Machine Coding	60-90 min	Working OO implementation, design judgment
System Design	45-60 min	HLD + LLD, Swiggy domain, tradeoffs
Hiring Manager	30-45 min	Ownership, motivation, behavioral depth

SDE-1 typically sees DSA plus Machine Coding plus HM. SDE-2 sees all five. Rounds usually land on the same day or across two consecutive days. Don't schedule anything after 6 PM on interview day. You will need that time to stare at the ceiling and process what just happened.

DSA Rounds: Pattern Recognition Over Memorization

The DSA rounds are testing whether you can identify the right structure, not whether you've memorized the exact problem. Difficulty sits in LeetCode medium territory for SDE-1. SDE-2 rounds occasionally touch hard problems when the interviewer wants a second approach or a space optimization.

Graphs show up constantly. Swiggy models a lot of its real work as graphs: delivery networks, catalog traversals, dependency chains. Expect BFS-based shortest-path variants, grid traversal problems ("count islands" dressed up as warehouse grids), and "find all connected components" wearing a delivery costume. The twist: interviewers sometimes describe problems in Swiggy domain language first. "Riders and restaurants" is a bipartite graph. Don't let the framing fool you. Parse through the delivery metaphor, find the structure underneath, and code the standard algorithm.

Trees come next. Root-to-leaf sums, LCA, serialize/deserialize, subtree equality. The interviewer will ask you to trace your DFS stack by hand before you've finished coding. Run your edge case checklist in parallel with the implementation. Null root, single node, fully skewed tree: name them before you're asked.

Dynamic programming rounds out the usual set. Coin change, edit distance, longest valid parentheses. For SDE-2, expect "can you reduce the space?" right after you present your memoized solution. Know both versions of whatever DP problems you prep.

A candidate from the July 2025 loop reported that the interviewer asked for the invariant behind the solution before accepting the code. Not just "what does this do" but "why is this correct." That's a higher bar than most interview prep targets. Be ready for it.

Bring every problem back to one of six structural families before you touch the keyboard: two pointers, sliding window, prefix sum, DFS/BFS, DP, binary search. The DSA for backend engineers guide covers priority order if you're short on prep time.

Machine Coding: The Round That Surprises Everyone

This is where candidates get humbled. You have 60 to 90 minutes to design and build a working mini-application from scratch, in a language of your choice, in a shared editor.

Not a diagram. Not pseudocode. Working code. Code that runs.

Common prompts across recent interview cycles:

A Splitwise-style expense split system (groups, users, settlement logic, partial payments)
A restaurant catalog model (items, categories, variant groups, pricing per combination)
A job scheduler with add, cancel, pause, and status query operations
A vaccine matching system (providers, takers, availability, booking)
A ride-sharing system (riders, drivers, trips, status transitions, allocation logic)

The evaluator is watching three things: whether you spend five minutes on the entity model before writing a single line of code, whether your code actually runs without last-minute patches, and how you handle scope decisions under time pressure.

Swiggy machine coding prompts are deliberately open-ended. Scope it yourself. "Should I handle concurrent users? Do I need persistence? Are splits fractional?" Get answers, then state your scope out loud: "I'll skip auth and assume single-threaded, and I'll flag where I'd add a lock." Don't wait for the interviewer to tell you what to build. Propose a scope, get agreement, execute.

Design for extensibility from minute one. The interviewer will ask you to extend the system after the initial build. "Now add partial payments." "Add priority levels to the job queue." An entity model that can absorb a new requirement beats a brittle implementation that barely compiled the first time.

Budget roughly 10 minutes for entity design and API sketch, 45 minutes for core implementation, and 10 minutes for the extension ask. Most rejections in this round come from candidates who spend 40 minutes at the whiteboard and never produce working code.

System Design: LLD Plus HLD With a Swiggy Lens

Swiggy system design rounds are not abstract FAANG infrastructure discussions. The interviewer frames the problem as a Swiggy feature, and they expect you to know the domain well enough to make sensible choices.

Common prompts:

Design Swiggy Instamart catalog with real-time inventory, availability, and search
Design the order matching and delivery allocation system
Design a real-time driver location tracking service (high write throughput, low-latency reads)
Design a notification system for order status updates across channels

The round typically splits: 20 minutes on LLD (class diagrams, API contracts, database schema) and 25 minutes on HLD (services, data flow, scaling, failure handling). Swiggy's stack leans on Go and Java for services, MySQL and PostgreSQL for relational data, Redis for caching and geospatial queries, Elasticsearch for catalog search, and Kafka for event streaming. Knowing the stack helps, but making choices that make sense at Swiggy's actual scale matters more.

Every design choice needs both sides named. "I chose Redis GEORADIUS for driver lookup because it handles high write frequency and gives sub-millisecond proximity queries, at the cost of limited query flexibility compared to PostGIS" is a real answer. "Redis because it's fast" is not. Without the cost half, the answer reads as overconfidence.

For the LLD portion, draw the entity-relationship model before touching services. A delivery has multiple status transitions. An item can belong to multiple categories. A driver can be in only one active trip. These constraints need to show up in your schema. The food delivery system design walkthrough covers the core architecture you should know cold before this round.

Hiring Manager Round: They Want Ownership, Not Story Time

The HM round is behavioral, but Swiggy's version has a specific shape. The interviewer wants to see strong opinions about technical decisions on your own projects and to watch you defend them under pressure.

Prepare to go deep on your best project for 20 minutes. Not what you built, but why you made each architectural choice, what you'd do differently now, and how you handled the hardest production problem. SDE-2+ interviewers follow the thread until they find the wall. Don't summarize. Narrate.

"Tell me about a time you took end-to-end ownership of a feature" is the core behavioral theme. The answer they want: what decision was unclear, what you did without being asked, what the concrete outcome was. Vague talk about "driving alignment" lands nowhere. Specific technical decisions with consequences land everywhere.

For motivation, the bar is knowing what Swiggy actually builds. Know Instamart (10-minute grocery delivery), Swiggy Genie (courier service), Snacc (quick commerce expansion), and the supply chain infrastructure powering sub-15-minute delivery. Generic answers about "scale and interesting problems" don't differentiate you from the other six candidates they're interviewing that day.

Narrating your reasoning is the underlying skill Swiggy scores across every round. Technical interview communication covers doing it under pressure without sounding like you memorized a script.

Common Mistakes

Skipping machine coding warm-up. Most candidates prep DSA and system design heavily but never practice building a complete working application in 90 minutes. Do a timed build of Splitwise or a parking lot system from scratch before the interview. Seriously, do one. One timed build reveals more gaps than two weeks of reading about OO design.

Treating system design as a FAANG problem. Generic microservices diagrams without Swiggy domain context get low marks. Know what Instamart is. Know why driver location tracking is write-heavy. Know what order allocation looks like under surge demand. Generic architecture with no domain awareness is the fastest way to the rejection pile.

Going silent when stuck. A two-minute silence in a DSA round is a fail signal even if you eventually get the answer. Narrate your dead end. Pivot out loud. Stuck in a coding interview has the recovery script for when your brain stops cooperating mid-round.

Not preparing a "go deep" project. If you can't defend every decision in your best project for 20 minutes, the HM round ends early. Pick one project. Know it cold. Practice defending the worst decisions you made on it.

Prep Timeline

Four to six weeks if you're coming from a product company with solid fundamentals. Two weeks on DSA pattern review (graphs, trees, DP). One week on machine coding (three timed builds minimum, not optional). One week on system design with Swiggy-flavored prompts. Final week on behavioral prep and end-to-end mocks.

Eight to ten weeks if you're rusty on system design or haven't done machine coding before. Add a week of OO design fundamentals before the machine coding phase.

Voice-based mock interviews at SpaceComplexity let you practice narrating your reasoning on DSA and system design problems under realistic time pressure. The rubric-based feedback tells you whether your trade-off articulation is actually landing, not just whether your solution is technically correct.