Low-Level Design and Machine Coding Round: A Practical Guide

Machine coding and low-level design (LLD) rounds ask for something DSA practice doesn't: well-structured code for a small real system. They're common at Indian product companies (see what Flipkart, Razorpay and Swiggy ask) and appear in global loops for earlier-career roles.

What interviewers grade

• Requirements handling: did you ask before building?
• Modeling: are entities and relationships sensible?
• Extensibility: can a new rule or type be added without rewrites?
• Correctness: does it run on the provided cases?
• Code quality: naming, separation of concerns, no god classes.
• Edge cases and tests.

A time-boxed workflow (90 minutes)

Worked example: parking lot

Requirements to confirm: multiple floors? vehicle types? pricing by hour? entry/exit tickets? concurrency?

Entities: ParkingLot, Floor, Slot, Vehicle (Car, Bike, Truck), Ticket, PricingStrategy.

class Vehicle:
    def __init__(self, plate, kind): self.plate, self.kind = plate, kind
 
class Slot:
    def __init__(self, sid, kind): self.sid, self.kind, self.vehicle = sid, kind, None
    def is_free(self): return self.vehicle is None
 
class PricingStrategy:
    def fee(self, hours): raise NotImplementedError
 
class HourlyPricing(PricingStrategy):
    def __init__(self, rate): self.rate = rate
    def fee(self, hours): return max(1, hours) * self.rate
 
class ParkingLot:
    def __init__(self, floors, pricing): self.floors, self.pricing, self.tickets = floors, pricing, {}
    def park(self, vehicle):
        for slots in self.floors:
            for s in slots:
                if s.is_free() and s.kind == vehicle.kind:
                    s.vehicle = vehicle
                    self.tickets[vehicle.plate] = s
                    return s.sid
        raise RuntimeError("no slot available")
    def leave(self, plate, hours):
        s = self.tickets.pop(plate)
        s.vehicle = None
        return self.pricing.fee(hours)

The PricingStrategy is the extension point: weekend pricing or per-vehicle rates arrive without touching ParkingLot. State that out loud.

Frequently asked problems

Parking lot, elevator system, library management, tic-tac-toe, chess, splitwise, ATM, vending machine, BookMyShow, rate limiter, LRU cache, logging framework, notification service.

Principles to apply

• Single responsibility: a class has one reason to change.
• Open/closed: extend via new classes, not edits.
• Composition over inheritance for varying behavior.
• Depend on interfaces at extension points.

Mistakes that lose points

• Starting to code before requirements
• One 400-line class
• Patterns without a need (a Factory for one type)
• No way to run it
• Ignoring invalid input (unknown vehicle, double exit)

Common design patterns, and when they earn their place

Use a pattern only when you can name the extension it makes easy. Patterns with no extension story look like over-engineering.

A second worked example: expense splitter

Requirements: users add expenses, split equally or by exact amounts or percentages, and see balances.

Entities: User, Expense, Split (Equal, Exact, Percent), BalanceSheet.

The extension point is the split type. Model it as an interface with a method that returns each participant's share, and validate in one place that shares sum to the total. Adding a new split type then needs one new class. State this aloud and show how a new type plugs in.

Concurrency and thread safety

Interviewers sometimes ask what changes with concurrent requests. Mention: shared mutable state, locks or atomic operations around critical sections (like assigning the last free slot), and idempotent operations. Even if you do not implement it, showing you know where the risk lies earns credit.

Testing in the round

You rarely have time for a full test suite, but a small harness shows professionalism:

• A main method that runs three or four scenarios
• A handful of assertions on edge cases
• Clear output so the reviewer can see behaviour at a glance

How reviewers read your code

Reviewers skim first. Make that skim easy:

• Meaningful names for classes and methods
• Small methods with one purpose
• Constants instead of magic numbers
• A short README or top-of-file comment on structure and assumptions

A 6-week practice plan

Time yourself. After each mock, ask: could I add a new rule without editing existing classes?

Related reading

• System design interview cheat sheet
• 12 common system design interview questions
• How to crack a DSA coding round