Interview
Flipkart Machine Coding Round: The 90-Minute Test (2026)
Flipkart's 90-minute machine coding round is its signature interview. Learn the format, how object-oriented design is graded, and how to practise for it.
If Flipkart's interview process has a calling card, it is the machine coding round. Ninety minutes, one under-specified problem, and running code at the end — graded explicitly on object-oriented design rather than on whether the output is correct. It is the most-discussed stage of the loop in candidate accounts, and the one that most reliably separates offers from rejections.
This guide covers the format, how the grading actually works, the structure that fits in ninety minutes, and how to practise. To work through the design problems evidenced at Flipkart, Flipkart's interview kit holds nine low-level design problems attributed to the company, each with a worked editorial and AI-evaluated practice.
Where it sits in the loop
| Stage | Format | What it screens |
|---|---|---|
| Online assessment | Timed algorithmic problems | Baseline coding ability |
| Live data structures round | Coding with an engineer | Problem solving, complexity reasoning |
| Machine coding | 90 min, graded on object-oriented design | Design under pressure, code quality |
| System design (SDE-2 and above) | Architecture discussion | Scale, trade-offs, distributed thinking |
| Techno-managerial / HR | Project depth and fit | Ownership, collaboration, level |
The algorithmic rounds are real and separate — they are not a formality on the way to the design round. But the machine coding round is where the loop concentrates, and it is the stage worth over-preparing.
What "graded on object-oriented design" actually means
This is the phrase that matters, and it changes how you should spend the ninety minutes.
In an algorithmic round, a correct answer with ugly code usually passes. Here the emphasis inverts: a working system with a muddled design scores below a working system with a clean one. The output being right is necessary but not sufficient.
Concretely, graders are looking at:
Does a domain model exist? Are there classes that represent the things in the problem — with behaviour, not just fields — or is everything happening inside one procedural block?
Does each class do one thing? A class that parses input, applies business rules and formats output is three classes wearing one name.
Are interfaces placed where behaviour genuinely varies? Not everywhere. An interface with a single implementation and no plausible second one is noise; an interface at the point where the requirements clearly branch is the single strongest signal in the round.
Does it extend cleanly? Near the end you will often be asked "how would you add X?" If the answer is "write a new class implementing this existing interface", you score well. If it is "change these four methods and this switch statement", you do not.
Is it readable? Naming, method length, consistency. This is read as a proxy for what your production code looks like.
💡 Pro Tip: Say the design out loud as you build it — "I am putting this behind an interface because pricing rules are the thing most likely to change". Stated intent is credited; silent good instincts sometimes are not.
The format
- Ninety minutes, typically. Confirm with your recruiter, as it varies by level and role.
- Running code. Not pseudocode, not a class diagram. It compiles and executes.
- Your choice of language. Java is the most common in reported accounts, but use the language you are fastest in.
- In-memory state. No database, no web framework, no network. Reaching for Spring wastes the clock.
- A driver or test harness that demonstrates the flows end to end.
- A deliberately incomplete problem statement. The gaps are part of the test.
Problem shapes reported across accounts are the familiar object-modelling exercises — inventory and cart systems, parking lots, ride or order matching, expense splitting, library or booking systems, notification dispatch. The domain rarely matters; the modelling does.
⚠️ Important: Spend the first five minutes clarifying scope and stating assumptions. An under-specified prompt is not an oversight — it is checking whether you ask or whether you silently build the wrong thing.
Structuring ninety minutes
| Time | Focus |
|---|---|
| 0–5 min | Clarify the spec. State assumptions and what you are explicitly excluding. |
| 5–15 min | Sketch the domain model: entities, and the two or three places behaviour varies. |
| 15–60 min | Build the core flow end to end. Keep it running at all times. |
| 60–75 min | Edge cases; extract the abstractions the design is asking for. |
| 75–85 min | Driver or tests demonstrating the flows. |
| 85–90 min | Walk through the design and name your trade-offs. |
The last five minutes are worth more than their share. Explicitly naming what you left out and why converts an unfinished solution into evidence of judgement — which is exactly what the round is trying to measure.
✅ Do: Get the smallest working version of the core flow running early, then improve its structure. ❌ Don't: Spend the first half hour on an elaborate class hierarchy before a single line executes.
The failure modes
The same handful of mistakes recur across reported experiences:
- Nothing runs at the end. The single most common failure, and fatal in a round where working code is the floor.
- Over-engineering early. Abstract factories and builders before the core flow exists.
- One god class. No domain model; all logic in a single procedural blob. This fails the round's explicit grading criterion directly.
- Interfaces everywhere. Over-abstraction reads almost as poorly as none, because it suggests pattern application without judgement.
- Building the wrong thing. The consequence of not clarifying.
- Silence. Design reasoning the interviewer never heard cannot be marked.
- Fumbling the extension question. Answering "how would you add X?" with a rewrite.
The reliable fix is rehearsal under the real constraints — ninety minutes, no assistant, running code at the end. The nine low-level design problems evidenced at Flipkart come with worked editorials, and an LLD mock interview will interrogate your design the way an interviewer does.
Preparing for the rest of the loop
The algorithmic rounds — the assessment and the live data structures round — reward pattern recognition over problem volume. The DSA Patterns Sheet is free to browse and organises problems by the pattern each tests; how to identify the right DSA pattern in a coding interview covers the recognition skill itself. Short sessions of in-browser code practice with AI feedback keep this ticking over during design preparation.
The system design round, from SDE-2 upward, is a separate evaluation. The System Design Sheet is free to browse, and how much system design is enough for SDE-1 vs SDE-2 is a sensible calibration point. Low-level design vs high-level design is worth reading if the boundary between the two design rounds is unclear.
The techno-managerial round wants project depth: what you owned, what broke, what you would change.
For the full loop in one place, see Flipkart interview questions and process.
A two-week plan
Week 1 — design vocabulary. Object-oriented design patterns and the class-design idioms this round assumes. Implement two problems end to end with no time limit, focusing entirely on structure. Read the editorials and compare against your own decisions. Design patterns for interviews covers the ground; the free Low Level Design Sheet fills the gaps.
Week 2 — speed. A 90-minute clock, one problem per session, running code by the end, no exceptions. Alternate problems you have seen with problems you have not. Finish each session by writing down what another half hour would have bought you — the same muscle the final five minutes of the real round uses.
💡 Pro Tip: Practise by hand, without an AI assistant. The round is timed and unassisted; practice that does not match those constraints builds false confidence.
What good structure looks like in practice
Abstract advice about "clean design" is hard to act on, so here is the concrete shape a strong ninety-minute submission tends to have — using an inventory or cart-style problem as the example, since those recur.
Entities that own their own rules. An item knows its price and whether it can be discounted. A cart knows what it contains and what it totals. Neither is a bag of fields that some service reaches into and manipulates, because that is the design that turns every new requirement into an edit in four places.
One seam where the requirements obviously branch. In a cart problem it is almost always pricing or discounting: percentage off, buy-one-get-one, flat reduction, tiered by quantity. An interface with two or three implementations, selected at runtime, is the single highest-value structural decision available in the round — and the answer to "how would you add a new offer type?" becomes one class.
A service layer that coordinates rather than computes. Thin. It moves things between entities and returns results; it does not contain the business rules.
No premature persistence. An in-memory collection behind a small repository-shaped interface, if you want the seam. Nothing more.
A driver that reads like a story. Add two items, apply an offer, print the total, remove an item, print again. Someone glancing at it should understand the system without reading the classes.
Then the extension, out loud. "If a new offer type arrived, I would add one implementation here and nothing else changes." Say it, even if unprompted. It is the exact thing the round is measuring, and stating it removes any doubt that you designed for it deliberately rather than by accident.
Frequently asked questions
How long is Flipkart's machine coding round? Ninety minutes is the commonly reported duration. Confirm with your recruiter, as it varies by level and role.
What is it graded on? Object-oriented design quality, alongside working code. Correct output is necessary but not sufficient — a clean domain model and well-placed abstractions are what distinguish a strong submission.
Which language should I use? Whichever you are fastest in. Java appears most often in reported accounts, but fluency matters more than the choice.
Do I need a database? No. In-memory state is expected, and adding persistence usually costs time without earning marks.
Should I write tests? Write enough to demonstrate the system working — a driver exercising the main flows is typically sufficient. Comprehensive unit tests are a bonus, not a requirement.
Does Flipkart still ask data structures and algorithms questions? Yes. The online assessment and a live data structures round both come before the machine coding round, and both are real gates.
Is there a system design round? For SDE-2 and above, yes, as a separate stage from machine coding.
How much does the machine coding round count? It is described across candidate accounts as the most significant and most discussed round in Flipkart's loop.
Start practising
The machine coding round asks for a specific, trainable skill: clean, working, extensible object-oriented code produced from a blank file in ninety minutes. Reading about it builds very little of that. Doing it on a clock builds all of it.
Open Flipkart's interview kit to work through the nine low-level design problems evidenced at Flipkart, each with an editorial and AI-evaluated practice. Pair it with an LLD mock interview, and browse the free Low Level Design Sheet as you find gaps.
Interview formats change. Confirm timings and round structure with your recruiter, and check Flipkart's careers site for current openings.