Swiggy Software Engineer Interview: Every Round, Decoded

Swiggy delivers dinner in 30 minutes. The interview takes about 13 days. Those two facts tell you everything you need to know about what you're walking into.

The process looks meaningfully different by level. SDE-1 is mostly DSA. SDE-2 adds machine coding and low-level design. SDE-3 turns the system design dial all the way up. Same company, three very different tests.

What You're Walking Into

Swiggy runs over 400 microservices in production. More than 130 of them sit directly in the order-fulfilment path. The stack spans Go, Java, Python, Scala, and Rust, backed by Kafka, Redis, ScyllaDB, and Postgres.

If you join Swiggy, you will work on distributed systems at serious scale. The interview reflects that. Even for junior roles, interviewers are looking for engineers who think about correctness and efficiency, not just code that compiles and waves politely at the test runner.

The Swiggy engineering blog is worth reading before your interviews. It signals what the team actually cares about and, helpfully, gives you real technical vocabulary to drop in system design rounds instead of just saying "Kafka for scalability" and then staring at the wall.

The Full Process at a Glance

Stage	SDE-1	SDE-2	SDE-3
Online Assessment	Yes	Yes	Sometimes
DSA Technical Rounds	2	2	1
Machine Coding	No	Yes	Yes
LLD Round	No	Yes	Yes
System Design (HLD)	No	Sometimes	Yes
Hiring Manager	Yes	Yes	Yes
Total Rounds	4-5	5-6	5-6

Glassdoor data across ~500 submissions puts the average process at about 13 days and difficulty at 3.05 out of 5. Medium spice. Enough to matter.

Round 1: Online Assessment

The OA runs 90 minutes on HackerEarth or HackerRank with two or three problems. Difficulty sits firmly in LeetCode medium territory. You are being screened for pattern recognition speed, not exotic algorithmic knowledge.

The problems that appear repeatedly are graphs (BFS/DFS, island counting, shortest paths), trees (LCA, tree views, sum root to leaf), and dynamic programming (coin change variants, subset sum, edit distance). Sliding window and prefix sum cover most array and string problems.

Specific examples from candidate reports:

Count Islands, 4-directional connectivity
Coin Change II (number of ways to make amount)
Longest Valid Parenthesis
Given an array and a target average, find any contiguous subarray with that exact average
Trie with search and startsWith operations

One thing worth noting: if the job description mentions Go, practice in Go. The algorithm doesn't change but you do not want to spend 15 minutes fighting slice syntax when you have 90 minutes and three problems staring at you.

Round 2: DSA Technical Rounds

SDE-1 gets two. SDE-2 typically gets two as well, before moving into design rounds. Each is 60-70 minutes with one or two medium-difficulty problems solved live, usually in a shared editor or directly on LeetCode with test cases visible.

Most candidates discover this the hard way: the interviewer is watching your process, not waiting for the answer. Start with clarifying questions. Walk through your approach before you type a single line. The code itself matters less than whether you can explain why your solution works and where it might break. See what this looks like in practice.

Topics that keep coming up at SDE-2:

Medium-hard graph problems (graph coloring, topological ordering, shortest path with constraints)
Tree problems with non-trivial modifications
DP on strings or intervals
Concurrency basics for backend roles (mutexes, race conditions in Go or Java)

One candidate reported a question about finding whether any subarray has a specific average. That is a non-obvious prefix sum transformation. It rewards engineers who recognize the reduction, not those who memorized a list and got unlucky.

Round 3: Machine Coding

This is the round most candidates underestimate. You get one to two hours to design and implement a working mini-application from a requirements description. No scaffolding. No starter code. Just you, a blank file, and the slowly dawning realization that maybe you should have drawn a class diagram first.

The bar is clean, extensible OOP code, not a brute-force that technically works. Interviewers evaluate database schema design, class hierarchy, edge-case handling, and whether the code could realistically be extended by someone who is not currently caffeinated and panicking.

Rick and Morty meme about technical interview going from a 20-minute adventure to shock at unexpected complexity That "let's just go in and code" energy, right up until someone asks you to add variant pricing.

Swiggy machine coding problems that have appeared:

A food catalog system with restaurants, item categories, variant groups, and add-ons
A food delivery order state machine (placed, accepted, preparing, out for delivery, delivered)
Snake and Ladder (used as a proxy for OOP discipline)
A booking system with slot management

The failure mode is diving into code immediately. Spend the first 10-12 minutes asking questions, drawing the class diagram, and agreeing on scope. Then write. The interviewer is judging how you structure your time and your code, not whether you implemented every requirement.

Practice two or three machine coding problems on workat.tech before the interview. Time yourself. Review your code for SOLID violations. Be honest with yourself about what you find.

Round 4: Low-Level Design

The LLD round overlaps with machine coding but is more conversational. You are given a scenario and expected to walk through the class structure, API contracts, and database schema.

A catalog system for a multi-restaurant platform is a documented example. You might be asked to design entity relationships, talk through normalization trade-offs, and then extend the design to handle a new requirement like variant pricing or add-on groups. The right answer acknowledges trade-offs rather than asserting a single perfect solution.

Bring SOLID principles to every LLD discussion. Talk about single responsibility explicitly. When you make a trade-off between flexibility and simplicity, name it out loud. Saying "I'm choosing composition over inheritance here because discount rules change frequently" is much stronger than just writing it and hoping they notice.

Round 5: System Design (HLD)

SDE-2s sometimes get this. SDE-3s always do. You are expected to design a large-scale distributed system in 45-60 minutes.

Documented Swiggy HLD problems include:

Real-time delivery partner location tracking system
Cab booking backend (Uber/Ola-style)
A system for user registration and file uploads at scale
Order management for a food delivery platform

For real-time tracking specifically, Swiggy's own architecture uses Kafka for location event streaming, an in-memory state store for current positions, and WebSocket gateways for client-facing updates. Understanding why each layer exists is more valuable than naming them. An interviewer who asks "why Kafka over a database?" wants to hear about write volume, decoupling, and replay. Not just "it's scalable".

For SDE-2, the expectation is fluency with core distributed systems concepts: horizontal scaling, caching strategies, message queues, CAP theorem trade-offs. For SDE-3, the bar jumps to knowing failure modes, monitoring strategy, and how you would evolve the design over 18 months.

Read a few posts on the Swiggy engineering blog about resilient microservices design. The vocabulary and real problems they've solved are exactly what interviewers want to hear you reference. It also genuinely helps to know what the team has actually shipped.

Round 6: Hiring Manager

The final round is a 30-45 minute conversation with your prospective hiring manager or a senior team leader. Not a casual chat. Not a formality.

Expect three things. First, a project deep-dive where you walk through something technically complex you've built. They want to understand your decision-making, not your accomplishments. Second, behavioral questions around how you handle ambiguity, disagreement, or incomplete requirements. Swiggy moves fast and the team values alignment with that culture. Third, your questions for them. The questions you ask signal how seriously you have thought about the role. Ask about the team's biggest technical challenge, the on-call rotation, or a recent architectural decision. Skip the perks question.

Common Mistakes

LinkedIn post from Google recruiter about candidate who panicked and closed Spotify and 14 Stack Overflow tabs while sharing their screen At least they recovered. Closing tabs live is embarrassing. Going silent for three minutes and staring at the prompt is worse.

Jumping to code without a plan. The OA scores correctness but the technical rounds score process. These are different things. Build the habit of articulating your approach before your hands move.

Treating machine coding as a hack session. Unclean code that works will score lower than clean code that is 80% complete. Write code you would be willing to submit in a pull request.

Underestimating LLD. Candidates who focus only on DSA walk into the LLD round surprised and underprepared. If you are interviewing for SDE-2 or above, spend real time on OOP design before the interview date.

Generic system design answers. "Use Kafka" is not a design. "Use Kafka here because the write throughput from 200K concurrent delivery partners would saturate any relational write path, and we need ordering guarantees per partner without a global lock" is a design.

Going silent during DSA. Interviewers are calibrated to read candidate process, not just output. Narrating your thinking out loud gives them something to score. Silence gives them nothing to write down, and nothing written down means nothing to advocate for in the debrief.

If you want to practice narrating your reasoning out loud under realistic pressure, SpaceComplexity runs AI-powered voice mock interviews that score exactly this, including how you handle hints and whether you communicate your approach before coding.

A Realistic Prep Timeline

Four weeks out: Run a cold diagnostic. Do 5-10 untimed problems across graphs, trees, DP, and strings to identify your weakest category. Focus that week exclusively on it.

Three weeks out: Machine coding practice if you are applying for SDE-2+. One problem a day with a two-hour timer. Review your code afterward for SOLID violations.

Two weeks out: System design. Pick two or three HLD problems (delivery tracking, order management, ride matching) and work through them with the constraint of explaining every choice out loud.

One week out: Timed mixed practice. Simulate the OA format: 90 minutes, three problems, no hints.

Final days: Light review and logistics. No new material. Read two or three Swiggy engineering blog posts so you have concrete technical conversations ready. The full pre-interview consolidation strategy covers what to do in the final stretch.

Key Takeaways

SDE-1: focus on DSA and communication. Medium-difficulty LeetCode solved cleanly, out loud.
SDE-2: DSA plus clean OOP in machine coding plus LLD fluency. System design may appear.
SDE-3: deep system design with trade-off reasoning. Machine coding still happens.
Graphs, trees, and DP show up most. Sliding window and prefix sum cover most array and string problems.
Machine coding is about code quality, not feature count. Finish 80% cleanly.
The hiring manager round is evaluative. Prepare your project deep-dive.
The full process runs about two weeks. Start prep four weeks out to give yourself a buffer.