Flipkart-Style Machine Coding Round: Format, Tips & Practice Problems
Flipkart is widely credited with popularising the machine coding round in Indian product-company interviews, and rounds in this style are now the default filter for SDE1 and SDE2 backend roles across e-commerce companies. The format is simple to describe and hard to fake: you get a business problem, a fixed window, and you must hand back code that runs.
The scenarios lean heavily on e-commerce mechanics — inventory that must never oversell, coupons with stacking and eligibility rules, loyalty points that expire, returns that must refund and restock atomically. This page breaks down the commonly reported format of Flipkart-style rounds, how they are evaluated, and Gronex problems in the same style you can practise in a real repository.
What a Flipkart-style machine coding round looks like
The typical shape is 90–120 minutes, solo, on your own machine. You receive a written problem statement — often an e-commerce slice like a cart-and-coupon engine or a stock reservation flow — with a set of functional requirements and a few explicitly called-out edge cases. You are expected to produce a small, working service or module: real classes, real state, runnable end to end, usually demoed to the interviewer at the end.
Working code is the entry ticket, not the goal. Rounds in this style are famously strict about the demo: if the happy path does not run, the interview is effectively over regardless of how elegant your design was. Only after the demo does the conversation move to design — why you modelled inventory as a state machine, how a new coupon type would slot in, what breaks under concurrent purchases.
Expect a requirement to change mid-round or in the follow-up discussion: "now support percentage coupons capped at ₹200", "now a cancelled order must release its stock". Extensibility is tested live, which is why hard-coded logic that passes the initial requirements can still sink you.
How you’re evaluated
A running demo
The single biggest gate. Requirements implemented, the main flow executable, and no crash while the interviewer watches you drive it.
Entity modelling
Clean separation of orders, inventory, coupons, and payments — with state transitions that make illegal states unrepresentable rather than guarded by scattered if-checks.
Edge-case correctness
Oversell under simultaneous purchases, coupon reuse, refunds on partially shipped orders. Interviewers keep a list and probe them one by one.
Extensibility under change
When the requirement changes at minute 70, how much of your code survives? Interfaces and strategy-style seams score; switch-statements everywhere do not.
Common mistakes that fail this round
- Spending 40 minutes on a perfect class diagram and reaching the demo with nothing runnable.
- Building a REST layer and database nobody asked for — in-memory repositories are expected and accepted.
- Treating concurrency as out of scope when the problem says "many users buy simultaneously" — that sentence is the problem.
- Hard-coding the first coupon/pricing rule so the inevitable "add one more type" extension requires a rewrite.
- Skipping input validation: duplicate items in a request, negative quantities, and unknown SKUs are the first things probed.
Quick tips for the room
- Get an end-to-end skeleton running in the first 30 minutes, then iterate.
- Say your assumptions out loud and write them at the top of the README.
- Model money and stock mutations as small, atomic operations from the start.
- Keep a two-minute buffer to rehearse the demo before you present it.
How to prepare
Practise the actual loop, not just the topics: pick a scoped e-commerce problem, set a 90-minute timer, and drive it to a runnable demo with at least a few tests. The skill that separates candidates is scoping under time pressure — a complete, working core with two edge cases handled beats a half-built grand design every time.
The Gronex problems below mirror the format from the other side: each is a real backend repository with a failing test suite, so you rehearse reading existing code, fixing service logic, and making tests green — the exact muscle a Flipkart-style round grades. Start with the free ones, then use the HARD concurrency problems to pressure-test yourself.
Practice problems in the Flipkart-style round format
Each is a real backend repository with a failing test suite — the same working-code standard the round applies. Open the brief and read the full problem, no signup required.
Flash Sale Inventory Purchase System
The flash-sale oversell problem: sell exactly the stock you have when thousands of buyers race the same SKU.
Open the challenge →E-Commerce Coupon Application Engine
Coupon eligibility, stacking rules, and idempotent redemption in a checkout backend — the classic pricing-rules round.
Open the challenge →Loyalty Points and Tier Management
Coin-style loyalty mechanics: FIFO point expiry, oldest-first redemption, tier recalculation, idempotent earn events.
Open the challenge →Warranty RMA Return Authorization
Returns done right: warranty-window checks, non-skippable state transitions, and atomic refund-plus-restock.
Open the challenge →Marketplace Escrow Hold & Release
Marketplace money flow: concurrency-safe held-balance release, terminal-state guards, and ledger reconciliation.
Open the challenge →Seat Reservation System
Inventory holds as a state machine: reserve, cancel, and list availability deterministically. Free to try.
Open the challenge →FAQ
Were these problems actually asked at Flipkart?
No. Every problem here is a Gronex original built in the same style — e-commerce domains, working-code grading, edge-case-heavy specs. We never republish any company’s actual interview questions, and Gronex is not affiliated with Flipkart.
How long is a Flipkart-style machine coding round?
Commonly reported as 90–120 minutes of solo coding followed by a demo and design discussion. Practising against a hard 90-minute timer is the single most useful habit.
Do I need a database or REST API in the round?
Almost never. In-memory repositories behind an interface are the expected idiom — they keep you fast and show layering. Spending time on HTTP or persistence is one of the most common ways candidates run out of clock.
Working code or clean design — which matters more?
Working code is the gate; design is the differentiator. A running demo with a readable service layer and one clear extension seam beats an unfinished textbook architecture in virtually every rubric used for this round style.
Related
Gronex is not affiliated with, endorsed by, or sponsored by Flipkart. All company names and trademarks belong to their respective owners. The problems on this page are Gronex originals written in the style of such interview rounds — not actual interview questions from Flipkart.