Machine Coding Round: The Complete Interview Preparation Guide
Machine Coding Round: The Complete Interview Preparation Guide
You walk into the interview room. The interviewer hands you a problem statement — maybe two pages long — and says: “Design and implement a working solution. You have 90 minutes. Go.”
No hints. Minimal interaction. Just you, your IDE, and a clock.
This is the machine coding round — the interview format that tests what no other round can: your ability to take a real-world problem and produce clean, working, extensible code under time pressure.
What is a Machine Coding Round?
A machine coding round gives you a design problem (like “Design a Parking Lot” or “Build a Splitwise-like expense splitter”) and expects you to produce fully functional, well-structured code in 60-120 minutes. After you submit, there’s a code review where you walk through your design decisions with the interviewer.
If you’re interviewing at companies like Flipkart, Uber, Swiggy, Cred, Razorpay, PhonePe, or dozens of other top Indian and global tech companies, this round is likely standing between you and an offer. Let’s make sure you’re ready.
How Machine Coding Differs from Other Interview Types
This is the first thing people get wrong — they prepare for the wrong format. Here’s how machine coding compares to other interview types:
Machine Coding Round
- Duration: 60-120 minutes (typically 90)
- Deliverable: Working, runnable code
- Interaction: Minimal — you work independently
- Tools: Your IDE (IntelliJ, VS Code, etc.)
- After: Code review with interviewers
- Focus: Clean code, design patterns, extensibility
- Data storage: In-memory (HashMaps, Lists — no databases)
OOD / Whiteboard Round
- Duration: 45-60 minutes
- Deliverable: Class diagrams, pseudocode, method signatures
- Interaction: High — continuous discussion with interviewer
- Tools: Whiteboard or virtual canvas
- After: Discussion continues throughout
- Focus: Design thinking, trade-offs, communication
- Data storage: Not applicable (conceptual design)
The critical difference: machine coding requires working code, not just design. You can’t hand-wave past implementation details. If your code doesn’t compile and run, you’ve failed regardless of how beautiful your class diagram is.
The Most Common Confusion
Many candidates prepare for machine coding by practicing system design (HLD) — drawing architecture diagrams with load balancers and databases. That’s the wrong preparation. Machine coding is about classes, objects, patterns, and working code — it’s Low Level Design in action.
Who Uses Machine Coding Rounds?
Machine coding is especially popular in the Indian tech ecosystem, but it’s spreading globally. Here are the major companies that use this format:
| Company | Typical Duration | Stage | Notes |
|---|---|---|---|
| Flipkart | 90-120 min | Round 1-2 | The pioneer of machine coding rounds |
| Uber | 90 min | Onsite | Called “design and implement” |
| Swiggy | 90 min | Round 1-2 | Expects working code with tests |
| Cred | 90 min | Round 1 | High bar for code quality |
| Razorpay | 90 min | Round 1-2 | Focus on payment/fintech domains |
| PhonePe | 90 min | Round 1 | Expects clean design patterns |
| Ola | 90 min | Round 1 | Ride-sharing domain problems |
| Groww | 60-90 min | Round 1 | Finance domain focus |
| Atlassian | 90 min | Onsite | Called “design exercise” |
| BrowserStack | 120 min | Round 1 | Expects comprehensive testing |
| Upstox | 90 min | Round 1 | Trading/finance problems |
| Dream11 | 90 min | Round 1 | Gaming domain focus |
International Companies Too
Companies like Google, Amazon, and Microsoft don’t typically call it “machine coding,” but their OOD rounds at Indian offices often follow the same format — design + implement working code.
What Interviewers Actually Evaluate
This is the part most candidates get wrong. They think the evaluation is: “Does the code work?” That’s only 20% of it.
Here’s the actual breakdown of what interviewers score:
The 5 Evaluation Criteria
What they check:
- Are classes well-defined with clear responsibilities?
- Is the project structure organized (models, services, strategies)?
- Are naming conventions consistent and meaningful?
- Is code readable without comments?
What kills your score: God classes, meaningless names like Manager or Helper, everything in one file, inconsistent formatting.
What impresses: Clear separation of concerns, each class under 50-80 lines, package/module structure that makes sense at a glance.
What they check:
- Does the core functionality work when they run it?
- Does the demo/driver code show the main flows?
- Are the primary use cases covered?
What kills your score: Code that doesn’t compile, missing core features, runtime crashes on basic scenarios.
What impresses: A clean main/driver that demonstrates all core flows, clear input/output, handling the full happy path.
What they check:
- Are SOLID principles applied naturally?
- Are appropriate design patterns used (Strategy, Factory, Observer, State)?
- Do classes depend on interfaces rather than concrete implementations?
What kills your score: One class doing everything (violates SRP), if-else chains for type switching (violates OCP), concrete dependencies everywhere (violates DIP).
What impresses: Strategy pattern for interchangeable behaviors, Factory for object creation, Observer for notifications — used where they naturally fit, not forced.
What they check: During the code review, the interviewer will ask: “What if we need to add X?” Can your design handle it without major rewrites?
What kills your score: Adding a new vehicle type requires modifying 5 existing classes. Adding a new payment method means rewriting the payment logic.
What impresses: “To add a new vehicle type, I’d create a new class implementing the Vehicle interface. Nothing else changes.” That’s the Open/Closed Principle at work.
What they check:
- What happens with invalid inputs?
- Are boundary conditions handled?
- Does the code fail gracefully or crash?
What kills your score: Null pointer exceptions on edge cases, no validation at all, silent failures that corrupt state.
What impresses: Input validation at the boundaries, meaningful error messages, graceful handling of impossible states.
The 90-Minute Framework
Time management is the difference between finishing strong and submitting half-baked code. Here’s the framework that works:
Read and Clarify (5-10 minutes)
Read the problem statement twice. Underline the nouns (they become classes) and verbs (they become methods). Write down any ambiguities. If the format allows questions, ask them now. If not, make reasonable assumptions and document them.
Design the Class Structure (10-15 minutes)
This is the most important step — and the one most candidates skip. Sketch out:
- Core entities (classes) and their attributes
- Relationships between classes
- Key interfaces for interchangeable behaviors
- Enums for fixed types and states
Don’t write code yet. Spend this time thinking. A 10-minute design saves 30 minutes of refactoring.
Implement Core Models (15-20 minutes)
Start with the data models — the entities, enums, and value objects. These are the foundation everything else builds on. Get the class hierarchy and relationships right.
Implement Business Logic (25-30 minutes)
Now build the services and strategies that operate on your models. Implement the main flows first — the happy path. Use interfaces and patterns where they naturally fit.
Write the Driver/Demo (10 minutes)
Create a main function or demo that exercises all the key flows. This is what the interviewer will run first. Make it clear, readable, and demonstrate the core functionality.
Handle Edge Cases and Polish (5-10 minutes)
If you have time left: add input validation, handle error cases, add comments to explain non-obvious design decisions. If time is tight, skip this — a working core beats a polished but incomplete solution.
The #1 Mistake: Skipping the Design Step
Most candidates jump straight into coding at minute 1. By minute 40, they realize their class structure is wrong and spend the remaining 50 minutes frantically refactoring. The candidates who spend 15 minutes designing first finish with 10 minutes to spare.
Visual: Time Allocation
The Top 10 Machine Coding Problems
These are the problems that appear most frequently across machine coding rounds. We’ve ranked them by how often they’re asked and which companies favor them.
Tier 1: Must-Practice (Asked Everywhere)
1. Parking Lot System Most Asked
The undisputed #1 machine coding question. Tests class hierarchies, strategy pattern, and state management.
Key concepts: Vehicle types (enum), spot allocation strategy, ticket generation, fee calculation Companies: Flipkart, Amazon, Uber, Google, Microsoft, Adobe What makes it tricky: Multiple vehicle types, multiple floors, different pricing strategies, concurrent entry/exit
2. Snake and Ladder Game Classic
A board game that tests turn management, random events, and game state tracking.
Key concepts: Board setup with snakes/ladders, dice rolling, player turns, win detection, special rules Companies: Amazon, Adobe, Microsoft, Flipkart, Swiggy, Zynga What makes it tricky: Configurable board (different snake/ladder positions), multiple players, edge cases (landing on snake head that leads to another snake)
3. Vending Machine State Pattern
The textbook state machine problem. Tests your ability to model states and transitions.
Key concepts: State pattern (Idle, HasMoney, Dispensing), inventory management, change calculation Companies: Google, Amazon, Microsoft, Apple, Oracle What makes it tricky: Correct state transitions, handling insufficient funds, making change with limited coin denominations
4. Online Shopping Cart Strategy Pattern
An e-commerce cart with discount strategies, pricing rules, and checkout flow.
Key concepts: Cart management, pricing strategy (percentage off, flat discount, buy-one-get-one), checkout flow Companies: Amazon, Flipkart, Walmart, eBay What makes it tricky: Multiple discount strategies that stack or conflict, cart totals that update in real-time, inventory checks during checkout
Tier 2: Frequently Asked
5. Elevator System Medium
Multi-elevator dispatching with state management and strategy pattern.
Key concepts: Elevator states, dispatch strategy, request queuing, direction management Companies: Amazon, Microsoft, Uber, Google, Adobe
6. Chess Game Medium
Complex entity modeling with piece hierarchies and move validation.
Key concepts: Piece hierarchy with polymorphic movement, board state, turn management, check/checkmate Companies: Amazon, Adobe, Facebook, Microsoft
7. Restaurant Food Ordering System Medium
Real-world multi-entity system with order lifecycle and delivery assignment.
Key concepts: Order state machine, menu management, delivery assignment strategy, real-time status Companies: Zomato, Swiggy, DoorDash, Uber Eats
8. Movie Ticket Booking System Medium
Seat allocation with concurrency concerns and booking lifecycle.
Key concepts: Show management, seat selection, booking confirmation, payment processing Companies: Amazon, BookMyShow, Paytm, Google
Tier 3: Advanced (Senior Roles)
9. Rate Limiter Hard
Algorithm-heavy with multiple strategies and concurrency.
Key concepts: Token bucket, sliding window, fixed window counter, per-client configuration Companies: Stripe, Google, Amazon, Cloudflare
10. Notification Service Hard
Multi-channel delivery with retry logic and rate limiting.
Key concepts: Template method, factory for channels, retry with backoff, per-user rate limiting Companies: Amazon, Uber, LinkedIn, Twitter
Start with Tier 1
If you have limited time, focus on Tier 1 problems first. They cover the fundamental patterns (State, Strategy, Factory, Observer) that appear in every other problem. Once you can ace Tier 1 in under 90 minutes each, move to Tier 2.
The 7 Deadly Mistakes
These are the mistakes that fail candidates most often — even those with strong coding skills.
The Complete Mistake List
The trap: “I’ll figure it out as I code.” You won’t. You’ll code yourself into a corner and spend the second half refactoring.
The fix: Spend 10-15 minutes on paper or in comments: list your classes, their responsibilities, key interfaces, and the main flow. This upfront investment pays for itself three times over.
The trap: The problem statement has 10 features. You try to implement all 10 and finish none well.
The fix: Identify the 4-5 core features. Implement those completely and cleanly. Mention the remaining features during the code review: “I’d add notification support using an Observer pattern here.” Showing you know how to extend is as valuable as implementing it.
The trap: You build all the classes but forget to write a main() that actually runs and demonstrates the system.
The fix: Always write a driver. Even if it’s simple: create a parking lot, park 3 cars, remove 1, check availability. The interviewer runs this first. If it doesn’t work, nothing else matters.
The trap: Setting up SQLite, writing SQL queries, dealing with connection issues. You burn 20 minutes on infrastructure that adds zero value.
The fix: Everything is in-memory. Use HashMap / dict for lookups, List / list for collections, Set / set for unique constraints. In-memory storage is the expected approach.
The trap: Treating the code review as a formality. Giving one-word answers. Not being able to explain your own design decisions.
The fix: The code review is 30-50% of your evaluation. Prepare to explain: “Why did you use Strategy here?”, “How would you add feature X?”, “What would you change for concurrency?” Practice articulating your design decisions out loud.
The trap: Using strings like "AVAILABLE", "OCCUPIED", "RESERVED" throughout your code. One typo and your logic silently breaks.
The fix: Define enums for every fixed set: vehicle types, spot types, booking states, payment status. Enums are type-safe, self-documenting, and prevent an entire category of bugs.
The trap: Adding fancy features like logging frameworks, custom exception hierarchies, and configuration management before the core functionality works.
The fix: Get the core working first. Only add polish if you have time left. A working MVP with clean design beats a sophisticated but broken system every time.
Project Structure That Impresses
Before you write a single line of logic, set up a clean project structure. This immediately signals to the interviewer that you think at a professional level.
Why this structure works:
- models/: Pure data classes — entities with attributes, no business logic
- services/: Business logic — the “verbs” of your system
- strategies/: Interchangeable algorithms implementing a common interface
- enums/: Type-safe constants for states, types, and categories
- main: The driver that demonstrates everything working together
The Code Review: What They’ll Ask
After the coding phase, you’ll have a 15-30 minute code review. Here are the most common questions and how to answer them:
| Question | What They’re Testing | Strong Answer |
|---|---|---|
| ”Walk me through your design” | Communication, high-level thinking | Start with entities, then services, then how they interact |
| ”Why did you use this pattern?” | Pattern awareness | Explain the problem it solves, not just name it |
| ”How would you add feature X?” | Extensibility (OCP) | “Create a new class implementing the interface — nothing else changes" |
| "What about concurrency?” | Advanced thinking | Identify where race conditions could occur, suggest locks or atomic operations |
| ”What would you test?” | Quality mindset | Name specific edge cases: empty lot, full lot, invalid vehicle type |
| ”What would you change with more time?” | Self-awareness | Honest answer about what you’d refactor, what patterns you’d add |
The Power Move
During the code review, proactively point out things you’d improve: “If I had more time, I’d add an Observer pattern here for notifications, and I’d make the fee calculator a Strategy so we could swap pricing models.” This shows you know more than you had time to implement.
Language-Specific Tips
Machine coding rounds typically let you choose your language. Here are tips for the most popular choices:
Advantages: Fastest to write, least boilerplate, great for rapid prototyping.
Key tips:
- Use
dataclassesor@dataclassfor models — saves time on__init__ - Use
ABCand@abstractmethodfor interfaces - Use
Enumfrom the standard library for type safety - Use type hints everywhere — shows professionalism
- Use
dictfor in-memory storage (it’s your database)
Watch out for: Python’s lack of true access modifiers — use _ prefix convention for protected, __ for private. Interviewers notice.
Advantages: Most mature OOP support, interviewers are very familiar with it, strong type system catches errors.
Key tips:
- Use
interfaceliberally for strategy and factory patterns - Use Java
enumwith methods for rich type definitions - Use
HashMapandArrayListfor in-memory storage - Use
Optionalfor nullable returns - Keep classes small — Java verbosity makes long classes unreadable
Watch out for: Don’t over-engineer with Spring-like patterns (dependency injection frameworks). Keep it simple with constructor injection.
Advantages: Familiar to full-stack developers, TypeScript provides type safety.
Key tips:
- Use TypeScript over JavaScript — the type system helps the interviewer and catches bugs
- Use
interfacefor contracts andabstract classfor shared behavior - Use
enumfor fixed types - Use
MapandSetfor in-memory storage - Use barrel exports (
index.ts) for clean imports
Watch out for: Avoid any type — it signals laziness. If you’re using TypeScript, use it fully.
Preparation Timeline
1-Week Crash Plan
- Day 1-2: Study SOLID principles and top 4 patterns (Strategy, State, Factory, Observer)
- Day 3: Practice Parking Lot under 90 min timer
- Day 4: Practice Vending Machine under 90 min timer
- Day 5: Practice Snake and Ladder under 90 min timer
- Day 6: Practice one Tier 2 problem of your choice
- Day 7: Review all solutions, practice code review explanations
1-Month Thorough Plan
- Week 1: OOP fundamentals, SOLID principles, key design patterns
- Week 2: Tier 1 problems — one per day, strict timer
- Week 3: Tier 2 problems — one per day, strict timer
- Week 4: Re-do weak problems, practice code reviews with a friend, attempt one Tier 3 problem
For a more structured approach, check out our 15/30/90-day study plans or the guided learning path.
A Day-of Checklist
Before you walk into the machine coding round, make sure you’ve got these covered:
Before the Round
- IDE set up with your preferred language and shortcuts
- Familiar with your language’s enum, abstract class, and interface syntax
- Know the project structure you’ll use (models, services, strategies)
- Have a mental model for the 90-minute time breakdown
- Know the top 4 design patterns and when to use each
During the Round
- Read the problem statement twice before touching code
- Spend 10-15 minutes on class design (on paper or in comments)
- Implement core models first, then services, then driver
- Don’t touch edge cases until the happy path works end-to-end
- Save 10 minutes for the driver/demo code — non-negotiable
Key Takeaways
Remember These
- Design before code: 10-15 minutes of design saves 30 minutes of refactoring
- Working code > perfect code: A clean MVP beats an incomplete masterpiece
- Project structure matters: models/, services/, strategies/ — set it up first
- In-memory storage only: HashMap/dict is your database
- Enums everywhere: For types, states, and categories — no magic strings
- The code review is half the battle: Practice explaining your design decisions out loud
- Know the top 4 patterns: Strategy, State, Factory, Observer cover 90% of problems
- Don’t implement everything: Core features done well > all features done poorly
What to Read Next
- What is Low Level Design? — Understand the design thinking behind machine coding
- SOLID Principles: A Visual Guide — The foundation of clean machine coding solutions
- OOP Concepts Every Developer Should Master — The building blocks you need
- Top 20 LLD Interview Questions — More practice problems with approach hints
- LLD Playground — Practice all 40+ problems with solutions in 6 languages and AI feedback
“Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” — Abraham Lincoln
The machine coding round rewards preparation and discipline, not just raw coding speed. Sharpen your axe — learn the patterns, practice the framework, and internalize the project structure. When the timer starts, you’ll know exactly what to do.