Ninety minutes. "Build Snake and Ladder. Any language, any IDE, working demo at the end." The interviewer leaves the call. You, a person who has solved 400 LeetCode problems, spend the first 25 minutes building a configurable input parser nobody asked for — and demo a game that crashes when the snake and the ladder share a square.
That's the machine coding round — the most India-specific, most preparable, and most failed round in product-company hiring. Popularized by Flipkart and now standard at Swiggy, Zomato, Uber India, Razorpay, Cred, Navi and most Bangalore product companies, it tests something LeetCode never does: can you turn a fuzzy problem into clean, working, extensible code — alone, under a clock.
What is a machine coding round?
A machine coding round gives you a small product problem and 90–120 minutes to build a working application on your own machine — no frameworks, no database, usually no UI; in-memory storage and console or test-driven output are expected. It's low-level design (LLD) expressed as real code instead of UML. After time's up, you demo the working flows and defend your design in a review discussion: why these classes, what breaks at scale, how you'd add feature X.
Machine coding vs the DSA round
Candidates fail machine coding by preparing for the wrong exam. The DSA round asks for one optimal algorithm in 40 minutes — the skill is pattern recognition and complexity analysis. The machine coding round rarely needs anything beyond a hashmap and a list; the skill is decomposition — carving a problem into entities and responsibilities that won't collapse when the requirement changes at minute 70. A 2,500-rating competitive programmer can absolutely ship a single 300-line main() and get rejected. The evaluator isn't asking "is this clever?" — they're asking "would I approve this pull request?"
Common machine coding round questions
The classics rotate, but this list covers most real rounds:
- Snake & Ladder / Ludo / Chess (moves only) — board games test entity modeling and turn management.
- Parking lot — the canonical LLD problem: floors, spot types, tickets, pricing strategies.
- Splitwise — expense sharing with equal/exact/percent splits and balance simplification.
- In-memory cache — get/put with TTL and eviction (LRU/LFU) — the one that does need a data-structure insight.
- Task planner / Trello board — CRUD, assignment, state transitions, filtering.
- Food ordering / cab booking lite — restaurants, inventory, matching, order lifecycle.
- Ride-sharing / inventory management — Flipkart and Swiggy favourites, often with a "now add surge pricing" twist mid-round.
What evaluators actually score
Nearly every company's rubric reduces to five things:
- A working demo. Non-negotiable. Two working features beat five broken ones — every time.
- Separation of concerns. Models, services, and a thin driver — not one god class named
Manager. - Extensibility. The reviewer will ask "how would you add a new spot type / split type / eviction policy?" If the answer is "change six files," you've lost the round.
- Naming and readability. They read your code cold.
t1andflag2read as contempt. - No over-engineering. No database, no Spring, no abstract factory for two subclasses. Restraint is a senior signal.
Here's the shape they want to see — small classes with one job each:
class ParkingLot:
def __init__(self, floors, spots_per_floor):
self.floors = [Floor(i, spots_per_floor) for i in range(floors)]
def park(self, vehicle):
# strategy lives in Floor, so new spot types don't touch this class
for floor in self.floors:
spot = floor.first_free(vehicle.size)
if spot:
return Ticket(vehicle, spot)
raise LotFullError(vehicle)The 90-minute execution plan
The round is lost in the first ten minutes far more often than the last ten. Budget it like this:
- 0–10: requirements. Write down the must-have flows. Ask which features are mandatory — interviewers answer this.
- 10–20: design on paper. Entities, relationships, and the two or three interfaces where requirements will likely change.
- 20–65: core happy path. Build and run the main flows end to end. Commit-style checkpoints: always be one save away from something demoable.
- 65–80: edge cases + the twist. Validations, error handling, and headroom for the mid-round requirement change.
- 80–90: demo prep. A tiny driver script that shows every working feature in sequence. Rehearse the run once.
How to practice (and where LeetCode falls short)
LeetCode and HackerRank train exactly the wrong reflex here — minimal code, fastest path, zero structure. For machine coding, practice differently: pick problems from the list above and build them in honest 90-minute sittings, then read Flipkart-style problem sets on workat.tech or GitHub's awesome-low-level-design collections. Avoid the classic coding interview mistakes — over-engineering early and demoing late are the two killers.
Then practice the half everyone skips: the review discussion. I froze in exactly this spot once — working code on screen, and no coherent answer to "why is this a separate class?" Building the thing and defending the thing are different skills. Ari, the AI interviewer behind Greenroom, runs the spoken design-review grilling — why this entity, what breaks at 10x, how you'd extend it — with follow-ups and blunt feedback, so the demo conversation at Swiggy or Zomato isn't your first rep.
Frequently asked questions
What is a machine coding round?
A machine coding round is an interview round where you get a small product problem — like Snake & Ladder, a parking lot or Splitwise — and 90–120 minutes to build a working application on your own machine, followed by a design review discussion. It tests low-level design, code structure and extensibility rather than algorithms, and is standard at Flipkart, Swiggy, Zomato, Uber India, Razorpay and most Indian product companies.
How long is a machine coding round?
Typically 90 minutes to 2 hours of solo coding, followed by a 20–45 minute review discussion where you demo the working features and defend your design decisions. Some companies split it: coding as a take-home or on-site block, review as a separate interview.
What questions are asked in Flipkart's machine coding round?
Commonly reported Flipkart machine coding problems include Snake & Ladder, parking lot, Splitwise-style expense sharing, in-memory cache with eviction, ride-sharing, and inventory or order-management systems — often with a requirement change introduced mid-round to test extensibility. The expectation is a working demo with clean, reviewable code, not a UI or database.
What is the difference between machine coding and DSA rounds?
A DSA round asks for one optimal algorithm to a well-defined problem in about 40 minutes — the skill is pattern recognition and complexity. A machine coding round gives a fuzzy product problem and 90+ minutes — the skill is decomposition: modeling entities, separating concerns and keeping the code extensible. Machine coding rarely needs more than hashmaps and lists; it's judged like a code review, not a contest.
Which language should I use in a machine coding round?
The one you can structure fastest in — most candidates use Java, Python or C++, and companies almost never mandate a language. Java's class-first style maps naturally to LLD; Python is faster to write but makes it easier to slip into unstructured code. Choose whichever lets you produce clean classes and a running demo, and practice in that one language only.
Is the machine coding round eliminatory?
Yes — at most companies it's the make-or-break round of the loop. A non-working demo is usually an automatic rejection regardless of code quality, and clean working code with a weak design-review discussion also fails. Prioritize a working happy path first, then structure, then edge cases.