Real, anonymized candidate journeys from recent (2025) Swiggy SDE loops in India — round by round, including what was asked, how the candidate approached it, and the outcome.
One complete journey, start to finish
Round 1 — Online Assessment
I applied on the careers page in late November and got the online assessment link within a few days. It had three problems and a fixed time limit. I started with the sliding-window one because I had practised that pattern the most — a longest-valid-window question on an array. I wrote the two-pointer loop, tested it on the sample, and it passed. The second was a shortest-path problem on a graph with equal edge weights, so I used BFS from the source and tracked the distance level by level. That passed too. The third one asked for the nth root of each number in an array, which sounded odd at first. I first tried the built-in power function, saw precision issues on a test case, and switched to a binary search on the answer with an integer check. That took the longest, but all three ended up passing. I got a mail about the technical interview roughly a week later.
Round 2 — Technical (DSA + Java/Spring)
The technical round was a one-hour video call. The interviewer started with a short intro and then asked me to count the number of structurally different BSTs for values 1 to n. I first explained the brute-force way — pick each value as root, recurse on both sides — and wrote it as plain recursion. She asked about the time complexity, and I said it repeats the same subproblems, so I rewrote it as a bottom-up DP where dp[k] is the count for k nodes and each root splits the rest into left and right. I dry-ran it for n = 3 and got 5, which matched her example. After that she moved to Java. She asked me to explain the difference between JDK, JRE and JVM, then how garbage collection works and which generations objects move through. Then she asked what @EnableAutoConfiguration does in Spring Boot and how dependency injection works there — I explained constructor injection and why I prefer it over field injection. She seemed fine with the answers and the round ended a few minutes early.
Round 3 — LLD
The LLD round came about four days later. The problem was a shopping cart: add items, apply discounts, and pay. Before I wrote a single class, I asked my clarifying questions — whether multiple discounts could stack, whether a discount applied to the whole cart or per item, and whether payment needed more than one method. The interviewer actually pushed on this and kept asking what else I needed to know before letting me start, so I also confirmed the quantity handling and wrote my assumptions in the shared doc. Then I listed the entities: Item, Cart, a DiscountStrategy interface, and Payment. I explained that discounts would be separate classes behind one interface — the Strategy pattern — so a new discount type would not touch the cart. He asked me why Strategy and not a simple if/else, and I said the if/else would grow every time marketing added an offer. Then he asked how I would add a buy-two-get-one offer, and I walked through adding just one class. We ended with a quick discussion on how payment would freeze the cart.
Round 4 — Hiring Manager
The hiring manager round was scheduled for an hour the following week. He started by asking me to walk through my main college project and one internship project, and he went deep — why I chose the database I did, how I handled a slow query, what I would change now. Then he asked SQL questions: the difference between indexes and when a query would not use one, and joins versus subqueries. After that he asked me to rate myself out of ten on DSA, Java and databases, and to explain the ratings honestly. Then came behavioral questions — why Swiggy, why backend, and a time I had to push through something hard. I was not expecting a coding problem in this round, but near the end he gave me an unbounded-knapsack DP: pick items with repetition to hit a value with minimum count. I wrote the 1-D DP and explained why the loop order allowed reuse. He nodded and we wrapped up. The offer call came about a week after that.
Key takeaway: Clarify requirements and constraints before designing anything, state your assumptions out loud, and prepare for project deep-dives and behavioral questions to show up in the same round as a coding problem — they aren't always kept separate.
More real interview journeys
The first round of each journey below is shown in full; the rest of each candidate's journey — every remaining round, verbatim — is part of the Placement-Ready PYQ Kit.
Round 1 — HackerEarth Online Assessment (3 hrs)
A recruiter messaged me on LinkedIn in the first week of September and sent a HackerEarth link the same day. The assessment was three hours and it was not a LeetCode-style test. It asked for a small CRUD app with a React frontend and a Node backend, each judged by its own set of test cases. I read the spec twice, then started with the backend since the frontend depended on its routes. I set up the Express routes, added the in-memory store they asked for, and hit each route with a quick script. Then I moved to React and built the list, the add form, and the edit and delete buttons. I ran the frontend tests first and every one passed. The backend tests ran next and one failed — a validation case on one of the routes that I had not read carefully enough. I had about ten minutes left and could not find it in time, so I submitted as it was. Two days later the recruiter mailed that I had cleared the round anyway and the JS interview was being scheduled.
🔒 3 more rounds — continue this journey in the full kit
Round 1 — Online Assessment
I applied through a referral from a college friend and got the online assessment link about a week later. It had two problems, both medium. The first was an array problem where I had to count pairs meeting a condition — I first wrote the nested-loop version to make sure I understood it, then replaced it with a hashmap that stored what I had already seen, and that passed all the cases. The second one was a sliding-window question on a string, finding the longest window that satisfied a constraint on the characters inside it. I kept a frequency map for the window, moved the right pointer forward, and shrank from the left whenever the constraint broke. It failed two hidden cases at first; I realised I was not updating the map when shrinking, fixed that, and everything passed. I finished with around fifteen minutes to spare. The recruiter confirmed a couple of days later that I had cleared it and set up the coding interview for the following week.
🔒 3 more rounds — continue this journey in the full kit
Round 1 — DSA Buffet
The first round was a one-hour video call, scheduled about a week after the recruiter screen. The interviewer opened with Number of Islands. I said it was a flood-fill, wrote a BFS from every unvisited land cell, and dry-ran it on a small grid; he was happy with that in about ten minutes. Next he gave me a subset-sum counting problem, then added a twist: the numbers could be negative. I explained why the usual positive-only DP table breaks and switched to recursion with a memo keyed on index and remaining target. He asked about the number of states and I worked out the bound out loud. The third problem was a Trie — insert, search and startsWith. I wrote the node class with a children map and an end flag, then the three methods, and he asked how I would free memory on delete. I described a recursive delete that prunes empty nodes. We ended right on time and he said the next round would be scheduled soon.
🔒 2 more rounds — continue this journey in the full kit