LLD Interview Problems
The problem
Knowing SOLID and design patterns individually doesn't automatically mean you can design a coherent class structure for an open-ended, ambiguous prompt under time pressure — that requires practiced synthesis, deciding which principles and patterns actually apply to a specific set of requirements instead of forcing all of them in.
Why now
This is the domain's capstone: every prior topic — OOP basics, inheritance, SOLID, all three pattern categories, and diagramming — is a tool, and this topic is where those tools get applied together against realistic, open-ended problems, which is the only way to find out whether they were actually understood or just memorized individually.
Mental model
An LLD problem is graded on process, not a single correct answer: clarify requirements and scope first, identify the core entities and their relationships, apply SOLID to keep responsibilities clean, reach for a specific design pattern only when it solves a real requirement in front of you (not to show it off), and be ready to extend the design when the interviewer adds a new requirement mid-conversation.
Requires
- Creational Design PatternsLow-Level Design
A realistic LLD design needs a deliberate strategy for object construction; you need the creational patterns already available as tools before applying them appropriately within a larger design.
- Structural Design PatternsLow-Level Design
Composing existing pieces into a coherent system is a core part of any nontrivial LLD problem; you need these patterns already available before recognizing when a design calls for one.
- Behavioral Design PatternsLow-Level Design
Coordinating object behavior and state transitions is central to most classic LLD problems (elevators, vending machines); you need these patterns already available as the vocabulary for expressing that coordination cleanly.
- UML & Class DiagramsLow-Level Design
Communicating and iterating on an LLD design in an interview setting relies on being able to sketch it quickly; you need that communication tool already fluent before using it under time pressure.
Used in
- Senior and staff-level software engineering interviews at most major tech companies
- Real system design work, where 'design a class structure for X' is a routine, not just an interview exercise
- Classic practice problems: parking lot, elevator system, vending machine, library management, tic-tac-toe, rate limiter as a class
- Evaluating whether a design will survive a realistic follow-up requirement change
Projects
- Design a parking lot system from scratch: entities, relationships, SOLID-compliant class structure, and at least one design pattern applied where it genuinely fits — then extend it to support multiple vehicle types and dynamic pricing
- Design an elevator control system handling multiple elevators and requests, explicitly using the State pattern for elevator state and Strategy for the dispatch algorithm
Examples
- A parking lot design naturally uses Strategy for pricing (hourly vs. daily) and Factory for creating the right ParkingSpot subtype for a given vehicle
- An elevator system's State pattern (Idle, Moving, DoorsOpen) makes adding a new state (Maintenance) an Open/Closed-compliant addition instead of a rewrite of a giant conditional
Resources
Mastery checklist
- I can take an ambiguous LLD prompt, clarify scope, and identify the core entities before writing any code
- I can produce a SOLID-compliant class design and justify each design pattern I include
- I can sketch the design as a class diagram and explain it clearly to another person
- I can extend an existing design cleanly when a new requirement is introduced mid-design