Flipkart System Design Interview: What the Bar Tests at Each Level

Most system design guides tell you to draw boxes and talk about trade-offs for 45 minutes. The Flipkart interview does something different. They hand you a keyboard and ask you to build it.

The machine coding round is Flipkart's signature. It's 90 minutes of live coding, in-memory, object-oriented design from scratch. No databases. No frameworks. No Stack Overflow. Just your classes, your data structures, and whether your design actually compiles and runs. This sits on top of a separate HLD round where you do the whiteboard-and-scale discussion everyone else does. Two rounds. Two completely different skills. One loop.

This guide covers both, with the bar at each level and the prep that actually matters.

What Round Tests What

Flipkart's full loop for SDE-2 and above is typically five rounds, though SDE-1 loops can be four. Here's the structure:

Round	Format	What It Tests
Online Assessment	90 min, 3 problems on HackerRank	DSA at medium-hard difficulty
PSDS Round	60-75 min, 1-2 problems	Problem solving, communication, edge cases
Machine Coding (LLD)	90-120 min, live coding	OOP, design patterns, working code
System Design (HLD)	45-60 min	Architecture, trade-offs, scale
Hiring Manager	45 min	Ownership, team fit, past work

The machine coding round is the most differentiated part of the loop. Every company asks system design. Very few ask you to submit working code that runs against test cases. This is the part where "I'd use a Strategy pattern here" needs to become actual Strategy pattern code that doesn't throw a NullPointerException at line 47.

The Machine Coding Round: Flipkart's Actual Bar

The round is structured as three segments: 15 minutes of requirement clarification and class design, 90 minutes of coding, and 15 minutes of post-coding discussion. You write real, executable code. In-memory data structures only. No SQL, no Redis, no external dependencies.

The interviewer expects your code to run and produce correct output for the given inputs at the end. Not pseudocode. Not "I'd implement this as a HashMap." Actual code. HashMap and ArrayList are your database.

Common problems from recent rounds:

Parking lot system with multiple vehicle types, dynamic spot allocation, and pricing
Food delivery platform with restaurants, menus, orders, and delivery assignment
Library management with books, members, borrowing limits, and fines
Splitwise clone with expense splits across multiple members and settlement logic
In-memory cache with LRU or LFU eviction
Subscription service where users subscribe to recurring deliveries from local stores

The problems always look simple for the first five minutes. Then the follow-ups arrive, and you realize you've painted yourself into a corner with a GodObject that does everything and a Main class that does nothing.

What Gets Scored

Class design. Your entity model matters more than your algorithm. The interviewer is evaluating encapsulation, how responsibilities are split across classes, and whether adding a new feature would require rewriting half your code or politely extending one interface.

Design patterns applied correctly. Strategy for pricing rules. Factory for object creation by type. Observer for state-change notifications. Using a pattern badly is worse than not using one. Nothing signals panic like a Singleton that shouldn't be a Singleton.

SOLID principles in practice. Single responsibility is the most visible. If your ParkingLot class also handles payment processing, that's a red flag that appears in the first 10 minutes.

Working output. This is the one that trips people. You need to write code that runs. Use Java if you're comfortable with Java. Most Flipkart interviewers are fluent in it.

The Pre-Coding 15 Minutes

Spend them well. Clarify scope: what features are required versus nice-to-have. Draw a rough class diagram on paper or in the editor comments. Identify your core entities and their relationships before you touch the keyboard.

Candidates who skip this and start typing usually finish with spaghetti code and no time to fix it. Candidates who spend 15 minutes on design typically finish with 10 minutes to spare and space to add extensions.

Yes, 15 minutes feels like a long time to not be coding. It isn't.

The System Design (HLD) Round: What Actually Gets Asked

This is the architecture conversation. 45 to 60 minutes. Design at scale, walk through trade-offs, defend your choices. Flipkart's problems tend to be e-commerce flavored because that's the domain interviewers know and can probe deeply.

Recent HLD questions from candidate reports:

Design a subscription grocery service (Flipkart's own product direction)
Design Swiggy's order and delivery system with real-time driver assignment
Design a flash sale system that handles 10x traffic spikes without overselling
Design a school bus tracking and navigation system
Design a digital wallet with atomic transfers and idempotency
Design BookMyShow with concurrent seat reservation

The expectation is not a perfect answer. It's a structured conversation with real technical depth. "I'd add a cache here" is not depth. "I'd use Redis with a cache-aside pattern, a 60-second TTL for the product catalog, invalidated on writes via a Kafka consumer" is getting warmer.

What the Interviewer Is Probing

Microservices boundaries. Can you identify which components should be separate services? What does the user service know about the order service? How do they talk without becoming one giant service in disguise?

Data modeling is weighted heavily at Flipkart. Schema design, normalization, how your tables support the query patterns you're describing. Flipkart interviewers think concretely about data. "I'd store this in a table" will be followed immediately by "what does that table look like?"

Consistency versus availability. What happens when the inventory service is down during checkout? Reject the order or proceed and reconcile later? Neither answer is wrong. The trade-off analysis is the point.

Kafka appears in almost every answer. Know producer-consumer patterns, at-least-once delivery, and why you'd use a message queue over a synchronous call. "Just use Kafka" is not an answer.

Caching strategy. Read-through versus cache-aside. TTL decisions. User-specific pricing during a sale? Don't cache that. Real-time inventory counts during a flash sale? Absolutely don't cache that.

Back-of-envelope calculations are expected. The interviewer will ask how many writes per second, how much storage per year, and whether your database can handle it. Have a framework for these. Don't wing it.

How the Bar Shifts by Level

SDE-1. Machine coding is the main filter. HLD may be shortened or light-touch. The bar is: can you build a working OOP system from scratch, do you write clean code, and can you handle one or two extensions? The HLD discussion, if it happens, stays at the component level. Nobody expects Kafka partition strategy from a new grad.

SDE-2. Both rounds at full depth. Machine coding needs to demonstrate extensibility, not just correctness. HLD needs actual numbers, a clear service breakdown, and you driving the conversation. When the interviewer says "how would you handle 10 million daily orders?" you're expected to start with bandwidth estimates, not wave your hands and say "horizontal scaling."

SDE-3. The HLD round becomes adversarial. The interviewer introduces failure scenarios and watches you recover. "Your inventory service is returning stale data. How do you detect it? How do you recover?" Machine coding shifts to elegance. Does your solution anticipate extension points, or did you abstract the wrong things?

SDE-4 and above. Cross-system design. Platform capabilities multiple teams consume, or redesigning an existing system with known scaling problems. Operational concerns enter the conversation: how do you deploy this without downtime, how do you monitor it, what's the rollback plan. If you haven't thought about what happens when your migration script fails at 2am, you'll find out in the interview.

The Tech Context That Changes Your Answers

Flipkart runs one of India's largest Java-based microservices platforms. Thousands of services, over 700 MySQL clusters, a Hadoop data platform at 35 PB. They migrated from a pure MySQL fleet to TiDB to handle HTAP workloads without splitting their transactional and analytical stacks. That tells you how they think.

This context matters for your HLD answers. When you suggest Redis for caching, Flipkart interviewers know Redis well. When you suggest Kafka for async order processing, they've shipped production systems on it. Vague answers get probed until you produce real reasoning or run out of answers.

Big Billion Days is Flipkart's Super Bowl for systems. Interviewers have lived through services that buckled and services that held. Questions about flash sale architecture or inventory management will be probed with real operational curiosity. The person across from you probably had pager duty during one of these.

What Gets You Rejected

Jumping to code before designing. Candidates who start typing in the first two minutes almost always have to backtrack, delete everything, and start over with five minutes less on the clock.

Producing code that doesn't run. If you spend 90 minutes writing beautiful class hierarchies and your main method throws a NullPointerException, you've failed the functional requirement. Beautiful unrunnable code is still unrunnable code.

Generic system design. Saying "add a cache" without specifics. Flipkart interviewers want to know which component, why that component, and what trade-offs you accepted. "Use a CDN" needs to become "put static assets behind CloudFront with a 24-hour TTL and invalidate on deploys."

Missing the data model. Schema design comes up explicitly more at Flipkart than at most companies. If you can't defend your table structure or explain why you chose SQL over NoSQL, the interviewer will push until you produce reasoning or run out of answers.

Ignoring failure modes. The HLD round at SDE-2+ will include a failure scenario. Candidates who've only designed the happy path produce inconsistent answers the moment a service goes down. "The payment service will be reliable" is not a system design.

How to Prepare

Machine coding comes first. Build five to six complete LLD systems from scratch, in your interview language (Java is safest), without IDE autocomplete. Time yourself. Parking lot, food delivery, library management, Splitwise, and a cache are the five problems that appear most frequently. Do them until the class design is automatic and the 15-minute design phase feels like enough time.

Learn three to four design patterns by implementation, not definition. Strategy, Factory, Observer, and Command cover 80% of what appears. Reciting the pattern is irrelevant. Writing it in five minutes is not.

For HLD, work through Flipkart-flavored problems: flash sales, real-time order tracking, subscription services, search and ranking at e-commerce scale. The food delivery system design walkthrough and e-commerce platform design cover the core patterns Flipkart tests. The system design interview tips guide has the 45-minute structure.

Practice the data modeling piece separately. Given a system design problem, sketch the schema before discussing architecture. Entity relationships, cardinality, index strategy. Flipkart interviewers will land there regardless of what you draw first.

Recommended timeline:

Week	Focus
1-2	Machine coding fundamentals: OOP, SOLID, 2-3 practice problems
3-4	Machine coding fluency: 3-4 more problems timed, design pattern review
5-6	HLD: e-commerce, delivery, flash sale, booking system problems
7	Mock interviews, weak area review

The HLD verbal piece is the one most people underinvest in. Knowing trade-offs is not the same as explaining them under pressure to someone who already knows the answer. SpaceComplexity runs voice-based mock interviews with structured feedback on how you explain trade-offs, not just which ones you know.