What is Low-Level Design (LLD) and what does an LLD interview expect you to do?

Direct Answer

Low-Level Design (LLD) is the process of designing the internal structure of a system component by defining classes, interfaces, their relationships, and interactions. In an LLD interview, you're expected to translate a problem statement (like designing a parking lot or library management system) into a working class diagram with proper object-oriented design principles, showing how objects collaborate to fulfill requirements.

Deep Dive & Architecture

LLD turns one requirement into code-level structure

High-level design chooses services, data stores, and communication boundaries. Low-level design opens one component and defines its classes, interfaces, important fields, public methods, relationships, and rules. For a parking lot, the output might include ParkingLot, ParkingFloor, ParkingSpot, Vehicle, ParkingTicket, and a pricing interface.

The interview expects a traceable process

Clarify the main use cases and constraints, identify candidate objects, assign each responsibility, draw the important relationships, and walk a normal flow such as park and unpark. Then write skeleton code for the decisions that matter and explain how the model handles an error or extension.

Patterns support the design; they are not the deliverable

A Strategy is useful when pricing rules vary, but adding one implementation for every imagined future is noise. A good answer is internally consistent: method calls match the diagram, state changes protect the rules, and every abstraction has a reason. The expected depth depends on the prompt, so confirm scope instead of assuming a fixed checklist.

Code Example

// LLD deliverable: classes, fields, signatures, relationships
abstract class Vehicle { String plate; abstract SpotSize requiredSize(); }
class Car extends Vehicle { SpotSize requiredSize() { return SpotSize.REGULAR; } }

class ParkingLot {                      // HAS-A floors (composition)
    private List<ParkingFloor> floors;
    Optional<ParkingTicket> park(Vehicle v);   // key behaviour
    BigDecimal unpark(ParkingTicket t);
}

The output is concrete classes and signatures — not boxes-and-arrows infrastructure (that's HLD).

Common Mistakes & Pitfalls

• Confusing LLD with HLD — talking load balancers and sharding when asked for classes.
• Jumping to code without clarifying — always scope the requirements first.
• Listing classes with no relationships — the connections are the design.
• Ignoring OOP principles — LLD is judged on encapsulation, SRP, and sensible patterns.