Machine Coding and Low-Level Design for Freshers

The interviewer says: "Design a parking lot. You have 90 minutes. I'd like working code at the end." Students who have only practised problem-solving tend to freeze. There is no single right answer, no hidden test cases and no constraint table. There are only questions: what kinds of vehicles? what sizes of spots? how is the fee calculated? what happens when the lot is full?

That openness is the point of the round. It simulates the actual job: take a loosely described need, ask the right questions, structure the code sensibly and deliver something that works. It is also very learnable, because the same handful of habits applies to every problem.

• What machine coding and low-level design rounds are, and how they are evaluated.
• A time-boxed approach from vague requirements to working code.
• The design principles that matter most at entry level.
• A complete small example, with its trade-offs.
• Common follow-up questions on extensibility and concurrency.
• How to practise, including with AI.

Names differ: "machine coding", "low-level design" (LLD), "object-oriented design", "pair programming round". The common shape:

• A problem described in a few sentences, from a familiar domain: a parking lot, an elevator, a library, a cab booking service, a food ordering system, a splitwise-style expense sharer, a rate limiter, a snake-and-ladder game, a hotel booking system.
• 60 to 120 minutes.
• Working code in your chosen language, sometimes on your own machine with your own editor, sometimes in a shared editor.
• A discussion at the end, and often during.

Some companies want a full runnable program with a small demo; others care more about the class design and interfaces. Ask at the start: "Would you like a runnable demo, or is the class design and core logic the priority?"

A design with three well-built classes that work beats an ambitious design with twelve classes and nothing running.

For a parking lot, questions might be:

• What vehicle types and spot sizes? Can a small vehicle use a larger spot?
• One floor or many? One entrance or several?
• How is the fee calculated: per hour, per started hour, flat?
• What happens when there is no suitable spot?
• Do we need payment, reservations, multiple lots? (Usually: out of scope for now.)

Write the answers as a short list in a comment at the top of your file. It shows structure and keeps you honest about scope.

Nouns in the requirements usually become classes; verbs become methods. For the parking lot: Spot, Vehicle (or just a plate and a size), Ticket, ParkingLot, and a pricing rule. Write their key fields and public methods before any logic.

Make "park a car, then unpark it and get a fee" work end to end, simply, before handling anything fancy. This is the brute-force-first habit from assessments, applied to design.

Then add: the lot is full; the same car parks twice; unparking a car that is not there. Finally, a short driver or a few tests that show the behaviour.

You do not need to recite every design principle. A few make the most difference:

• Single responsibility. Each class has one job. The parking lot assigns spots; the pricing rule calculates fees. When requirements change, one class changes.
• Composition over inheritance. Give a class a pricing object rather than creating HourlyParkingLot and FlatRateParkingLot subclasses.
• Program to interfaces. Depend on "something that can calculate a fee", not on one specific pricing class, so a new rule can be swapped in.
• Patterns only when they remove a real problem. A strategy for pricing makes sense, because pricing varies. A factory, a singleton and an observer added "because LLD rounds want patterns" make the code harder to follow. Interviewers notice pattern-stuffing.
• Validate at the boundary. Check inputs where they enter (parking an already-parked car) and fail with a clear error.

For a clear, free explanation of common design patterns with examples, refactoring.guru is widely used.

Assumptions written at the start: three spot sizes (small for bikes, medium for cars, large for buses); a vehicle may use a spot of its size or larger; the first free suitable spot is used, smallest first; the fee is charged per started hour by vehicle size; payment, floors and reservations are out of scope.

The program below is written in Python for brevity; in an interview, use the language you are most fluent in. It needs Python 3.10 or later.

# File: parking_lot.py# A small machine-coding answer: a parking lot with spot sizes, tickets and# a pluggable pricing rule. Times are minutes since opening, so runs repeat exactly.import mathfrom dataclasses import dataclassfrom enum import Enumclass Size(Enum):    SMALL = 1   # bikes    MEDIUM = 2  # cars    LARGE = 3   # buses@dataclassclass Spot:    spot_id: str    size: Size    plate: str | None = None@dataclassclass Ticket:    ticket_id: int    plate: str    vehicle_size: Size    spot_id: str    entry_minute: intclass HourlyPricing:    """Charge per started hour, by vehicle size. Swap in another class to change pricing."""    RATES = {Size.SMALL: 10, Size.MEDIUM: 30, Size.LARGE: 60}  # rupees per hour    def fee(self, size, minutes):        return max(1, math.ceil(minutes / 60)) * self.RATES[size]class ParkingLot:    def __init__(self, spots, pricing):        self.spots = sorted(spots, key=lambda s: s.size.value)  # smallest first        self.pricing = pricing        self.active = {}  # plate -> Ticket        self.next_id = 1    def park(self, plate, size, minute):        if plate in self.active:            raise ValueError(f"{plate} is already parked")        for spot in self.spots:  # first free spot that is big enough            if spot.plate is None and spot.size.value >= size.value:                spot.plate = plate                ticket = Ticket(self.next_id, plate, size, spot.spot_id, minute)                self.next_id += 1                self.active[plate] = ticket                return ticket        return None  # lot full for this size    def unpark(self, plate, minute):        if plate not in self.active:            raise ValueError(f"{plate} is not parked here")        ticket = self.active.pop(plate)        spot = next(s for s in self.spots if s.spot_id == ticket.spot_id)        spot.plate = None        return self.pricing.fee(ticket.vehicle_size, minute - ticket.entry_minute)lot = ParkingLot([Spot("L1", Size.LARGE), Spot("M1", Size.MEDIUM),                  Spot("S1", Size.SMALL), Spot("M2", Size.MEDIUM)], HourlyPricing())for plate, size, minute in [("KA01-BIKE", Size.SMALL, 0), ("KA02", Size.MEDIUM, 5),                            ("KA03", Size.MEDIUM, 10), ("KA04", Size.MEDIUM, 12),                            ("KA05", Size.MEDIUM, 15)]:    t = lot.park(plate, size, minute)    print(f"park {plate:<9} -> {t.spot_id if t else 'FULL'}")try:    lot.park("KA02", Size.MEDIUM, 20)except ValueError as e:    print("error:", e)print("unpark KA01-BIKE after 61 min, fee:", lot.unpark("KA01-BIKE", 61))print("unpark KA03 after 90 min, fee:", lot.unpark("KA03", 100))print("park KA05 again ->", lot.park("KA05", Size.MEDIUM, 101).spot_id)

park KA01-BIKE -> S1park KA02      -> M1park KA03      -> M2park KA04      -> L1park KA05      -> FULLerror: KA02 is already parkedunpark KA01-BIKE after 61 min, fee: 20unpark KA03 after 90 min, fee: 60park KA05 again -> M2

What to notice, and what you would say in the interview:

• Responsibilities are separated. ParkingLot assigns and frees spots; HourlyPricing calculates fees. A weekend rate or a flat-rate pricing rule is a new class with a fee method, passed to the lot, with no change to ParkingLot.
• The fee uses the vehicle's size, not the spot's. The car KA04 parked in a large spot because medium ones were full; charging it the bus rate would be unfair. That was a decision, and worth saying aloud.
• Edge cases fail clearly: a car already parked, a car not parked, a full lot (park returns None).
• The search is a simple loop. It is O(number of spots) per park. Fine for a few hundred spots; for a large lot you might keep a separate queue of free spots per size. Mentioning this, without building it, shows judgement.

Interviewers often extend the problem to see how your design copes:

You do not have to build every follow-up. Explaining how your design would accommodate it is often what is wanted.

Pick six to eight classic problems and build each one in 90 minutes, timed, in your interview language: parking lot, library management, expense sharing, elevator, snake and ladder, a rate limiter, a hotel booking system, a food ordering flow. Then compare your design with a well-regarded reference implementation, and write down one thing to do differently.

You can ask an assistant to play the interviewer, including using your company research notes (article 27) to choose a problem in the company's domain:

Act as an interviewer running a 90-minute machine coding round for an entry-levelengineer. Use a problem from [the company's domain, from my notes: e.g. payouts,delivery tracking]. Rules:- Give the problem in 3 or 4 sentences, deliberately leaving some things unclear.- Answer my clarifying questions briefly, as a product owner would.- When I share a class or method, ask ONE question about a design choice:  "why this over that?", "what if we need to add X?", or "what if two users do this  at the same time?"- Do not write code for me.- At the end, give a verdict on requirements, modelling, working code, edge cases,  readability and extensibility, and the single biggest improvement.

Then build in your own editor, sharing classes as you go. The questions train the explaining that the real round requires.

• No clarifying questions, then building the wrong thing.
• Designing twelve classes and running out of time with nothing working.
• One giant class that does everything.
• Inheritance where composition fits (a subclass for every variation).
• Adding patterns to look sophisticated.
• Ignoring concurrency when asked, or not knowing what "atomic" means.

• Next: System Design for Freshers: What SDE-1 Interviews Expect zooms out from classes to services.
• For object-oriented foundations in Java, see Interfaces, Polymorphism and Composition and Classes, Objects and Encapsulation.
• For testing your design's code, see Testing with JUnit and Mockito: Unit Tests, Mocks and Their Limits.