Company questionsGroundworkSwiggy

India · interview process

Swiggy

Swiggy loops reported for SDE-2/3 combine DSA, a low-level design round, a high-level design round and a hiring manager conversation. The SDE-2 report and guides mention an online test; the SDE-3 report starts with a recruiter call and a telephonic screen. Guides add a machine coding round of up to 2 hours and a bar raiser, but the candidate reports read here do not confirm machine coding.

  • 10 rounds
  • 2-6 weeks and 3-5 weeks in two guides; one SDE-3 reported about a month, one SDE-2 about one week
  • 2 design answers
  • 4 coding answers
  • 1 well-reported rounds
  1. OA
  2. Screen
  3. CS basics
  4. DSA
  5. Machine coding
  6. LLD
  7. System design
  8. Bar raiser
  9. Manager
  10. HR
  11. People rounds

The process, round by round

Reported by candidates and, where we found one, the company itself. Each round shows how well it is reported. Processes change by team, level and year.

  1. Online assessment

    Online assessment75-90 min (one guide)

    One report

    Timed coding test with about three DSA problems on a hiring platform. One SDE-2 candidate could only use Java, Python or Go; guides mention delivery-themed framing and sometimes a SQL question.

    • medium-hard DSA
    • language-restricted coding
    • dynamic programming
    • binary search

    Varies: The SDE-3 report starts with a recruiter call and a telephonic screen and mentions no test. A guide says campus reports describe a 90-minute test with one SQL and three coding questions.

    What can be asked in a online assessment round

    A timed test on a coding platform, taken alone. Usually two or three coding problems, sometimes with multiple-choice questions on CS basics, aptitude or SQL.

    • Array and string problems that need a hash map, two pointers or a sliding window

      Read the constraints first, because they point to the technique. If n is 100,000, an O(n^2) scan will time out, so look for a hash map, two pointers on a sorted array, or a window that moves forward only. Sketch the brute force, find the repeated work, then remove it. For two-sum style pairs you might say: I store each value's index as I scan, so the complement lookup is O(1) and the whole pass is O(n).

      DSA course →
    • Greedy and sorting problems with a catch in the constraints

      Greedy problems hide behind a sort. Ask what ordering makes the locally best choice safe, then try to argue why swapping two adjacent choices never helps. Interval scheduling is the classic case: sort by end time and take every interval that starts after the last chosen one. Check the catch in the constraints, such as overflow, ties or equal values, and test a tiny case by hand before submitting.

      DSA course →
    • A medium dynamic programming or graph-on-a-grid problem

      Decide whether the problem is a graph walk or a recurrence. On a grid, a shortest path with equal step cost is breadth-first search from the start, with a visited set so each cell is processed once, giving O(rows x cols). For dynamic programming, define the state in one sentence, write the transition, set the base cases, then see if only the previous row is needed to save space.

      DSA course →
    • SQL queries with joins and group by

      Start from the table that holds the thing being counted, join the others on their keys, filter rows with WHERE, group, then filter groups with HAVING. Remember that WHERE runs before grouping and HAVING after. Use LEFT JOIN when rows with no match must still appear, and COUNT of a column rather than star when nulls matter. Example: customers with more than three orders is GROUP BY customer_id HAVING COUNT(*) > 3.

      Databases →
    • Multiple-choice questions on OOP, operating systems, databases and networks

      These reward quick, accurate recall rather than long reasoning, so revise the short list of definitions that recur. Know the difference between a process and a thread, the four ACID properties, what an index trades for faster reads, TCP against UDP, and the four pillars of OOP. Eliminate two wrong options first, then choose. Do not spend more than a minute on any single question, and flag it to return to if time remains.

      Mock interviews →

    Prepare with: Book · Online assessmentDSA course

    3 sources for this round
  2. Telephonic screen

    Recruiter or phone screen60 min

    One report

    In the SDE-3 report, a short introduction followed by a deep dive into the candidate's most challenging project: challenges, technical choices and lessons learned. A guide describes a 15-30 minute recruiter call at this stage instead.

    • project depth
    • design reasoning
    • learning from challenges

    Varies: Reported for an SDE-3 (L8) candidate in a post dated July 2025; the SDE-2 report read does not describe it.

    What can be asked in a recruiter or phone screen round

    A short call that decides whether you move on. Part resume and motivation, sometimes one easy coding or fundamentals question in a shared editor.

    • Walk me through your resume and your best project

      Give a two minute spine, not a life story: who you are now, the one or two projects that matter most, and why this role is the next step. Pick the best project and state the problem, your part, the technology and one measurable result. Keep every claim something you can defend if the next question digs in. You could open with: I am a backend engineer, and the project I am proudest of is the one where I cut checkout latency.

      Screening call chapter →
    • Why this company and why now

      The listener wants to know whether your reason is specific and sincere, not flattery. Name one or two real things about the product, the engineering problems or the team that you have looked at, then connect them to something you have done or want to learn. Why now should be about your growth, not escaping your current job. An opening could be: I have used the product, and the scaling problem it describes is the kind I want to work on.

      Screening call chapter →
    • Notice period, location and compensation expectations

      Give the facts that are true and keep the negotiation for later. State your notice period exactly as your contract says, and mention whether it can be shortened or bought out only if that is real. For compensation, say you would like to understand the role and level first, or give a researched range rather than a single anchor. Never invent a current figure. If you are asked directly, answer honestly and calmly.

      HR and the number chapter →
    • One easy or medium coding question, or a language fundamentals question

      Treat it as a short version of the full coding round. Repeat the problem back, ask about input size and edge cases, state a plan before typing, and talk while you code. For a language question, such as what a closure is or how a hash map handles collisions, give a one line definition and a tiny example. A good line is: first I will do the simple approach so we have something correct, then improve it.

      Tech phone screen chapter →

    Prepare with: Book · Screening callBook · Tech phone screen

    2 sources for this round
  3. Coding and CS fundamentals

    CS fundamentals60 min

    One report

    Questions on deployment practice, an API latency increase after a release, ordering across Kafka partitions and functional testing, followed by two coding problems (longest run of consecutive integers and a linked-list pointer problem).

    • backend fundamentals
    • production debugging
    • Kafka basics
    • data structures

    Varies: One SDE-3 report only.

    What can be asked in a cs fundamentals round

    Questions on the subjects every engineer is expected to know: operating systems, databases, networks and object-oriented programming. Common for campus and early-career hiring.

    • Process vs thread, scheduling, deadlocks, virtual memory

      A process has its own address space, while threads in one process share memory, so threads are cheaper to create and switch but need synchronisation. A deadlock needs four conditions at once: mutual exclusion, hold and wait, no pre-emption and circular wait. Break any one, for example by taking locks in a fixed order. Virtual memory maps pages to frames, and a page fault loads a missing page from disk.

      Operating systems →
    • ACID, isolation levels, indexes, normalization, joins

      ACID means atomicity, consistency, isolation and durability. Isolation levels trade anomalies for speed: read committed prevents dirty reads, repeatable read also stops a row changing under you, and serializable behaves as if transactions ran one at a time. An index, usually a B-tree, speeds lookups at the cost of slower writes and more space. Normalisation removes duplicated facts, and joins put the pieces back.

      DBMS →
    • TCP vs UDP, the TCP handshake, HTTP and HTTPS, DNS, load balancing

      TCP is connection-oriented, ordered and reliable, using a three-way handshake of SYN, SYN-ACK and ACK. UDP sends datagrams without those guarantees, so it suits low latency uses such as voice or DNS queries. HTTPS is HTTP over TLS, which adds encryption and server identity. DNS resolves a name to an address through a chain of resolvers. A load balancer spreads requests across servers using a policy such as round robin or least connections.

      Networks →
    • OOP: polymorphism, abstraction, interfaces, SOLID

      Answer with a definition and a small example each time. Polymorphism means one interface with many behaviours, such as a Shape with an area method that each subclass implements. Abstraction hides detail behind a contract. An interface states what, a class states how. Mention that you prefer composition over inheritance when behaviour varies, and tie SOLID to one real choice from your own code.

    • How would you debug a slow query or a hung process

      Work from symptom to cause, measuring before changing. For a slow query, run the execution plan, look for a full scan, a missing or unused index, or a bad join order, and check row counts. For a hung process, check whether it uses CPU, is waiting on I/O or a lock, and read a thread dump or stack trace. State the order: reproduce, observe, form one hypothesis, change one thing.

      Databases →

    Prepare with: Book · Databases & RedisOperating systemsDBMSNetworks

    1 source for this round
  4. Problem solving and data structures

    Data structures and algorithms60 min

    One report

    A live round with an interviewer. In the SDE-3 report the task was implementing a JSON parser in Java with error handling, finishing with a chat on on-call culture and production incidents. A guide describes a standard 60-minute live DSA round that discusses running time and memory cost.

    • parsing and implementation
    • error handling
    • complexity reasoning
    • production mindset

    Varies: The SDE-2 report read shows DSA only inside the online test; the live round above is from the SDE-3 report.

    What can be asked in a data structures and algorithms round

    A live coding round of 45 to 60 minutes with one or two problems. You are judged on how you clarify, reason, code, test and state the complexity, not on the answer alone.

    • Arrays, strings and hashing: pairs, windows, frequency counts, prefix sums

      Name the pattern from the shape of the question. Pairs with a target use a hash map of seen values. A contiguous range with a condition uses a sliding window that grows on the right and shrinks on the left, so each element enters and leaves once, giving O(n). Range sums over many queries use a prefix sum array so each query is O(1) after O(n) setup. Count characters with a fixed-size array or map.

      DSA course →
    • Linked lists, stacks and queues, including design-a-structure problems such as an LRU cache

      For an LRU cache, combine a hash map from key to node with a doubly linked list ordered by recency. Get moves the node to the front, put inserts at the front, and when over capacity you remove the tail node and its map entry. Both operations are O(1), and you say why: the map finds the node, the list reorders it without a scan. For stacks, mention a monotonic stack for next greater element.

      DSA course →
    • Trees and BSTs, graphs (BFS, DFS, topological sort, shortest paths) and grids

      Decide the traversal from what is asked. Level by level or shortest path in an unweighted graph is BFS with a queue. Exploring all paths, components or cycles is DFS. A dependency order is topological sort: Kahn's algorithm repeatedly removes nodes with in-degree zero, and leftover nodes mean a cycle. Weighted shortest path with non-negative edges is Dijkstra with a heap, O((V + E) log V). On a BST, an in-order walk is sorted.

      DSA course →
    • Heaps and top-K, intervals, binary search on the answer

      For the K largest items keep a min-heap of size K: push each element and pop the smallest when the heap exceeds K, so the cost is O(n log K) and memory is O(K). For intervals, sort by start, then merge by comparing the next start with the current end. For binary search on the answer, define a yes or no check that is monotonic, such as can ship within D days, and search the capacity range.

      DSA course →
    • Dynamic programming from one dimension up to knapsack and string DP

      Define the state in a sentence, write the recurrence, fix the base cases, and decide the order of filling. Start with the recursive version with memoisation, then convert to a table. For 0/1 knapsack, dp[w] is the best value at capacity w, and in the one dimensional form you loop capacity downward so each item is used once. For string problems such as edit distance, the state is a pair of prefix lengths.

      DSA course →
    • Follow-ups: optimise space, handle streaming input, make it thread-safe

      Treat follow-ups as a chance to show depth, and answer in the same calm order each time. To save space, ask which previous rows or values the recurrence actually reads and keep only those. For streaming input, say what summary you can keep, such as a heap of size K or a running count. For thread safety, name the shared state, guard it with a lock, and keep the critical section short.

    Prepare with: Book · DSA roundDSA course

    2 sources for this round
  5. Machine coding

    Machine coding90-120 min

    Prep guides

    Guides call this Swiggy's signature round: build a runnable system from written requirements (parking lot or expense-sharing style) and be judged on structure and ease of adding features. None of the candidate reports I could read include it.

    • runnable modular code
    • class organisation
    • extensibility

    Varies: Guides say experienced hires only; campus drives skip it. The SDE-3 loop I read had a separate 60-minute LLD round instead.

    What can be asked in a machine coding round

    You build a small working system in your own editor in 60 to 120 minutes, then walk through it. Clean entities, extensibility, a runnable demo and tests matter more than clever algorithms.

    • Parking lot, library or inventory system with several entity types

      Spend the first ten minutes on requirements and entities, not code. For a parking lot you might list Vehicle, Slot, Ticket and Lot, with slot types as an enum and the allocation rule hidden behind an interface so a nearest-slot strategy can be swapped. Keep the code runnable early, write a small demo in main, and add a few tests. Say what you would add with more time, such as pricing rules.

      Whiteboard →
    • Splitwise-style expense sharing, a wallet or a ledger

      The core of expense sharing is a balance ledger: for each pair or each user, store the net amount owed. An expense has a payer, an amount and a split type such as equal, exact or percent, handled by a split strategy per type. Validate that exact splits sum to the total and handle rounding explicitly. To simplify debts, compute each person's net balance and match the largest creditor with the largest debtor.

    • Snake and ladder, tic-tac-toe, chess or another game engine

      Model the board, players, dice or moves, and a game controller that owns the turn loop, with rules kept out of the board class. For tic-tac-toe, keep counters per row, column and both diagonals, so a win check is O(1) per move instead of scanning the grid. For snake and ladder, store jumps in a map from square to destination. Make board size and number of players configurable rather than hard coded.

    • An in-memory cache, key-value store, rate limiter or job scheduler

      Start with the public interface and the invariants. For a rate limiter, a token bucket stores tokens and a last refill time per key, refills lazily on each call and allows the request if a token remains. For an LRU or key-value store, say the data structure and the complexity. For a scheduler, a priority queue ordered by run time with a worker that waits for the earliest job.

    • Elevator, vending machine or ATM as a state machine

      Draw the states and transitions before coding. An elevator is idle, moving up, moving down or doors open, and each event such as a button press or arrival is handled by the current state. A vending machine moves through idle, has money, dispensing and out of stock. Implement it with a state interface or an enum and a transition table, so invalid actions are rejected in one place instead of with scattered if statements.

    • Follow-ups: add a new rule without rewriting, make it concurrent, add persistence

      Show that your design bends without a rewrite. For a new rule, say you add a new class that implements the existing interface and register it, leaving old code unchanged. For concurrency, name the shared state and protect it with a lock per resource, or atomic operations, keeping check-and-update in one critical section. For persistence, put a repository interface in front of storage so an in-memory version can be replaced by a database.

      Mock interviews →
    2 sources for this round
  6. Low-level design

    Low-level design60 min

    Several reports

    An SDE-3 candidate designed a feature around Swiggy's serviceability, with discussion of object modelling, handling states and extensibility. An SDE-2 candidate's notes list a notification-system LLD question. A guide describes LLD as classes, interfaces and relationships.

    • object modelling
    • state handling
    • extensibility

    Varies: One guide says LLD is for SDE-1/SDE-2 while seniors get system design; the SDE-3 report had both.

    What can be asked in a low-level design round

    An object-oriented design discussion: classes, interfaces, relationships and the patterns that keep them flexible. Often combined with machine coding.

    • Class design for a booking system, a notification service or a payment module

      Begin by listing the nouns and verbs from the requirements, then turn nouns into classes and group verbs by who owns the data. For a booking system you might have Resource, Booking, User and a BookingService, with a rule that two bookings for one resource cannot overlap. Draw relationships clearly: composition when a part cannot exist alone, an interface when behaviour varies. Say which classes you would write first and why.

      Whiteboard →
    • SOLID principles applied to your own classes

      Tie each principle to a concrete choice in your design rather than reciting the acronym. Single responsibility: the invoice class does not also send email. Open and closed: add a new payment method by adding a class, not editing a switch. Liskov: a subclass must honour the parent's contract. Interface segregation: small interfaces. Dependency inversion: the service depends on a notifier interface, not on an SMS client.

    • Strategy, observer, factory, state and builder patterns, and when each helps

      Know the problem each pattern solves. Strategy swaps an algorithm, such as pricing or routing. Observer lets many listeners react to one event, as in notifications. Factory hides which concrete class is created. State moves behaviour into a class per state, as in an order lifecycle. Builder assembles an object with many optional fields. Say when not to use one: a pattern with a single implementation is usually noise.

    • Concurrency inside the design: locks, thread-safe collections, idempotent operations

      Identify what is shared and mutable, then choose the smallest protection that works. Use a lock around a compound check-then-act, a concurrent map for independent keys, and atomic counters for simple tallies. For operations that may be retried, make them idempotent by carrying a request id and ignoring a repeat. Example: charging a booking twice is prevented by storing the request id with the result and returning it again.

    • Extending the design for a new requirement without breaking old code

      Show the design absorbing change. When a new requirement arrives, say which existing abstraction already covers it and which new class you add. If a discount rule appears, add a new implementation of the discount interface and register it. If you must change old code, explain why the original split was wrong and how you would limit the edit. Mention tests: existing tests should still pass unchanged after the extension.

    3 sources for this round
  7. High-level design

    System design60 min

    One report

    A system design discussion. The SDE-3 candidate designed a promotional notification system covering push architecture, targeting, scale, rate limiting, retries and queues. A guide folds HLD, project deep-dives and ambiguity handling into the senior bar-raiser round.

    • scalable architecture
    • queues and retries
    • rate limiting
    • handling ambiguity

    Varies: One guide says seniors get system design; another folds architecture into the bar-raiser round for SDE-2 and above.

    What can be asked in a system design round

    A 45 to 60 minute discussion of how to build a system at scale: requirements, numbers, APIs, data model, components, bottlenecks and trade-offs.

    • Short links, chat, news feed, notifications, search, rate limiting

      Use one repeatable path: clarify scope and scale, estimate load, define the API, sketch the data model, draw the main components, then probe bottlenecks. For short links, store a mapping from a generated short id to the long url, generate ids with a counter encoded in base 62, cache hot links, and note reads far outnumber writes. For chat, mention persistent connections and a store ordered per conversation.

      System design course →
    • Payments, wallets and ledgers where money must never be lost or doubled

      Money systems put correctness before speed. Use a double-entry ledger where entries are append-only and every transfer writes a debit and an equal credit in one transaction. Protect against doubled charges with an idempotency key stored with the result, so a retry returns the original outcome. For lost updates use a database transaction, and reconcile with the payment provider's records on a schedule.

      System design course →
    • Ride matching, maps and anything with live location

      Split the problem into location ingestion, a geospatial index and matching. Drivers send updates every few seconds to a write-optimised store, often in memory, keyed by a grid cell such as a geohash or S2 cell. To find nearby drivers, query the rider's cell and its neighbours, then rank by distance and estimated time. Say how you handle a stale location and a driver who accepts two rides.

      System design course →
    • File storage and sync, video streaming and content delivery

      For file sync, split files into chunks, hash each chunk and upload only chunks the server lacks, so a small edit transfers a small amount. Keep metadata in a database and chunks in object storage. For video, upload the original, transcode into several resolutions, store segments and serve them through a content delivery network with adaptive bitrate streaming, so the player switches quality as bandwidth changes.

      System design course →
    • Fundamentals: caching, sharding, replication, queues, consistency, failure handling

      Treat each as a tool with a cost. A cache cuts read latency but adds staleness and invalidation. Sharding spreads write load but makes cross-shard queries hard. Replication gives availability and read scale but introduces lag. Queues smooth spikes and decouple services but require idempotent consumers. For failures, name timeouts, retries with backoff and a fallback. State what you give up whenever you choose.

      System design course →
    • Back-of-envelope estimates and what they decide

      Estimates are there to choose a design, so finish each one with a decision. Use round numbers: a day has about 100,000 seconds, so 10 million requests a day is roughly 100 per second on average, with a peak of a few times that. Multiply object size by count for storage, and compare against one machine's capacity. If one database handles the load, say so and avoid sharding.

      Capacity estimation →

    Prepare with: Book · System designSystem design course

    2 sources for this round
  8. Bar raiser

    Bar raiser

    One report

    One SDE-2 candidate reached this round after clearing the online test and was rejected after it; the page gives no detail on what was asked. One guide says it is led by a senior engineer from another team and covers high-level design, project deep-dives and handling ambiguity.

    • design judgement
    • project depth
    • handling ambiguity

    Varies: One guide says it is more common for SDE-2 and above. Single candidate report, date unclear.

    What can be asked in a bar raiser round

    An independent interviewer from outside the hiring team who judges you against the company's leadership principles, with the power to hold the bar.

    • Stories mapped to leadership principles such as ownership and customer obsession

      Prepare a handful of real stories and be ready to map each to more than one principle. Choose the story that fits the principle being probed. Use situation, task, action and result, speak in the first person about what you did, and include a measurable result where you have one. The listener checks that your behaviour matches the principle, not that you know its name.

      Leadership principles chapter →
    • Deep follow-ups on every claim in a story: what exactly you did, what the numbers were

      Expect repeated why and how questions on one story, to separate your own work from the team's. Know the details: the dates, the numbers, the alternatives you rejected, and who disagreed. Say we only when it is true, and I when it is you. If you do not remember a figure, say so and give your best estimate. Consistent detail is persuasive; invented detail collapses under the next question.

      Leadership principles chapter →
    • A technical or design question to confirm the level

      This is a shorter check that your technical level is real. Treat it like any design or coding question: clarify, state assumptions, give a simple solution first, then discuss trade-offs and failure cases. The listener looks for judgement, such as knowing what to leave out and when to be careful. Explaining your reasoning aloud matters more than a perfect final design.

      System design course →

    Prepare with: Book · Leadership PrinciplesBook · Behavioural

    2 sources for this round
  9. Hiring manager

    Hiring manager30-60 min (one guide)

    One report

    In the SDE-3 report, a behavioural round on leadership, ownership, driving a feature end to end and handling technical disagreements. One guide says it covers projects, decisions you owned and why you applied; another mentions alignment with Swiggy's values.

    • ownership
    • leadership
    • conflict resolution
    • values alignment

    Varies: The SDE-3 report lists it as 60 minutes; one guide says senior candidates may also get systems-fundamentals questions.

    What can be asked in a hiring manager round

    A conversation about your past work and how you would fit the team: depth on projects, ownership, decisions and trade-offs, sometimes a design problem.

    • Pick a project and go deep: why this design, what broke, what you would change

      Choose a project you can discuss at every layer. Explain the problem and who it served, the options you considered, why you chose one, what broke and what you would change now. Be clear which parts you did and which the team did. Admitting a flaw earns trust. Opening line: the main constraint was latency, so I chose a cache in front of the database, and I would now add an invalidation strategy.

      Resume grilling chapter →
    • A time you disagreed with a teammate or pushed back on a decision

      Use situation, task, action, result, and keep the disagreement about the work, never the person. The listener is checking that you can hold a view with evidence, listen, and commit once the decision is made. Describe what you proposed, the data or reasoning you used, how you reached agreement or accepted the other path, and what happened. Do not invent a story: use a real one, even a small one.

      Behavioural chapter →
    • How you prioritise when everything is urgent

      Show a method rather than a claim of being busy. Describe how you judge impact and deadline, ask who needs the result and when, and say no or renegotiate scope early when two things clash. Mention communicating the trade-off to stakeholders so nobody is surprised. A sentence you could adapt: I list what is blocking others first, then what has a fixed date, then what moves a metric.

      Behavioural chapter →
    • What you want from the next role and the team

      Answer honestly and tie it to what the role offers. Say what you want to learn or own next, such as larger systems, more ownership of design, or mentoring, and what kind of team helps you do it. Then ask what the team is trying to achieve this year and how the work is reviewed. The listener checks that your wishes match the job and that you have thought about it.

    Prepare with: Book · Resume grillingBook · Behavioural

    3 sources for this round
  10. HR round

    HR and offer20-30 min

    Prep guides

    One guide says some candidates report a short final call about motivation, notice period and logistics, and that the written offer can arrive well after the verbal confirmation.

    • motivation
    • notice period
    • logistics

    Varies: Described as only 'some reports' by one guide.

    What can be asked in a hr and offer round

    The closing conversation: motivation, expectations, notice period, compensation and how the offer is structured. Prepared answers and a clear number help here.

    • Current and expected compensation, and how to answer without boxing yourself in

      Be honest and avoid giving a single number too early. Share your current pay only if you are comfortable, and make clear what is fixed and what is variable. For expectations, say you are flexible for the right role, and offer a researched range based on level and market. If pushed, state a figure you can justify. Never state a number you cannot support, because offers are often checked.

      HR and the number chapter →
    • Notice period, joining date and relocation

      Give the facts exactly as they are in your contract. State the notice period, whether early release or a buy-out is truly possible, and the earliest honest joining date. Do not promise a date your employer has not agreed to. For relocation, say whether you can move, how soon, and whether you would need support. Clear, early information helps the recruiter plan and shows you are reliable.

      HR and the number chapter →
    • Why you are leaving and what you are looking for

      Keep it positive and forward looking. Talk about what you want more of, such as larger scale, ownership or a stronger team, rather than criticising your current employer. The listener checks that you will not leave this job for the same reason. Opening line: I have learned a lot in the current role, and I now want to work on problems at a bigger scale.

    • Levels, equity and how the offer is built

      Ask for the structure rather than only the total. Find out the level and title, base salary, bonus and whether it is guaranteed, equity amount, vesting schedule and cliff, joining bonus and any clawback. Compare offers on a yearly total with the same assumptions. If equity is in a private company, ask how it is valued and what happens on leaving. Asking calmly is normal and expected.

      Levels and equity chapter →

    Prepare with: Book · HR & the numberBook · Levels & equity

    1 source for this round

Preparing for the people rounds at Swiggy

The hiring manager, behavioural and offer conversations. Candidate reports shape the themes; the answers and frames are written for this site, so use them as a structure and bring your own stories.

What Swiggy says it values

  • Ownership and initiativeCandidates report being probed on projects where you acted without waiting to be told.
  • End to end deliveryReported prompts focus on leading a feature from idea to production, not just one piece.
  • Candid disagreementReported questions cover how you handle disagreement in technical decisions.
  • Comfort with ambiguityGuides describe questions on incomplete requirements and unclear scope.
  • Production accountabilityOne candidate reports short questions on on-call culture and how production issues are handled.

Themes candidates report being probed

  • Ownership and initiative
  • Leading a feature end to end
  • Technical disagreement and conflict
  • Ambiguity and incomplete requirements
  • Why Swiggy and decisions you owned
  • On-call and production culture
  • Motivation, notice period and logistics at HR

Questions to rehearse

  1. Tell me about a project where you showed ownership and led a feature from start to finish.One report

    What is being checked. An SDE-3 candidate reports prompts on ownership, initiative and driving a feature end to end. The listener is checking whether you carry work past your own task, including the unglamorous parts.

    How to frame it. Use a feature with a beginning, a launch and a follow-up. Say what you decided, who you had to bring along and what you did after release. Example opening: 'Nobody had been assigned the rollout plan for the new flow, so I wrote it, ran the dry run and watched the first day of traffic myself.'

  2. Describe a technical decision where you and someone else disagreed, and how it was settled.One report

    What is being checked. The same SDE-3 account lists disagreement in technical decisions. The listener checks that you argue from evidence, respect the person and can accept the outcome.

    How to frame it. State both positions fairly, name the evidence that moved the decision and what you did once it was made, including when it went against you. Example opening: 'We disagreed about caching at the service level versus the client, so we measured the hit rate on real traffic.'

  3. How do you handle production issues, and what does good on-call practice look like to you?One report

    What is being checked. A candidate reports short questions on on-call culture and production issues at the end of a problem-solving round. The listener is checking that you have been accountable for live systems and have views on reducing repeat incidents.

    How to frame it. Walk through your own routine: detect, limit the damage, communicate, fix, then review. End with one change that prevented a repeat. Example opening: 'My first move is to stop the bleeding with a rollback or a flag, and only then to look for the cause.'

  4. Tell me about a time the requirements were unclear or incomplete, and what you did.Prep guides

    What is being checked. A guide describes behavioural questions on ambiguity, disagreement and incomplete requirements. The listener checks whether you make progress under uncertainty rather than waiting.

    How to frame it. Show how you turned vague scope into questions, assumptions and a first small deliverable that tested them. Example opening: 'The brief said make delivery estimates better, so I first asked which estimate customers were complaining about.'

  5. Which decisions on your recent projects did you own, and why are you applying here?Prep guides

    What is being checked. A guide describes the opening conversation as projects, decisions you owned and reasons for applying. The listener separates your decisions from those of the team and checks that your reasons are specific.

    How to frame it. Pick two decisions, state the alternative you rejected and the result, then give a reason for applying tied to the kind of problems in food or quick commerce logistics. Example opening: 'On the last project I owned the choice of queue and the retry policy, and I rejected the simpler option because...'

The offer conversation

  • One SDE-3 candidate reports being first offered SDE-2 at the high end of the band and the offer being revised to SDE-3 after they received a competing offer from another company; the process took about a month.
  • A guide says some reports add a short HR round of 20 to 30 minutes on motivation, notice period and logistics, and that its content varies by level and team.
  • As general advice, ask early what level the role is scoped at, get the full breakdown in writing, and keep any competing offer in writing too.

What we could not verify. No official values page that names the values could be read, so the entries above are the themes candidates and guides point to. Only one first-hand report was read (SDE-3, 2025), and the two guides give no first-hand detail on the HR round.

What we could not verify. LeetCode Swiggy SDE-1/SDE-2 posts (2025-26), Glassdoor and Naukri Code360 were 403, so SDE-1 and campus details rest on guides. Candidate evidence is one Roundz SDE-3 post (July 2025) and one undated Aced SDE-2 page. Machine coding and the HR round are not confirmed by any candidate report read here.