Swiggy Interview Guide (2026)

1Snapshot, read this first#

The one thing to understand about Swiggy:

• It is a high-scale consumer internet company where correctness, latency, and real-world trade-offs beat algorithm trivia.
• They test whether you can build, not just solve puzzles.
• The world your answers get judged against: dinner hour hits, hundreds of thousands of orders land in a few minutes, each needs a nearby rider in under a second, and a payment that must never double-charge.
• The machine-coding / LLD round is where strong LeetCode grinders get caught off guard, because it rewards a skill they never practiced.

2Getting the call (the part most guides skip)#

A referral is the single highest-leverage move, full stop.

• Swiggy engineers get a bonus when their referral is hired, so most are happy to refer a credible resume.
• Find second-degree connections on LinkedIn who work at Swiggy.
• Send a short, specific note: "I build backend systems in Java/Go, 3 yrs, here is a project relevant to your delivery scale, resume attached."
• A referred resume gets looked at by a human within days. A cold application often sits in a queue and never does.

Resume rules that matter here:

• One page for anyone under ~8 years of experience. Two pages past that, never more.
• Lead every bullet with impact and a number. The recruiter screening you thinks in p99s and conversion rates, so a bullet with no number reads as a bullet with no impact.
• Strong bullet: "Redesigned order-assignment service to batch DB writes and add Redis caching, cutting p99 latency from 820ms to 190ms and handling 4x peak traffic during IPL match surges." It names the change, the mechanism, and two numbers.
• Weak bullet to avoid: "Worked on the order service and improved performance." No mechanism, no number, nothing to interview you on.
• Show scale and ownership, not just features: QPS handled, data volume, users served, rupees saved, incidents prevented.

ATS and keywords:

• Mirror the job description. For backend roles that usually means Java or Go, Spring Boot, microservices, Kafka, Redis, MySQL/Postgres, AWS, Docker/Kubernetes.
• For data/ML-adjacent roles, add the stack named in the posting.
• Put these in a real "Skills" line, then prove each one inside a bullet.
• Do not keyword-stuff a skill you cannot defend. The interviewer will ask you to explain exactly the thing you listed.

How people actually get shortlisted at Swiggy:

• Referrals (best), through current employees. Highest hit rate by a wide margin.
• Off-campus applications via the Swiggy careers portal and LinkedIn job posts. Apply within the first day or two of a posting going live, before the pile grows.
• Campus hiring for SDE-1 from target engineering colleges, often with an online coding test (HackerRank/HackerEarth style) as the first filter, usually 2 to 3 DSA problems on a timer.
• Recruiter inbound. If your profile shows relevant scale experience, Swiggy recruiters do reach out on LinkedIn. Keep your headline and top project crisp and scale-flavored so the first screen already reads like a fit.

3The loop at a glance#

Composition varies by team and level:

• SDE-1 may skip heavy system design.
• SDE-2/3 almost always include it.
• Some teams fold machine-coding into the coding rounds, so do not be surprised if a "coding" round suddenly asks you to design and build a small cart.

Here is the shape of a typical loop:

The bar-raiser is not a formality:

• Usually a senior engineer from outside your target team whose job is to protect the hiring bar.
• They can veto the whole loop.
• Treat that round as seriously as the technical ones.

4The coding / technical rounds, patterns, not problems#

Swiggy's DSA bar sits around LeetCode Medium, with a couple of Mediums that tilt toward Hard. They care less about obscure algorithms and more about whether you reason cleanly and ship a correct, optimal solution.

The pattern set is small. Think fewer than ten core patterns, reused constantly:

• Arrays and strings. Two pointers, sliding window, prefix sums. Longest substring without repeats, minimum window substring, subarray sum equals K.
• Hashing. Frequency maps, grouping, deduplication. Extremely common because it mirrors real backend work like counting events or deduping order IDs.
• Trees and graphs. BFS/DFS, level-order traversal, shortest path, topological sort, number-of-islands style grid problems. Expect at least one traversal.
• Heaps / priority queues. Top-K, merge K sorted lists, scheduling. These map directly to delivery and assignment logic, so they show up often.
• Dynamic programming. The medium flavors only: coin change, longest common subsequence, house robber, grid unique paths. They rarely go exotic, so do not burn a week on bitmask DP.
• Binary search. On answer space ("minimum capacity to ship packages in D days," "smallest divisor given a threshold"), not just on sorted arrays. Candidates miss these the most.
• Stacks and intervals. Valid parentheses, next greater element, merge intervals, meeting rooms.

How to practice:

• Do ~120-150 curated mediums across these buckets rather than grinding 500 random problems.
• Solve, then re-solve cold two days later. Spaced repetition on the ones you got wrong beats new problems.
• Always state time and space complexity out loud, even when nobody asked.

How to win the round:

1. Clarify first. Restate the problem, confirm input ranges (is n up to 10^3 or 10^7, that decides your target complexity), ask about edge cases: empty input, duplicates, negatives, a single element. This signals seniority before you write a line.
2. Communicate continuously. Narrate your approach before coding. Interviewers score your thinking, not just the final answer, and a silent screen gives them nothing to score.
3. Start correct, then optimize. State the brute force and its complexity ("this is O(n squared), I think we can get to O(n) with a hash map"), then improve. Half-finished clever beats nothing but loses to finished simple.
4. Write clean code. Good names, small helper functions, no 60-line method. Swiggy reads your code as a proxy for your production code, so write it like a teammate reads it tomorrow.
5. Test it yourself. Walk through one normal case and one edge case line by line before you say "done." Catching your own off-by-one is a strong signal. Waiting for the interviewer to catch it is not.

5Machine coding & LLD, the round that decides it#

This is the round that separates Swiggy, and its peers among high-scale Indian product companies, from a pure algorithm interview.

• You get a real-world problem and build a small, working, extensible program (or design the class model) in 60-90 minutes.
• The output is expected to compile and run with a small demo.
• This is the single most common place strong LeetCoders fail, because clean OOP under a clock is a different muscle than solving graph problems.

Typical prompts (realistic, not leaked):

• A food ordering / cart system: add items, apply offers, compute bill, handle multiple restaurants in one order.
• A delivery-partner assignment service: match orders to nearby available riders with a pluggable matching rule.
• A parking lot, elevator system, splitwise/expense-sharing, or ride-hailing matcher: the classic LLD canon every Indian product company reuses.
• An in-memory rate limiter, LRU cache, or tiny booking system that actually compiles and runs.

A framework that scores well:

1. Clarify scope and lock the MVP. You cannot build everything in 60 minutes. Say it out loud: "I will build add-to-cart, apply one discount, and compute total. I will leave multi-restaurant and taxes as extensions." Agreeing on the core 2-3 features up front stops you from drowning.
2. Model the entities. Identify the nouns (Order, Item, Restaurant, DeliveryPartner) and sketch clean classes with one clear responsibility each. Keep data and behavior together.
3. Apply the right abstractions. Use an interface or strategy for anything that varies: pricing, assignment, discount rules. A DiscountStrategy interface with FlatDiscount and PercentageDiscount implementations is exactly the signal they want, SOLID in action, not recited.
4. Make it work. Compile and run with a small main that demonstrates the flow: create a cart, add two items, apply a discount, print the bill. Working code beats a beautiful but broken design every single time.
5. Keep it extensible. Show where a new discount type or assignment rule plugs in without editing existing classes. That is open/closed, and saying "to add a buy-one-get-one offer I just write a new strategy class and register it, nothing else changes" is a near-guaranteed point.

Here is the kind of abstraction that reads as senior in this round:

interface DiscountStrategy {
    double apply(double subtotal);
}

class PercentageDiscount implements DiscountStrategy {
    private final double percent;
    PercentageDiscount(double percent) { this.percent = percent; }
    public double apply(double subtotal) {
        return subtotal - (subtotal * percent / 100);
    }
}

class Cart {
    private final List<Item> items = new ArrayList<>();
    private DiscountStrategy discount = subtotal -> subtotal; // no-op default

    void addItem(Item item) { items.add(item); }
    void setDiscount(DiscountStrategy d) { this.discount = d; }

    double total() {
        double subtotal = items.stream().mapToDouble(Item::price).sum();
        return discount.apply(subtotal);
    }
}

What makes this score:

• No giant switch on discount type.
• No hardcoded 10 percent buried in total().
• A new offer is a new class. That is the whole game.

System design (for SDE-2/3):

• Expect prompts straight from Swiggy's world: "design the food-delivery order flow," "design a nearby-restaurants/geo-search service," "design a surge-pricing system," "design a notification/push service at scale."
• Use this skeleton and walk it in order:

The trade-offs that earn the senior signal:

• Traffic is bursty and spikes hard at lunch and dinner, so you need autoscaling and queues to absorb the surge.
• Geo queries for nearby restaurants and riders want a geohash or quadtree index, not a naive distance scan.
• Payments must be idempotent so a retry never double-charges.
• Order status can be eventually consistent, but a payment ledger must be strongly consistent.
• Naming those trade-offs by hand is what gets you the senior signal, not reciting "use Kafka and Redis."

6Behavioral & culture fit#

Swiggy's culture leans into consumer obsession, ownership, speed, and frugality, the mindset of a company that moves fast and ships at scale.

What the values sound like in practice:

• Consumer first.
• Ownership, "act like an owner."
• Bias for action and speed.
• High trust and transparency.
• Doing more with less.

What the rounds are actually checking:

• Whether you operate this way, not whether you can recite the values page.
• They listen for "I decided," "I owned," "I shipped," and a number at the end.

Prepare 5-6 STAR stories (Situation, Task, Action, Result) covering:

• A hard technical decision.
• A time you owned something end to end.
• A conflict with a teammate or stakeholder.
• A failure and what you learned.
• A time you shipped fast under pressure.
• One story can often serve two prompts, so pick ones rich enough to stretch, and always end with a quantified result.

One full worked STAR example:

• Situation: Our checkout service was timing out during peak dinner hours. Around 3% of orders failed to confirm, and support tickets spiked.
• Task: As the owning engineer, I had to cut the failure rate without a long re-architecture, because the festive-season peak was two weeks away.
• Action: I profiled the request path and found synchronous calls to the loyalty-points service were the bottleneck. I made points accrual asynchronous via a Kafka event, added a Redis cache for the user's active offers, and set a circuit breaker so a loyalty outage could no longer block an order. I shipped behind a feature flag and ramped it over three days while watching dashboards.
• Result: Checkout failure during peak dropped from ~3% to under 0.3%, p99 latency fell ~40%, and we handled the festive peak with zero order-confirmation incidents.

How to deliver them:

• Tell your stories in that structure.
• Keep them under two minutes.
• Make sure the result has a number. A story with no number is a story about a task, not about impact, and that gap is exactly what Swiggy is probing.

7Your prep plan#

4-week plan (comfortable):

• Week 1, DSA foundations. Arrays, strings, hashing, two pointers, sliding window. ~6 problems/day, re-solve weak ones cold the next day.
• Week 2, breadth. Trees, graphs, heaps, binary search (including on answer space), DP mediums. Start timing yourself to 30 minutes per problem.
• Week 3, machine coding / LLD. Build 5-6 small systems end to end (cart with discount strategy, parking lot, rate limiter, splitwise, LRU cache). Practice compiling and running inside 60 minutes, with a timer running.
• Week 4, design and behavioral. 4-5 design mocks using the skeleton above, write out your 6 STAR stories, do 2 full mock loops with a friend playing interviewer.

2-week plan (focused):

• Days 1-5. Grind mediums across all core patterns, re-solve every miss two days later.
• Days 6-9. Machine coding / LLD daily: one working app per day with clean abstractions and a running main.
• Days 10-12. System design skeleton plus 3 delivery-flavored prompts (order flow, geo-search, surge pricing).
• Days 13-14. Behavioral stories plus one timed mock interview end to end.

2-day crash plan:

• Day 1. Re-solve the top 30 patterns (sliding window, BFS/DFS, heaps, binary-search-on-answer, intervals, DP basics). Build one LLD app end to end, a cart with a discount strategy, and make sure it compiles.
• Day 2. One system design walkthrough ("design food delivery order flow"), write 4 STAR stories each ending in a number, and review your resume projects so you can speak to every line without hesitating.

8Why people get rejected at Swiggy#

1. Great at LeetCode, weak at building. They freeze in machine-coding because they have never written a clean, running mini-app under time pressure. The number one killer. Fix it by building, not by solving more arrays problems.
2. Silent problem solving. Solving correctly but not narrating leaves the interviewer unable to score the reasoning, and that reads as a red flag, not a neutral.
3. No complexity analysis. Not stating time and space, or stating it wrong, signals shallow fundamentals even when the code works.
4. One-big-class LLD. No interfaces, no separation of concerns, hardcoded logic. It fails the "would this survive in production" test, which is the exact question the round is secretly asking.
5. Hand-wavy system design. Jumping to "use Kafka and Redis" without quantifying scale, choosing a data model, or handling failure. Buzzwords without trade-offs is an instant downgrade.
6. Thin behavioral answers. Vague "we did X as a team" with no personal ownership and no numbers, the exact opposite of Swiggy's act-like-an-owner expectation.

9The offer, comp & negotiation#

Swiggy compensation is competitive for Indian product companies.

• Packages typically split into base salary, a joining/retention component, and ESOPs (RSU-style equity in the private company).
• Rough total-comp ranges: SDE-1 ~₹18-30 LPA, SDE-2 ~₹30-50 LPA, SDE-3/Senior ~₹50-80+ LPA.
• ESOPs form a larger slice of the package as you move up.
• Numbers vary by team, location, and your current comp, so treat these as bands, not promises.

Negotiation tips for Swiggy's context:

1. Anchor on a competing offer or a documented current CTC. The strongest lever is a real alternative, and even a credible verbal competing process helps. Share numbers honestly. Fabricated offers get caught in background checks and can cost you the whole thing.
2. Negotiate the whole package, not just base. Ask about the ESOP grant value, the vesting schedule (typically 4 years with a 1-year cliff), and the joining bonus separately. There is often more room in equity and sign-on than in base, because base pushes up the whole band for your level.
3. Be specific and calm. Say "based on my experience and the market for this level, I was targeting X total comp, can we get there?" Give the recruiter one concrete number to take to their panel, not a vague "a bit more." And get the final offer in writing before you resign anywhere, no exceptions.

Want a personalized, dated prep schedule built around your interview date and current level? Map these rounds onto a day-by-day plan and start with the machine-coding and DSA work first, that is where the signal is strongest.