The LLD Interview Framework
You'll learn to
- -Apply a repeatable process: clarify requirements, identify actors and use cases, design classes and relationships, apply patterns, then discuss trade-offs
- -Recognize the most common failure modes - over-engineering, premature pattern use, and ignoring concurrency or edge cases
Every strong LLD answer follows roughly the same five-step shape, whether the prompt is "design a parking lot" or "design an elevator system." Having a framework does not make the answer formulaic - it frees up your working memory to think about the actual problem instead of the process, which is exactly what a 45-minute clock demands.
The Five Steps
- -Clarify requirements: what are the functional requirements (what must the system do), and what are the constraints (scale, concurrency, extensibility)? Write them down visibly.
- -Identify actors and use cases: who or what interacts with the system, and what are the 3-5 core actions they take?
- -Design classes and relationships: nouns become classes, verbs become methods, and you decide association vs. aggregation vs. composition vs. inheritance for each relationship.
- -Apply patterns where they earn their cost: a pattern should solve a concrete problem in your design, not be added to demonstrate you know its name.
- -Discuss trade-offs and extensions: what would change if a new requirement showed up? Where are the seams in your design that make that change cheap?
The Failure Modes That Actually Sink Candidates
Over-engineering is the most common one: reaching for Factory, Strategy, and Observer in the first five minutes on a problem that does not need any of them yet, because the requirements have not surfaced a reason. The second is ignoring concurrency - many classic LLD prompts (parking lot spot assignment, movie seat booking, rate limiters) are secretly concurrency problems, and a design that never mentions thread-safety has missed half the point. The third is treating the class diagram as the finish line instead of the midpoint - interviewers almost always follow up with "now add X," and a design that cannot absorb that follow-up without a rewrite has failed the actual test, even if the original diagram looked clean.
Do not introduce a design pattern before the requirement that justifies it exists. "I'll use Strategy here" is a red flag on its own - "I'll use Strategy here because we need to swap pricing rules at runtime without touching the booking class" is the same code with the reasoning that actually matters.
You finish your class diagram for a vending machine with 10 minutes left. The interviewer asks: "What if we now need to support promotional discounts?"
"I'd add an if-statement in the checkout method that checks for a discount code and reduces the price."
"I'd introduce a DiscountStrategy interface with implementations like PercentageDiscount and FixedAmountDiscount, and have the machine hold a reference to the active strategy. That keeps the checkout logic unchanged and means new discount types never require touching existing code - which is exactly the kind of extension this design should already be built for."
In the five-step LLD framework, what comes immediately after clarifying requirements?