Real, anonymized candidate journeys from recent (2025) Flipkart SDE-1 and SDE-2 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 — Machine Coding
A recruiter reached out on LinkedIn on a Monday and the machine coding round was scheduled for that same Thursday. The problem came in a shared doc: build a small investing app where users can see a list of stocks, place buy and sell orders, and check their holdings. I had 90 minutes. First I spent about ten minutes writing down the entities on paper — Stock, User, Order, Portfolio — and only then opened the editor. I built the order flow first because that was the core of it, then the holdings calculation, and I kept the price source behind an interface so I could swap in a fake for the demo. With about fifteen minutes left I wrote a small driver that ran a few buys and sells and printed the portfolio. Then the interviewer joined the call, I ran the demo, and she asked why I had kept the price source separate. I said it was so a real feed could be plugged in later without touching the order code. She asked me to add a sell-validation check live — you cannot sell more than you hold — and I added it in a couple of minutes. Round ended on time.
Round 2 — DSA (1 hour)
This was two days later, one hour, two problems. The first one was a recursion question — generating all valid combinations under a constraint. I explained the recursion tree out loud first, wrote the base case, then the recursive step, and dry-ran it on the sample. It passed. The second one was a DP problem on an array. I started with the plain recursive version, said it would be exponential, then added memoization, then converted it to a bottom-up table. The interviewer asked for the space complexity and whether I could bring it down; I showed how only the previous row was needed. We finished with about five minutes to spare and he asked a couple of questions about my current project.
Round 3 — System Design
The system design round was the following week. The prompt was: design a music streaming service like Spotify. I began by asking about scale and what mattered most — she said assume tens of millions of users and focus on playback and search, not recommendations. So I split it into an upload path (transcode the song into a few bitrates and push it to object storage and a CDN) and a playback path (the app fetches a manifest and streams chunks from the CDN). Then I covered the metadata store for songs, artists and playlists, and a search index on top of it. She asked what happens when a very popular song is released. I talked about CDN caching handling most of it and the metadata service sitting behind a cache. Then she asked how I would track play counts without hammering the database, and I described batching play events through a queue and aggregating them. It felt like a conversation more than a test.
Round 4 — Hiring Manager
The last round was with the hiring manager, about 45 minutes. It was mostly about my current work — what I had built, one incident I had handled, and why I wanted to move. He asked how I deal with a teammate who disagrees with my design, and I gave a real example from my team. Then he explained what his team at Flipkart worked on and asked if I had questions. I asked about the on-call setup and how the team decided what to build. That was it. The recruiter called about a week later with the offer, roughly 23 days after my first round — quicker than any other company I was talking to at the time.
Key takeaway: The whole process took about 9 days end-to-end, with an offer arriving roughly 23 days after the first interview — a notably fast turnaround at the SDE-2 level.
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 — Machine Coding (90 min)
I applied through the careers page and got the machine coding round about two weeks later. The problem was a conference-room booking system: rooms, users, bookings for time slots, no double-booking, and a few bonus features if time allowed. I had 90 minutes alone before the discussion. I started by listing the classes — Room, User, Booking, BookingService — and wrote the overlap check first because I knew that was where bugs would hide. Then I added searching for free rooms by capacity. I got the core done in about an hour and spent the rest on one bonus feature, cancelling a booking. When the interviewer joined he asked me to run it, then asked how I would add recurring bookings. I explained I would make the slot generation a separate step so the conflict check stayed the same. He seemed fine with that and I cleared this round.
🔒 3 more rounds — continue this journey in the full kit
Round 1a — Machine Coding (90 min)
My process started in the second week of January. The first thing they sent was a machine coding problem: a task scheduler that assigns tasks to workers and rebalances when a worker gets overloaded or goes down. Ninety minutes, then a follow-up discussion later. I read it twice and decided to keep it simple — a Task class, a Worker class with a capacity, and a Scheduler that picks the least-loaded worker. I wrote the assignment logic first, then the part where a worker is removed and its tasks are handed back to the scheduler. I used a priority queue keyed on current load to pick workers. Around the 70-minute mark it worked for my test cases and I spent the last twenty minutes cleaning up names and adding a small README explaining the design and what I would do differently with more time. I submitted a couple of minutes before the deadline.
🔒 4 more rounds — continue this journey in the full kit
Round 1 — Machine Coding (2.5 hours)
The first round was a take-home style machine coding problem, two and a half hours. They called it FlipStocks — a small trading platform where users can register, add money, and buy and sell stocks, and the instructions said clearly that they would judge OOP and SOLID principles, not just whether it ran. So I started with the interfaces: a repository interface for storage, a service layer for orders, and a separate class for wallet operations. Then I wrote the actual in-memory implementations. Buy and sell went in first, then the wallet checks, then a simple command-line driver to show it working. I wrote a few unit tests for the order service near the end. I finished with about twenty minutes left and used it to write a short design note. In the review call afterwards the interviewer asked why I had put the wallet in a separate class, and I explained it was so that money rules could change without touching the order code. I was told I cleared this round the next day.
🔒 3 more rounds — continue this journey in the full kit
Round 1 — PS/DS (45 min, in-person)
I came in through the Girls Wanna Code program, so the first round was in person at the Bangalore office, 45 minutes. The interviewer gave me one problem: piles of items, a fixed number of hours, find the minimum rate that finishes everything in time. I first said the obvious thing — try every rate from 1 upwards and check — and worked out that this would be too slow for large inputs. Then I noticed that if a rate works, every bigger rate also works, and said that out loud. She nodded, so I wrote the binary search on the rate, with a helper that adds up the hours for a given rate. I dry-ran it on her example, [3,6,7,11] with 8 hours, and got 4. She asked about the ceiling division and whether I could do it with integers only, and I changed it to (pile + rate − 1) / rate. We finished a few minutes early and she asked what I had worked on during the internship.
🔒 2 more rounds — continue this journey in the full kit