---
title: Machine Coding Round: How to Prepare (Flipkart & More)
description: What a machine coding round is, the questions Flipkart-style rounds ask (Snake & Ladder, parking lot, Splitwise), what evaluators score + a 90-minute plan.
url: https://usegreenroom.app/blog/machine-coding-round
last_updated: 2026-07-12
---

← Back to blog

Coding Interviews

# Machine coding round: what it is and how to prepare

July 12, 2026 · 9 min read

![Machine coding round preparation guide — cover from Greenroom, the AI mock interviewer](/assets/blog/machine-coding-round-hero.webp)

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](/blog/flipkart-interview-questions) 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](/blog/big-o-notation-time-complexity-interview-questions). 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. `t1` and `flag2` read 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.
    

![The 90-minute machine coding round execution plan, minute by minute](/assets/blog/machine-coding-round-diagram.webp)

*The 90-minute split that ships a working demo — most candidates lose the round in the first ten minutes.*

    
> **The core truth:** the machine coding round is a code-review simulation, not an algorithm exam. The demo gets you considered; the design discussion afterwards — spoken, defended, out loud — gets you hired.

    
## 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](/blog/common-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](/blog/swiggy-interview-questions) or [Zomato](/blog/zomato-interview-questions) 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.

The code gets you to the review; explaining the design out loud gets you the offer. Greenroom runs spoken mock design-review interviews with follow-ups on your actual reasoning. Free to start. Preparing for a specific company? See our Flipkart interview questions guide.