Swiggy Software Engineer Interview: Questions & Prep (2026)

Swiggy software engineer interviews test whether you can build systems that stay up when a city orders dinner at the same time. The product is real-time by nature — live order tracking, driver allocation, geo-indexed search, and dispatch decisions that expire in seconds — so system design rounds lean heavily on streaming data, location services, and graceful degradation under peak load (IPL finals and New Year's Eve are the canonical stress tests). The loop typically runs recruiter screen → one or two DSA rounds → a system design round (for SDE2 and above) → a hiring manager/behavioral round. For SDE1, design is lighter or replaced by a problem-solving round; for SDE3 and above, expect deeper architecture discussion and trade-off defence. Swiggy's public engineering blog, Swiggy Bytes, is fair game for preparation — reading their published posts on dispatch, data platforms, and service architecture gives you vocabulary that maps directly to interview questions. If you're earlier in the funnel, start with the broader guide on [how to get hired at Swiggy](/company_guide/how-to-get-hired-at-swiggy.html).

1. Design a real-time order tracking system: a customer watches their delivery partner move on a map with updates every few seconds, at the scale of lakhs of concurrent orders.
2. Design the driver-allocation (dispatch) system: given an incoming order, pick the best delivery partner within a second, accounting for distance, current load, and food prep time.
3. How would you geo-index millions of restaurants and delivery partners to answer "who is near this customer" queries with low latency? Compare geohash, quadtree, and S2-style approaches.
4. It's an IPL final and traffic is 3x forecast. Which services do you degrade, which do you protect, and how do you build that decision into the architecture beforehand?
5. Given a stream of GPS pings from delivery partners (some delayed, some out of order), compute each partner's live ETA to the drop point.
6. Design a rate limiter for a public API gateway that must be fair across clients and survive a node failure.
7. You have a list of restaurant open/close intervals; merge overlapping intervals and answer "is this restaurant serviceable at time T" efficiently.
8. Find the k nearest delivery partners to a given order location from a large, frequently updating set of coordinates.
9. Design the menu and catalog service: restaurant menus change often, item availability flips in real time, and reads outnumber writes by orders of magnitude.
10. A downstream payment service starts timing out during peak. Walk through how your order service should behave — retries, circuit breaking, idempotency, and what the customer sees.
11. Implement an LRU cache, then discuss where you'd actually use one in a food-delivery stack and what invalidation problem it creates.
12. Tell me about a time you owned a production incident end to end — detection, mitigation, and the prevention work afterwards.

Q: Find the k nearest delivery partners to an order location (DSA walkthrough).

Start by clarifying scale and freshness: how many partners (say lakhs per city), and how stale can positions be (a few seconds)? The naive approach — compute distance to every partner and sort — is O(n log n) per query and fine for a single query, but collapses at dispatch volume. Better: maintain a max-heap of size k while scanning, giving O(n log k). Best for repeated queries: pre-bucket partners into a spatial grid (geohash cells), fetch the order's cell plus its eight neighbours, and only compute distances within that candidate set, expanding rings if you have fewer than k candidates. Walk through edge cases aloud: partners on cell boundaries, empty cells in low-density zones, and the staleness problem — a partner who pinged 30 seconds ago may have moved cells. State the complexity of each approach, code the heap version cleanly, and mention that in production you'd care about the 99th percentile latency of the grid lookup, not the average. Interviewers reward candidates who connect the textbook structure to the operational reality.

Q: Design Swiggy's dispatch system (system design outline).

Clarify requirements first: assign an incoming order to a delivery partner within roughly a second, optimising delivery time and partner utilisation, at peak loads of thousands of orders per minute per city. Sketch the flow: order service publishes an assignment request → dispatch service pulls candidate partners from a geo-index (grid or S2 cells, updated by a GPS ingestion pipeline) → a scoring function ranks candidates on distance, current load, predicted food-ready time, and acceptance likelihood → offer is pushed to the top partner with a short expiry, falling through to the next on decline. Key deep-dives to volunteer: batching (when to hold an order briefly to pair it with another along the route), the GPS pipeline (out-of-order pings, dedupe, last-write-wins per partner), and peak-load behaviour (shed precision, not availability — widen search radius, simplify scoring, lengthen tracking-update intervals before you ever fail an assignment). Close with metrics: assignment latency, acceptance rate, and p90 delivery time.

Q: Tell me about a production incident you owned (behavioral).

*Situation:* At my previous company, our order-processing queue backed up during a festival-sale evening; consumer lag crossed 20 minutes and orders appeared "stuck" to customers.

*Task:* As the on-call engineer, I owned mitigation and the post-incident fix.

*Action:* I confirmed the bottleneck was a downstream notification service doing synchronous calls inside the consumer, not queue capacity. I shipped a mitigation within the hour — moved notifications to a separate async path and replayed the backlog — then wrote the postmortem and drove two prevention items: a bulkhead so one slow dependency can't stall order processing, and an alert on consumer lag rather than queue depth.

*Result:* Backlog cleared in 40 minutes with zero lost orders, and the same failure mode never recurred in the following two festival peaks. I'd bring the same bias to Swiggy: mitigate first, then make the class of failure impossible.

For DSA rounds: clarify constraints, state the brute force and its complexity, improve it, then code cleanly while narrating — Swiggy interviewers, like most Indian product companies, typically weight working code plus complexity analysis over leetcode-trick recall. For system design: requirements (functional, scale, latency budget) → high-level flow → data model → the two or three deep-dives that matter for this system (for Swiggy, that's almost always the geo-index, the real-time pipeline, and peak-load degradation) → metrics and failure modes. Always state your consistency choices explicitly: order state needs strong consistency and idempotency; partner locations tolerate staleness. For behavioral questions, use STAR with one quantified result, and pick stories about incidents, ambiguity, and cross-team friction — they map to how delivery engineering actually works.

Candidates report Swiggy interviewers look for engineers who think about the p99, not the demo. In design rounds that means volunteering failure modes before being asked: what happens when GPS pings arrive late, when a payment dependency times out mid-order, when demand triples in an hour. They reward explicit degradation plans — knowing what you'd sacrifice (tracking-update frequency, search precision) to protect order placement. In DSA rounds they want clean, working code with honest complexity analysis, and they probe whether you can connect the structure to a real use case. In behavioral rounds, ownership is the signal: incidents you ran, systems you improved without being asked, and trade-offs you can defend with numbers. Referencing concepts from Swiggy Bytes posts, accurately, signals genuine interest — but only if you can discuss them, not just name-drop.

Weeks 1–2: DSA reps. Cover arrays, strings, hashmaps, heaps, trees, graphs, and intervals — 40 to 50 problems with an emphasis on heap and geometry-flavoured problems (k-nearest, merge intervals, sliding window) that mirror delivery-domain questions. Practise talking while coding. Weeks 3–4: system design. Do full one-hour designs of order tracking, dispatch, a geo-search service, and a notification pipeline; for each, write down the peak-load degradation plan explicitly. Read a handful of Swiggy Bytes posts on dispatch and data platforms and be ready to discuss one intelligently. Week 5: behavioral prep — six STAR stories (incident, ownership, conflict, failure, scaling something, mentoring) each with a number in the result — plus two mock interviews, one DSA and one design, with someone senior. Alongside prep, keep your pipeline warm: [knok](https://knok.work/) searches 150+ job boards overnight, surfaces only high-fit engineering roles, and drafts hiring-manager outreach, so practice doesn't come at the cost of applications.

Jumping into architecture diagrams before pinning down scale and latency budgets — dispatch at one order per second and one thousand per second are different systems. Designing for the happy path: no idempotency on order writes, no plan for out-of-order GPS data, no circuit breakers on payment calls. Treating peak load as an afterthought instead of a design input; at Swiggy, the IPL-night question is coming. In DSA rounds, reciting a memorised optimal solution without being able to modify it when the interviewer changes a constraint. Name-dropping Kafka, Redis, and S2 without explaining what problem each solves in your design. Behavioral answers with no ownership — "we" did everything and you can't say what you personally decided. And claiming certainty about Swiggy's internal stack — hedge with "based on what's public on Swiggy Bytes" or "I'd validate this with your team."