Flipkart Onsite Interview Loop: Every Round Explained

Flipkart runs a machine coding round that most engineers have never practiced. That single fact explains a disproportionate share of SDE-2 offer misses. The rest of the loop is recognizable: DSA, system design, a hiring manager chat. But 90 minutes to design and build a working console application while someone watches you? That is a genuinely different skill from anything LeetCode trains.

This guide covers the Flipkart onsite interview round by round, SDE-1 through SDE-3: what each one evaluates and how to prepare.

The Loop at a Glance

Round	SDE-1	SDE-2	SDE-3
Online Assessment	Yes	Yes	Yes
DSA / Problem Solving	2 rounds	1 round	1 round
Machine Coding	Sometimes	Yes (90 min)	Yes (90 min)
System Design	No	Yes (60 min)	Yes (60 min)
Hiring Manager	Yes	Yes	Yes

Every round is eliminatory. Clear four, stumble on the fifth. No rescue vote.

The OA: Your Entry Ticket

Before any human interviewer, you sit a 90-minute HackerRank assessment. Two medium and one hard LeetCode-style problem. The rough bar is solving 2.5 out of 3 correctly under the clock.

If you scraped through on partial solutions, expect the DSA rounds to feel harder than they should. A clean OA sweep means you arrive with momentum. A near-miss means you arrive defensive, which is a genuinely terrible starting position.

DSA Rounds: Your Process Is Being Graded Too

SDE-1 gets two separate rounds of roughly 60 minutes each. SDE-2 and above get one. Each contains one or two medium-hard problems.

The interviewer scores your process as much as your code. Restating the problem, confirming edge cases, narrating a brute-force approach, optimizing out loud: all of it contributes to the communication dimension. A correct solution typed in silence gives the interviewer almost nothing to write. A slightly imperfect one narrated well gives them a lot.

Topics that come up consistently across candidate reports:

Trees: level-order traversal, LCA, path sum variants
Graphs: BFS/DFS on grids, connected components, shortest paths
Priority queues: top-K elements, merge K sorted lists
Dynamic programming: knapsack-style, substring problems
Hashmaps: sliding window, prefix sum with hash

Grinding 150 to 200 LeetCode mediums across these families is the right preparation. Grinding them in silence at 3am is less useful than grinding 100 of them out loud, explaining every step to your rubber duck.

Machine Coding: The Round Nobody Prepares For

This is what separates Flipkart from every other Indian tech company. Machine coding is a 90-minute session to design and build a working, runnable console application from a problem statement. The interviewer watches you build it, may add requirements partway through, and expects a demo at the end. Some reports describe the full session as closer to 2.5 hours: 30 minutes discussing requirements, 90 minutes of coding, 30 minutes of demo and Q&A.

The bar is not a correct solution. The bar is correct, modular, extensible, readable code that actually runs.

"Actually runs" is doing real work in that sentence. Non-compiling code is a serious mark against you regardless of how beautiful the class hierarchy looks on your screen.

Problems from recent cycles:

Tic Tac Toe (generalizable to n×n, multiple players, custom win conditions)
Parking Lot (vehicle types, floors, dynamic fee calculation)
Splitwise (expense tracking, balance settlement, minimal transactions)
URL Shortener (encode/decode, expiry, click tracking)
Rate Limiter (token bucket or sliding window)
Bowling Alley (lane booking, scoring edge cases)

The topic rotates. The evaluation criteria do not.

OOP design. Classes are cohesive, each owns one responsibility. Interfaces and abstractions where appropriate, without over-engineering while the clock is running.

Extensibility. If the interviewer adds "now support a new vehicle type," that should touch one class, not five files. Code that requires sweeping edits for one new feature fails this dimension. Hard.

Correctness. The application must run and produce correct output against the given test cases.

Code hygiene. Meaningful names, no dead code, error handling for the obvious failure cases the problem implies.

Java is the most common language choice. Python works, but the OOP structure comes through more naturally in Java for problems that lean on inheritance and interfaces.

Where Candidates Run Out of Time

Most failures follow the same pattern: 30 to 40 minutes designing on paper, then a sprint that produces incomplete code. It looks like good preparation. It results in a demo where you describe what the code would do if you had finished writing it.

Build a working core first, then refactor for clean design. An ugly-but-running solution with a readable structure beats a beautiful incomplete one every time.

Before writing any code, spend five minutes identifying the entities (classes), the relationships between them, the operations each entity needs, and where extensibility is likely to come up. Build interfaces first, then implement. Then write the core flow end to end before you touch anything optional.

The preparation strategy here is underutilized. Most engineers do hundreds of LeetCode problems but have never built a complete runnable application from scratch against a timer. Run at least five full 90-minute machine coding sessions before your onsite. The first one will be rough. By the fifth you will have a personal pattern for entity modeling and interface design that carries directly into the actual interview.

The hardest part to simulate alone is narrating design decisions while someone watches. SpaceComplexity runs voice-based mock interviews that replicate that pressure. Explaining your choices under observation is a different skill from coding quietly at home.

System Design: Know Your E-Commerce Failure Modes

SDE-2 and above face a 60-minute design round. Problems are standard system design topics with an e-commerce or supply chain skin: product recommendation engines, flash sale backends, real-time inventory services, warehouse management systems.

The expected arc: clarify requirements, estimate scale, sketch the high-level architecture, go deep on one or two critical components, discuss failure modes.

The failure modes question almost always comes. What happens when the inventory service is down? What happens when two users try to reserve the last unit simultaneously? Having concrete answers, not "we add redundancy," is what separates a pass from a fail.

At SDE-3, surface-level architecture does not survive 60 minutes of expert probing. Specific storage choices, replication strategies, consistency trade-offs, and how the design evolves under changed requirements are all fair game.

For the structural framework, system design interview tips covers the 45-minute clock breakdown. Adapt it with e-commerce examples specific to Flipkart's domain and you will arrive considerably better prepared than most candidates at your level.

Hiring Manager: More Technical Than It Looks

Many candidates treat this round as a formality and prepare only vague collaboration stories. That is a mistake that the hiring manager recognizes immediately, because they hear those vague stories constantly.

The round opens with your current projects: the decisions you made, the hardest technical problem you encountered, what you would do differently. Bring a project where your decisions are individually visible and defensible. Not one where you implemented a spec someone else wrote. The interviewer notices immediately when "we built X" cannot answer "why did you choose that data model?"

Common questions across levels:

Walk me through the most technically complex thing you have shipped.
What was the hardest bug you debugged and how did you find it?
Tell me about a time you disagreed with a technical direction.
Where do you want to be in two years?

The tone is conversational and relaxed compared to machine coding. That relaxed tone is a trap. Stay concrete.

How to Prepare by Level

SDE-1. Spend 80% of prep time on DSA. Target 150 to 200 LeetCode mediums across the major pattern families. Practice narrating while you code, not after. The machine coding round is sometimes skipped at this level, but treat it as required and prepare accordingly.

SDE-2. Machine coding is the differentiator. Many SDE-2 candidates lose the offer here despite strong DSA rounds. Run at least five full 90-minute machine coding sessions before the onsite. Add system design in parallel: one new topic per week for six weeks, with emphasis on databases, caching, and message queues. Six to eight weeks of focused preparation is realistic for a currently employed engineer.

SDE-3. System design will go deep. Knowing the components is not enough. You need to defend specific choices under pressure and understand how each decision behaves at failure. The HM round at this level also involves leadership and influence questions. Prepare stories where your individual technical judgment was the deciding factor, because generic answers at SDE-3 level are easy to spot.

What to Remember

Machine coding is Flipkart's signature round and the most common failure point for mid-level candidates
DSA rounds are medium-hard; process and narration matter as much as the final code
System design at SDE-2 and above carries an e-commerce flavor; failure modes will be probed
The hiring manager round is more technical than most candidates expect
Build a working core first in machine coding, then refactor; never design for 40 minutes and code for 50

For how Flipkart's loop compares to the broader Indian tech market, see Flipkart vs Amazon India. The complete process from application through offer is covered in the Flipkart Software Engineer Interview guide.