Swiggy backend interview questions and process

The candidate had designed Swiggy in eleven minutes. Users, restaurants, orders, a delivery service, a nice little Kafka topic in the middle. Then the interviewer said: "It's 8:04pm. Bengaluru just placed forty thousand orders in four minutes and one restaurant's kitchen is down. Walk me through what your system does." There was a pause you could park a scooter in.

That is the shape of Swiggy backend interview questions. The rounds look like any product company's — DSA, machine coding, design, hiring manager — but almost every design question resolves into the same problem: a demand spike you can predict to the minute, against physical supply you cannot control. I built Greenroom after freezing in an interview I had prepared hard for, so this guide covers what Swiggy asks and how to reason through it out loud.

The Swiggy backend engineer interview process in 2026

Swiggy's loop is close to the Indian product-company standard, with unusually heavy weight on practical building. What candidates report as the Swiggy backend interview process:

• Online assessment — timed DSA problems, medium difficulty, on a platform like HackerRank or HackerEarth.
• Machine coding round — 90 minutes to build a small working system in memory, then a code walkthrough. Prompts skew towards order or assignment problems.
• Problem solving / DSA round — live coding with an interviewer, plus complexity discussion.
• System design round — food delivery mechanics: order lifecycle, delivery partner assignment, ETA, surge.
• Hiring manager round — ownership, on-call, a decision you would make differently, and why Swiggy.

The thread through all of it: latency and correctness under a predictable spike. Swiggy's traffic is not random — it has two peaks a day, every day. Interviewers want to hear you design for a load curve you know in advance. Our Swiggy interview questions guide covers the company-wide loop; this one is backend-specific.

The machine coding round: build the order flow, make it run

The Swiggy machine coding round gives you a written problem statement and roughly 90 minutes to produce working, in-memory code — no database, no framework, no UI. Typical prompts: an order management system, a delivery-partner assignment service, a restaurant menu with availability, a coupon engine, a rate limiter.

The scoring order that matters:

• It compiles and it runs. Get the happy path working inside the first half hour, then refine. Unfinished elegance loses to finished adequacy every time.
• Every stated requirement is covered. Re-read the brief at minute sixty. Missed requirements, not bad code, cause most rejections.
• The domain model is honest. An order has a status enum and explicit transitions, not three booleans.
• Layers are separated. Entities, an in-memory store, a service layer, a driver or tests. Four packages, not twelve.
• One extension point, named. The brief usually hints at it — a new assignment strategy, a new coupon type. Make that pluggable and leave the rest concrete.
• Concurrency where it matters. Two orders claiming the same delivery partner is the follow-up you should pre-empt.

The order state machine is the piece interviewers probe hardest, so make it explicit rather than scattering if checks through your service:

public enum OrderStatus {
    PLACED, CONFIRMED, PREPARING, READY, PICKED_UP, DELIVERED, CANCELLED;

    private static final Map<OrderStatus, Set<OrderStatus>> NEXT = Map.of(
        PLACED,    EnumSet.of(CONFIRMED, CANCELLED),
        CONFIRMED, EnumSet.of(PREPARING, CANCELLED),
        PREPARING, EnumSet.of(READY, CANCELLED),
        READY,     EnumSet.of(PICKED_UP),        // past this point, no cancel
        PICKED_UP, EnumSet.of(DELIVERED),
        DELIVERED, EnumSet.noneOf(OrderStatus.class),
        CANCELLED, EnumSet.noneOf(OrderStatus.class));

    public boolean canMoveTo(OrderStatus next) {
        return NEXT.get(this).contains(next);
    }
}

Then say the thing the table implies: cancellation stops being free once the kitchen has cooked the food, so the state machine is a business rule, not a formality. That single sentence usually earns more credit than the code. Our machine coding round guide covers the full time budget, and the design patterns interview questions guide covers which patterns are worth reaching for under a clock.

Delivery partner assignment: the question behind the question

Delivery partner assignment is Swiggy's signature design problem, and it is deceptively deep. The naive answer — "assign the nearest available partner" — invites four follow-ups, so answer them before they arrive.

• Nearest by what? Straight-line distance is wrong in a city with one-ways and flyovers. Say you would use road-network ETA, with geodesic distance only as a cheap pre-filter.
• Nearest to what, when? Not the partner's current position, but their projected position when the food is actually ready. Assigning too early wastes the partner; too late adds minutes to every order.
• Batching. Two orders from the same restaurant heading the same direction should ride together. This is where a greedy nearest-first assignment quietly falls apart, and mentioning it marks you as someone who has thought about the economics.
• Fairness and supply. Partners have earnings targets and will go offline if starved. An assignment system that optimises purely for customer ETA loses supply, which raises ETA. Name that feedback loop.
• Geospatial indexing. Grid cells, geohash or H3 to narrow candidates before scoring them. Do not scan every partner in the city.
• Failure. The partner declines, or never moves. You need a timeout and reassignment, and the order must not be assigned twice — an idempotency or claim mechanism on the assignment row.

The Swiggy backend engineer prep page has a round-by-round checklist, and the Redis interview questions guide covers the fast lookup layer this design leans on.

System design for the 8pm dinner rush

Expect a prompt like "design Swiggy," "design the order service," "design live order tracking," or "design surge pricing." Structure your answer this way:

• Constraints first. Orders per second at peak versus average, acceptable latency for order placement versus tracking updates, and which parts must be strongly consistent. Order creation must be; the tracking dot on the map must not.
• The predictable spike. Say it explicitly: traffic is bimodal around lunch and dinner, so you can pre-scale on a schedule rather than reacting. Autoscaling that reacts to load arrives late in a four-minute ramp.
• Write path versus read path. Order placement is a durable write. Live tracking is a high-frequency, low-value stream — push over a websocket or long poll, keep the last position in a cache, and never write every GPS ping to your primary database.
• Async everything non-blocking. Notifications, invoices, restaurant printers, analytics — all events on a queue. Only payment authorisation and order creation block the customer.
• Degradation, not failure. When the recommendation service is down, the app should still take orders with a dumb default list. Naming a graceful degradation path is a senior signal.
• Hot partitions. One viral restaurant on a Friday night is a hot key. Say how you would detect and shard around it.

Our system design interview guide for India, Kafka interview questions guide and microservices interview questions guide cover the pieces this round leans on.

DSA, databases and the fundamentals rounds

The DSA bar sits at LeetCode medium: arrays, hashing, sliding window, heaps, graphs and shortest-path variants — the last of these unsurprisingly common given the domain. Binary search on the answer shows up in ETA and capacity framings.

Database questions get more attention here than at many companies, because order data is transactional and tracking data is not. Be ready for indexing, isolation levels and the anomalies each one still permits, when you would denormalise, and why you might put orders in a relational store and location pings somewhere else entirely. Our DBMS interview questions guide and SQL interview questions guide cover this ground, and the DSA coding interview preparation guide covers the algorithm list.

Behavioral rounds: on-call, ownership, and why Swiggy

The hiring manager round is about operating a live system. The reliable questions: an incident you handled, a time you were on call and something broke at an inconvenient hour, a tradeoff you made under deadline pressure, and why Swiggy specifically.

First person, two minutes, real numbers. "The service was slow" is invisible. "Order confirmation p99 hit six seconds during peak, I traced it to a synchronous call to the notification service, moved it behind a queue, and we went back to 400 milliseconds" is a hire signal. For "why Swiggy," the strong answers are about real-time logistics being a genuinely hard problem, not about liking food. Our tell me about a time you failed guide has the structure.

LeetCode, GeeksforGeeks, ChatGPT — where each fits

An honest map of the prep stack for this loop:

• LeetCode — necessary for the assessment and DSA round, at medium difficulty. Covers roughly one round in five.
• GeeksforGeeks and interview-experience posts — good for calibrating machine coding prompts and round format. Anecdotal, and reported difficulty tends to be inflated.
• Designing Data-Intensive Applications — the best single source for the consistency and streaming questions the design round turns into.
• Timed self-builds — pick an order or assignment problem, set 90 minutes, and finish it. Running out of time once in practice is worth more than reading five design articles.
• ChatGPT — useful for generating machine coding prompts and critiquing a design you have written down. It will not ask "so what happens at 8:04pm?" at the moment your diagram has no answer.
• Greenroom — the spoken layer. Ari, the AI interviewer, runs the round out loud, pushes the follow-up when a design hand-waves, and scores structure and clarity. Fair tradeoff: Ari will not review your Java line by line, so pair it with timed builds.

How to prepare for the Swiggy backend interview

• Week 1: DSA daily at medium difficulty, stating complexity aloud. Add graph and shortest-path problems deliberately.
• Week 2: three timed machine coding builds — order management, delivery assignment, coupon engine. Run them, write a driver, then explain each in five minutes aloud.
• Week 3: design out loud — Swiggy end to end, live tracking, surge pricing. Constraints first, then diagram, then failure modes and degradation.
• Final week: five behavioral stories in first person with numbers, two full spoken mocks with design pushback, and the role-specific prep page the night before — not new material.

Interviewing across comparable companies? The Zomato backend engineer guide covers the nearest equivalent bar, the Flipkart backend engineer guide covers the machine coding format in more depth, the Uber backend engineer guide goes deeper on dispatch and geospatial questions, and the Swiggy data engineer guide covers the analytics side.

Interviewing for a frontend role instead? Our Swiggy frontend engineer interview questions guide covers the machine coding round, live order tracking UI and optimistic cart updates.

Frequently asked questions

What is the Swiggy backend engineer interview process?

Candidates report five stages: an online assessment with timed medium-difficulty DSA problems, a machine coding round of about 90 minutes building a working in-memory system, a live problem-solving round with complexity discussion, a system design round on food-delivery mechanics such as order lifecycle and delivery partner assignment, and a hiring-manager round on ownership and on-call experience.

What system design questions does Swiggy ask?

The recurring prompts are design Swiggy end to end, design the order service, design live order tracking, design delivery partner assignment, and design surge pricing. Interviewers push on the predictable lunch and dinner traffic spikes, which operations need strong consistency, how live location updates avoid hitting the primary database, and how the system degrades when a dependency fails rather than failing outright.

How does Swiggy's delivery partner assignment question work?

You are asked how to match an order to a delivery partner. The expected depth goes past nearest-available: road-network ETA rather than straight-line distance, assigning based on where the partner will be when the food is ready, batching orders travelling the same direction, geospatial indexing such as grid cells or H3 to narrow candidates, fairness so partners do not go offline, and timeouts with safe reassignment when a partner declines.

What is the Swiggy machine coding round?

It is a roughly 90-minute timed build where you are given a plain-English problem — commonly an order management system, delivery assignment service, menu with availability or a coupon engine — and must produce running in-memory code with no database or framework, followed by a walkthrough. Working code with average design outscores unfinished elegant design.

Is the Swiggy backend interview hard?

It is a solid product-company bar rather than a FAANG-style algorithm gauntlet. DSA sits at medium difficulty, so the filter is elsewhere: building correct software under a 90-minute clock and reasoning fluently about real-time logistics, spiky traffic and graceful degradation while an interviewer probes each answer.

How many rounds is the Swiggy backend interview and how long does it take?

Most reported loops run four to six rounds — online assessment, machine coding, problem solving, system design and a hiring-manager round — over roughly two to four weeks. Gaps are usually scheduling rather than deliberation, so use them to practise designing under spoken pushback.