Interview experience
Swiggy Interview Questions and Answers (2026)
Overview
Section titled “Overview”Swiggy’s loop is a fairly standard 4-stage product-company process, but its second technical round is distinctly domain-flavoured - candidates reason about order assignment and ETA systems rather than generic system design.
Swiggy interview process at a glance
Section titled “Swiggy interview process at a glance”| Round | Duration | What they test |
|---|---|---|
| Online Assessment | 90 min | 2-3 coding problems |
| Technical Round 1 | 45-60 min | DSA + project discussion |
| Technical Round 2 | 45-60 min | System design (orders / logistics) |
| HR | 20-30 min | Behavioural + culture fit |
Online Assessment
Section titled “Online Assessment”A timed, 90-minute coding test (HackerRank or similar) with 2-3 DSA problems. Clean, fully passing solutions score better than partially clever but incomplete ones - shortlist decisions come within a few days.
Common questions
- Top-K frequent elements - typically expects a heap or bucket-sort approach
- Shortest path in a grid - typically expects BFS
- Merge overlapping delivery slots / intervals - typically expects an interval-merge approach
Technical Round 1
Section titled “Technical Round 1”A 45-60 minute round mixing 1-2 DSA problems with a detailed walkthrough of your resume project - stack choices, your hardest bug, and what you’d rebuild differently. Some drives fold in a light domain question here too.
Common questions
- Solve a DSA problem live, then discuss complexity and edge cases explicitly
- Walk through your project’s architecture and your specific contribution
- What was the hardest bug you debugged, and how did you find it?
- Explain order assignment or ETA at a conceptual level - inputs, outputs, what breaks at scale
Technical Round 2
Section titled “Technical Round 2”A system-design round grounded in Swiggy’s own domain rather than generic distributed-systems trivia - order assignment, ETA reliability, or menu search are the recurring themes.
Common questions
- How would you design an order-assignment system matching delivery partners to orders?
- How would you keep delivery ETAs reliable during a demand surge, like a rainy evening or a big cricket match?
- Design a menu-search feature - data model, APIs, and failure modes
- What would you monitor to catch this system breaking in production?
Full round-by-round narratives are on the Swiggy interview experience page.
HR / managerial round
Section titled “HR / managerial round”A closing 20-30 minute conversation on motivation, comfort with ambiguity, and logistics like on-call or weekend availability.
Common questions
- Tell me about yourself and why Swiggy?
- How do you approach working with unclear or changing requirements?
- Tell me about a time you worked across teams (ops, delivery partners, restaurant partners) to fix a customer-facing problem
- Are you comfortable with on-call or weekend rotations?
Sample answer frameworks for each of these are on the Swiggy HR interview questions page.
Common technical interview questions and answers
Section titled “Common technical interview questions and answers”Q: Find the k most frequent elements in an array.
Build a frequency map in one pass in O(n), then either keep a min-heap of size k, popping when it grows past k, for O(n log k) time, or use bucket sort with n plus one buckets indexed by frequency and walk down from the highest bucket for O(n) time. Space is O(n) for the map either way. Say which you would pick and why: heap when k is small relative to n, bucket sort when k approaches n. Ask about tie-breaking before you code, because the statement rarely defines it.
Q: Find the shortest path from a start cell to a target cell in a grid with obstacles.
Because every move costs the same, plain BFS gives the shortest path - Dijkstra is unnecessary overhead here. Push the start into a queue with distance zero, mark it visited, and expand the four neighbours, skipping obstacles and out-of-bounds cells, marking each visited at enqueue time rather than dequeue time to avoid duplicates. The first time you dequeue the target, its distance is optimal. Time and space are both O(rows times columns). If some cells cost more to cross, switch to Dijkstra with a priority queue, or 0-1 BFS with a deque when the only two costs are zero and one.
Q: Merge a list of overlapping delivery time slots.
Sort the slots by start time, then sweep once holding a current slot: if the next slot starts at or before the current end, extend the current end to the maximum of the two ends, otherwise emit the current slot and start a new one. That is O(n log n) dominated by the sort, with O(n) output. Decide up front whether a slot ending at 6:00 and one starting at 6:00 count as overlapping, since both answers are defensible and the interviewer wants the assumption stated. For a streaming variant where slots arrive continuously, keep them in a balanced interval tree instead of re-sorting.
Q: Write a SQL query for the top three restaurants by order count in the last seven days.
SELECT r.id, r.name, COUNT(*) AS orders FROM orders o JOIN restaurants r ON r.id = o.restaurant_id WHERE o.created_at is at or after CURRENT_DATE minus 7 days AND o.status = ‘DELIVERED’ GROUP BY r.id, r.name ORDER BY orders DESC LIMIT 3. Two details matter: filter on order status in the WHERE clause so cancelled orders do not inflate counts, and include every non-aggregated selected column in the GROUP BY. If you need the top three per city rather than overall, wrap it in a window function using ROW_NUMBER() OVER (PARTITION BY city ORDER BY orders DESC) and filter to rank at most three, because LIMIT cannot express per-group top-N.
Q: How would you design an order-assignment system that matches delivery partners to orders?
Maintain a geospatial index of available partners - a hexagonal grid such as H3, or a geohash prefix - updated from location pings every few seconds, so finding candidates near a restaurant is a cell lookup rather than a scan. Score each candidate on distance to pickup, current batch load, direction of travel, and historical acceptance rate, then assign in small batches rather than greedily one order at a time, because batching lets you solve a bipartite matching that reduces total delivery time. Assignment must be atomic - a compare-and-swap on the partner’s state prevents double-assigning one rider to two orders. Handle rejection and timeout by re-queueing the order with a widening search radius, and cap retries so an unassignable order escalates to ops instead of looping forever.
Q: How do you keep delivery ETAs reliable during a demand surge?
Split the ETA into components you can measure separately: partner-to-restaurant travel, restaurant food-preparation time, and restaurant-to-customer travel. Surges break the model mainly through preparation time and partner availability, not road speed, so feed live signals - current queue depth at that restaurant, supply-to-demand ratio in the cell, and rain or event flags - into the model as features rather than relying on a static historical average. Predict a distribution and quote a conservative percentile such as p80 instead of the mean, because a late order costs far more in trust than an early one. Recompute the ETA continuously during the trip and monitor the error distribution per city per hour, since a model that is fine on average can be badly wrong in one cell.
Q: What is the difference between an abstract class and an interface, and when do you use each?
An abstract class can hold state, constructors, and concrete method implementations, and a class can extend only one of them; an interface declares a contract, holds no instance state, and a class can implement many. Use an abstract class when several subclasses genuinely share implementation and identity - a base Payment holding an amount and a shared audit-logging method - and an interface when unrelated classes need to be interchangeable at a call site, such as Serializable or Comparable. Modern Java allows default methods on interfaces, which narrows the gap but still forbids instance fields. The practical guideline is that interfaces express capability while abstract classes express a shared partial implementation.
Q: What would you monitor to catch this system breaking in production?
Track the business funnel first, because it fails visibly before infrastructure does: orders placed, orders assigned within N seconds, assignment rejection rate, and unassigned-order backlog per city. Add latency percentiles rather than averages - p50, p95, and p99 on the assignment API - since an average hides the tail that customers actually feel. Instrument the dependency layer with error rate, saturation, and cache hit ratio, and alert on symptoms such as rising unassigned backlog rather than on causes such as CPU, so a novel failure still pages someone. Every alert needs a defined owner and a runbook, otherwise the dashboard becomes noise that nobody trusts during an incident.
Frequently asked questions about Swiggy interviews
Section titled “Frequently asked questions about Swiggy interviews”What is the Swiggy interview process for freshers?
Swiggy placement process (from student reports): 1. Online Coding Assessment (90-120 min): 2-3 DSA problems on a HackerRank-style platform. 2. Technical Interviews (2 rounds, 45-60 min each): the first mixes DSA with a project discussion, the second is system design centered on Swiggy’s logistics domain (order assignment, ETA). 3. HR / managerial round (20-30 min): behavioural fit and offer discussion. Total duration: 2-4 weeks.
What questions are asked in Swiggy interviews?
Swiggy interviews commonly cover DSA (Top-K frequent elements, shortest path in a grid via BFS, interval-merge problems), core CS fundamentals (OOPs, SQL), a detailed project discussion, and domain-flavoured system design around order assignment, ETA prediction, and menu search. Behavioural rounds check ownership, teamwork, and comfort with on-call/weekend rotations.
How many rounds are there in the Swiggy interview?
Swiggy typically runs 4 stages: Online Assessment (90 min), Technical Round 1 (45-60 min, DSA + project), Technical Round 2 (45-60 min, system design), and HR (20-30 min). Some drives merge HR with the managerial round or skip a stage - check that cycle’s placement email.
What is Swiggy’s system design round about?
Swiggy’s second technical round leans into its logistics domain rather than generic system design: candidates are asked to reason about order assignment (matching delivery partners to orders), ETA calculation, or menu search - explaining bottlenecks, failure modes, and simple APIs in plain language rather than reciting buzzwords like ‘microservices’ without substance.
How should I prepare for Swiggy interviews?
Practise timed DSA under time pressure (Swiggy’s screening round rewards clean, passing solutions over partial cleverness), revise OOPs and SQL since they open a lot of Swiggy panels, prepare one crisp project narrative covering your hardest bug, and read up on how food-delivery order assignment and ETA systems work at a conceptual level. Use STAR for behavioural answers.