Swiggy frontend interview questions and process

The cart worked perfectly. Add item, quantity up, quantity down, total recalculates — smooth as anything. Then the interviewer asked her to throttle the network to 3G and tap the plus button four times fast. The counter jumped to 4, then flickered back to 2, then settled on 3. "Which one is right?" he asked. She said, "the server's." He said, "the user is looking at 3. What do you show them, and when?"

That question is the whole of Swiggy frontend interview questions compressed into one exchange. Swiggy's product is real-time — an order moves through states while you watch it, a delivery partner moves across a map, a cart syncs across devices — so the frontend rounds are about optimistic updates, reconciliation and what the user sees while the truth is still in flight. 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 frontend engineer interview process in 2026

Swiggy's frontend loop follows the Indian product-company standard with an unusually practical bent. What candidates report as the Swiggy frontend interview process:

• Online assessment — timed DSA problems at medium difficulty, on HackerRank or a similar platform.
• Machine coding round — around 90 minutes to build a working UI feature, then a walkthrough. Prompts skew towards carts, lists and live-updating widgets.
• JavaScript and React round — fundamentals plus framework depth: closures, the event loop, hooks semantics, re-render behaviour.
• Frontend system design round — the order tracking screen, the restaurant listing page, the cart, or a shared component library.
• Hiring manager round — ownership, a production incident, working with design and product, and why Swiggy.

The unifying constraint: the interface is never done rendering. Something is always arriving — an order status push, a new ETA, a partner location. Design your answers around that. Our Swiggy interview questions guide covers the company-wide loop, and the Swiggy backend engineer guide covers the other side of the same problems.

The machine coding round: build it, then break it yourself

The Swiggy machine coding round gives you a brief and roughly 90 minutes of working time. Typical prompts: a food cart with quantity rules and offers, a restaurant list with filters and sorting, an order status tracker that updates live, a searchable menu, or a star-rating and review widget.

The scoring order that matters:

• It runs and covers the brief. Re-read the requirements at minute sixty; missed requirements cause more rejections than ugly code.
• All four async states exist — loading, empty, error, success. Empty states are the most commonly forgotten and the most commonly asked about.
• Derived state is derived, not stored. The cart total is computed from items; storing it separately creates two sources of truth and the interviewer will find the bug.
• Updates are optimistic where it matters. A quantity tap should feel instant. Say how you reconcile when the server disagrees.
• Cleanup and cancellation. Abort in-flight fetches, clear intervals, close sockets on unmount.
• Sane component boundaries. Two or three well-named components with state lifted to where it is genuinely shared.

The optimistic-update pattern is the one worth having in your fingers, because it is both the machine coding answer and the design-round answer:

function useCartItem(id, serverQty) {
  const [qty, setQty] = useState(serverQty);
  const pending = useRef(0);

  async function change(delta) {
    const next = Math.max(0, qty + delta);
    setQty(next);                 // 1. optimistic: the UI moves immediately
    pending.current += 1;
    try {
      const res = await updateCart(id, next);
      // 2. only the last in-flight write may correct the UI
      if (--pending.current === 0) setQty(res.quantity);
    } catch (e) {
      pending.current -= 1;
      setQty(qty);                // 3. roll back and tell the user something
      toast('Could not update your cart');
    }
  }

  return { qty, change };
}

Then say the sentence that lands: "the UI is optimistic, the server is authoritative, and only the last response is allowed to correct the screen — otherwise four fast taps produce a flicker." Our machine coding round guide covers the time budget and the React interview questions guide covers the hooks semantics underneath.

Real-time UI: order tracking, sockets and the moving map

Live order tracking is Swiggy's signature frontend design problem. "Poll every five seconds" is where the conversation starts, not where it ends.

• Transport choice, with a reason. Polling is simple and wasteful; long polling is awkward; server-sent events are a clean one-way fit for status updates; websockets are right when you need two-way or high-frequency data. Order status is one-way and low-frequency — say that server-sent events are often the correct boring answer, and reserve websockets for the map.
• Reconnection is the real work. Networks drop constantly on mobile. Exponential backoff, resuming from the last known state, and a visible but non-alarming "reconnecting" affordance.
• Out-of-order and duplicate events. Apply updates by a sequence number or timestamp and ignore backwards transitions, because a delayed PREPARING must never overwrite a delivered order.
• Interpolate the marker, do not teleport it. Location pings arrive every few seconds; animating between them is what makes it feel live. This is a genuinely good answer and few candidates give it.
• Battery and data. Pause updates when the tab is hidden using the Page Visibility API. Mentioning this unprompted is a strong signal at a mobile-first company.
• Degrade gracefully. If the socket dies entirely, fall back to polling rather than showing a frozen screen.

The Swiggy frontend engineer prep page has a round-by-round checklist, and our system design interview guide for India covers the shared vocabulary.

JavaScript and React questions Swiggy asks

The fundamentals round is standard but thorough. On the JavaScript side: closures, this binding, the event loop and microtask ordering, event delegation, prototypal inheritance, and implementing debounce, throttle or Promise.all from scratch. Our JavaScript interview questions guide covers the set.

On the React side, expect depth rather than API recall:

• Why did this re-render? The most-asked React question anywhere, and the one that separates people who use React from people who understand it. Reference equality, state changes, context value identity.
• useEffect dependencies and cleanup — what runs when, why an object dependency loops forever, and what the cleanup function is actually for.
• useMemo and useCallback — and the honest answer that they are not free and are often applied where they do nothing. Interviewers like candidates who can say that.
• Keys in lists — why index keys break reordering, with a concrete example.
• State colocation versus global state. When context is enough and when a store earns its place. Our Redux interview questions guide covers that tradeoff.
• Controlled versus uncontrolled inputs, and why a controlled input can feel laggy on a slow device.

Frontend system design at Swiggy

Design prompts are scoped to the browser: design the order tracking screen, the restaurant listing page, the cart across devices, or a shared component library used by several teams. Structure your answer this way:

• Constraints first. Device profile, network conditions, update frequency, and which data must be fresh versus which can be stale. The ETA can be a few seconds old; the order status cannot be wrong.
• Data flow and state ownership. Server state versus client state is the key distinction — cache the first, own the second, and do not put server data in a global store just because it is convenient.
• Caching and revalidation. Stale-while-revalidate for the restaurant list, cache keys that include filters, and prefetch on hover or intent.
• Long lists. Virtualization for a thousand restaurants, plus image lazy loading and skeletons that match the final layout so nothing shifts.
• Offline and flaky networks. What survives a refresh, what is persisted locally, and whether the cart is recoverable.
• Instrumentation. How you would notice the tracking screen getting slower after a release.

Behavioral rounds: incidents, design friction and why Swiggy

The hiring manager round is about operating a live consumer product. Reliable questions: a bug that reached users and how you found it, a time you disagreed with a designer, a launch under deadline pressure, and why Swiggy.

First person, two minutes, numbers. "The page was slow" is invisible. "The restaurant list dropped to about 20 frames per second on mid-range Android because every scroll re-rendered all 400 cards, I added virtualization and memoized the card, and we held 60" is a hire signal. For "why Swiggy," tie it to real-time consumer interfaces being hard, not to liking food. Our tell me about a time you failed and behavioral interview questions guide cover the structure.

LeetCode, GreatFrontEnd, ChatGPT — where each fits

An honest map of the prep stack for this loop:

• LeetCode — the online assessment only, at medium difficulty. One round in five.
• GreatFrontEnd and JavaScript.info — the right depth for the fundamentals round and the implement-it questions.
• MDN — the source of truth for EventSource, AbortController, the Page Visibility API and the WebSocket API you will be asked to choose between.
• The React documentation's own guides on effects — genuinely the best explanation of the dependency and cleanup questions this round asks.
• Timed self-builds — build a cart with optimistic updates and a live-updating status tracker on a 90-minute clock. This is the highest-leverage hour you can spend.
• ChatGPT — useful for generating briefs and reviewing pasted code. It will not throttle your network to 3G and tap the button four times.
• Greenroom — the spoken layer. Ari, the AI interviewer, runs the round out loud, pushes the follow-up when you say "I'd just poll," and scores structure and clarity. Fair tradeoff: Ari will not review your JSX line by line, so pair it with timed builds.

How to prepare for the Swiggy frontend interview

• Week 1: DSA at medium difficulty for the assessment, plus the implement-it set — debounce, throttle, bind, Promise.all — written from memory.
• Week 2: three timed machine coding builds — a cart with optimistic updates, a filtered restaurant list, a live status tracker. All four async states in each, then explain each aloud in five minutes.
• Week 3: real-time and design — transports and their tradeoffs, reconnection, out-of-order events, virtualization. Design the tracking screen and the cart out loud, constraints first.
• 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 loops? The Zomato frontend engineer guide covers search and infinite feeds at the nearest equivalent bar, the Flipkart frontend engineer guide goes deeper on machine coding and performance budgets, the Uber frontend engineer guide covers map-heavy interfaces, and the Atlassian frontend engineer guide covers accessibility and design systems.

Frequently asked questions

What is the Swiggy frontend 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 UI feature, a JavaScript and React round covering fundamentals and re-render behaviour, a frontend system design round on screens such as order tracking or the restaurant list, and a hiring-manager round on ownership and working with design.

What is asked in the Swiggy machine coding round for frontend?

You get roughly 90 minutes to build a working UI feature from a brief. Common prompts are a food cart with quantity rules and offers, a restaurant list with filters and sorting, a live-updating order status tracker, a searchable menu, and a rating and review widget. Reviewers score whether it runs, whether loading, empty, error and success states all exist, whether the cart total is derived rather than stored, and whether updates are optimistic with sane reconciliation.

How do you design live order tracking in a frontend interview?

Go past polling. Choose a transport with a reason — server-sent events suit one-way low-frequency status updates, websockets suit the high-frequency map data — then cover reconnection with exponential backoff and resume from last known state, applying events by sequence number so a delayed update cannot overwrite a newer one, interpolating the map marker between location pings instead of teleporting it, pausing updates when the tab is hidden, and falling back to polling if the socket dies.

What React questions does Swiggy ask?

Expect depth rather than API recall: why a component re-rendered and how reference equality causes it, useEffect dependencies and what the cleanup function is for, why an object dependency loops forever, whether useMemo and useCallback are actually earning their cost, why index keys break list reordering, when context is enough versus when a store is justified, and why a controlled input can feel laggy on a slow device.

How do you handle optimistic updates in a Swiggy interview question?

Update the UI immediately so the interaction feels instant, treat the server as authoritative, and allow only the last in-flight response to correct the screen — otherwise four fast taps produce a visible flicker. On failure, roll back to the previous value and surface a non-blocking message. Saying explicitly which source of truth wins, and when, is what the question is testing.

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

Most reported loops run four to six rounds — online assessment, machine coding, a JavaScript and React round, frontend 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 building and explaining under spoken pushback.