Machine Coding Round

The machine coding round is a 60-90 minute live coding exercise where you design and implement a small system from scratch. Unlike DSA rounds that test algorithmic thinking, this round tests whether you can write production-quality object-oriented code under time pressure.

Why this matters: Most product companies (Flipkart, Uber, Swiggy, PhonePe, Atlassian) use this round as a primary filter. Candidates who clear DSA rounds often fail here because writing clean, extensible code is a fundamentally different skill than solving LeetCode problems.

Prerequisites

• SOLID Principles – the grading rubric directly evaluates these
• Class Design Approach – your first 5 minutes

How It Differs from DSA Rounds

What You’re Building

Typical problems ask you to build a simplified version of a real system:

• Parking Lot management
• Splitwise expense sharing
• Elevator system
• Vending machine
• Snake and Ladder game
• Task scheduler
• Rate limiter

The problem statement is intentionally under-specified. You’re expected to ask clarifying questions and make reasonable assumptions.

The Grading Rubric

Interviewers typically score on these axes (though they won’t tell you this):

flowchart LR
    A["Working Code<br/>40%"]:::client
    B["Design Quality<br/>30%"]:::service
    C["Extensibility<br/>20%"]:::data
    D["Code Hygiene<br/>10%"]:::client

    A --> B
    B --> C
    C --> D

    classDef client fill:#4c3a5e,stroke:#818cf8,color:#e2e8f0
    classDef service fill:#1a3a2a,stroke:#4ade80,color:#e2e8f0
    classDef data fill:#3b3520,stroke:#fbbf24,color:#e2e8f0

Working Code (40%) – Does the core flow actually run? Can you demo it? Partial implementations that compile and handle the happy path score better than ambitious designs that don’t run.

Design Quality (30%) – Are responsibilities cleanly separated? Are you using appropriate patterns? Is there a clear separation between models, services, and orchestration?

Extensibility (20%) – If the interviewer says “now add X,” how much code do you need to change? A good design means adding a new feature touches 1-2 files, not 10.

Code Hygiene (10%) – Naming conventions, no magic numbers, proper access modifiers, small methods. This is the easiest 10% to earn.

The 90-Minute Breakdown

This is a battle-tested time allocation:

The cardinal sin: Spending 30 minutes on design without writing any code. Interviewers want to see working software. A mediocre design that runs beats an elegant design that doesn’t compile.

What Gets You Rejected

These are the patterns that consistently fail candidates:

1. The God Class One class with 500 lines that does everything. No separation of concerns.

2. Primitive Obsession Using String type = "CAR" instead of an enum. Using int[] instead of a proper model.

3. No Interfaces Everything is concrete. When the interviewer asks “what if we add a new type,” you’re rewriting half the code.

4. Logic in Main The main method contains business logic instead of just orchestrating calls to services.

5. Not Running the Code You wrote 400 lines but never compiled or ran it. The demo doesn’t work.

Project Structure That Works

Keep it simple. You don’t need Spring Boot or dependency injection frameworks.

src/
  models/        # Entities, enums, value objects
  service/       # Business logic (one service per responsibility)
  strategy/      # If you use Strategy pattern
  exception/     # Custom exceptions (2-3 max)
  Main.java      # Driver that demos the system

The Extensibility Test

After you finish, the interviewer will often ask: “What if we need to support X?” Good answers:

• “I’d add a new implementation of this interface” (new class, no existing code changes)
• “I’d add a new strategy here” (plug into existing framework)
• “I’d extend this enum and add a case in the factory”

Bad answers:

• “I’d add another if-else block in this method”
• “I’d modify the existing class to handle both cases”
• “I’d copy this class and change the parts that differ”

Common Mistakes in the First 5 Minutes

1. Not asking about scale – “How many concurrent users?” determines whether you need thread safety
2. Not asking about persistence – Most machine coding rounds are in-memory only. Don’t waste time on DB schemas
3. Not asking about input format – “Will I get API calls, or should I read from stdin?”
4. Jumping to code – Without identifying at least your core 3-4 entities, you’ll refactor heavily mid-round

Sample Clarifying Questions

Good questions for any machine coding problem:

• “Is this in-memory only, or should I persist to a database?”
• “Should I handle concurrent access, or is single-threaded fine?”
• “What’s the input mechanism – method calls, API, or stdin?”
• “Which features are must-have vs nice-to-have if time runs short?”
• “Should I write unit tests, or is a working demo sufficient?”

Demo Strategy

Your demo should tell a story. Don’t just call random methods – show a realistic flow:

public class Main {
    public static void main(String[] args) {
        // Setup
        ParkingLot lot = new ParkingLot(3, 10); // 3 floors, 10 slots each
        
        // Happy path: park vehicles
        Vehicle car1 = new Vehicle("KA-01-1234", VehicleType.CAR);
        Ticket t1 = lot.park(car1);
        System.out.println("Parked: " + t1); // Floor 1, Slot 1
        
        // Park more to show allocation strategy
        Vehicle bike = new Vehicle("KA-02-5678", VehicleType.BIKE);
        Ticket t2 = lot.park(bike);
        System.out.println("Parked: " + t2); // Floor 1, Slot 2
        
        // Unpark and show billing
        Receipt r1 = lot.unpark(t1);
        System.out.println("Receipt: " + r1); // Shows duration + cost
        
        // Edge case: lot full
        // ... fill remaining slots ...
        try {
            lot.park(new Vehicle("KA-03-0000", VehicleType.CAR));
        } catch (ParkingFullException e) {
            System.out.println("Handled: " + e.getMessage());
        }
    }
}

def main():
    # Setup
    lot = ParkingLot(floors=3, slots_per_floor=10)
    
    # Happy path
    car1 = Vehicle("KA-01-1234", VehicleType.CAR)
    t1 = lot.park(car1)
    print(f"Parked: {t1}")  # Floor 1, Slot 1
    
    # Show allocation
    bike = Vehicle("KA-02-5678", VehicleType.BIKE)
    t2 = lot.park(bike)
    print(f"Parked: {t2}")
    
    # Unpark and billing
    r1 = lot.unpark(t1)
    print(f"Receipt: {r1}")  # Duration + cost
    
    # Edge case: lot full
    try:
        lot.park(Vehicle("KA-03-0000", VehicleType.CAR))
    except ParkingFullError as e:
        print(f"Handled: {e}")

if __name__ == "__main__":
    main()

#include <iostream>
#include <memory>

int main() {
    // Setup
    ParkingLot lot(3, 10); // 3 floors, 10 slots each
    
    // Happy path
    auto car1 = std::make_shared<Vehicle>("KA-01-1234", VehicleType::CAR);
    auto t1 = lot.park(car1);
    std::cout << "Parked: " << t1->toString() << std::endl;
    
    // Show allocation
    auto bike = std::make_shared<Vehicle>("KA-02-5678", VehicleType::BIKE);
    auto t2 = lot.park(bike);
    std::cout << "Parked: " << t2->toString() << std::endl;
    
    // Unpark and billing
    auto r1 = lot.unpark(t1);
    std::cout << "Receipt: " << r1->toString() << std::endl;
    
    // Edge case: lot full
    try {
        auto overflow = std::make_shared<Vehicle>("KA-03-0000", VehicleType::CAR);
        lot.park(overflow);
    } catch (const ParkingFullException& e) {
        std::cout << "Handled: " << e.what() << std::endl;
    }
    return 0;
}

When to Use vs When to Avoid (Patterns in Machine Coding)

Interview Questions

1. “Walk me through your design decisions.” – Explain why you separated concerns the way you did. Mention which SOLID principles you applied and where.

2. “How would you add feature X?” – Show that your design is open for extension. Point to the interface or abstract class that would get a new implementation.

3. “What would you do differently with more time?” – Mention thread safety, input validation, logging, or breaking a large service into smaller ones. Shows self-awareness.

4. “Why didn’t you use pattern Y?” – Have a reason. “I considered it, but for only two variants, the added abstraction wasn’t worth it yet” is a valid answer.

5. “How would this scale to handle concurrent users?” – Discuss synchronization points, where locks would go, and which data structures would need to be thread-safe.

See It in Action