Low-Level Design (LLD) Interview Prep

Low-level design (LLD) interview questions test whether you can take an ambiguous prompt ("design a parking lot", "design a cab-booking system") and produce a clean class diagram in 30 minutes — using OOP correctly, identifying entities and relationships, applying the right design patterns, and writing code that compiles. This page covers the LLD prompts that recur most often, with the classes, the patterns used, and the Java code skeletons.

LLD = take a fuzzy prompt, produce a clean class diagram in 30 minutes:

• Identify entities — nouns in the prompt.
• Define behaviours — verbs become methods.
• Apply patterns — Strategy / State / Factory / Observer where intent matches.
• Code skeleton — interfaces first, classes second, tests if time permits.
• Concurrency — declare it: which methods are thread-safe and how.

The interview surface for this module breaks into these focus areas:

• Elevator system — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Lld fundamentals — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Parking lot — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Splitwise — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Vending machine — drill the named patterns, the failure modes, and the recommended Java / framework idiom.

• Encapsulation — make state private; expose intentionally.
• Open-closed — new behaviour by extension, not modification.
• Avoid premature interfaces — extract one when you have ≥ 2 implementations.
• Mutability — default to immutable; opt into mutability with reason.
• Don't model the database — model the domain.

"Entities: . Relationships: . The behaviour split is ; I'd apply for . Concurrency: and the data is ."

Design patterns interview questions test whether you can apply the Gang-of-Four classics to real Java code — Singleton (and why it is a smell), Factory and Abstract Factory, Builder (with the Java records angle), Strategy, Observer, Decorator, Adapter, Proxy, and the patterns Spring itself uses (Template Method, IoC, AOP). Each answer leads with the problem the pattern solves, the Java implementation, and the trade-offs (when not to use it).

Three families — name the family before the pattern.

• Creational — Factory, Abstract Factory, Builder, Singleton, Prototype.
• Structural — Adapter, Decorator, Facade, Proxy, Composite, Bridge, Flyweight.
• Behavioural — Strategy, Observer, Template Method, Command, State, Iterator, Chain of Responsibility.

Spring uses many by default — DI ≈ inversion-of-control, AOP ≈ proxy, JdbcTemplate ≈ template method.

The interview surface for this module breaks into these focus areas:

• Behavioral patterns — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Comparisons — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Creational patterns — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Design patterns legacy — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Refactoring — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Solid principles — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Structural patterns — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Technical debt — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Scenario-based — applied questions tying multiple topics together. Drill these last, after the fundamentals are sharp.

• Singleton is a smell when global state lurks — prefer DI scope.
• Strategy vs State — same shape, different intent: strategy is interchangeable, state is contextual.
• Builder for records — modern Java needs less of it.
• Composition is the meta-pattern — most patterns are composition in disguise.
• Anti-patterns count too — God object, anaemic domain, magic numbers.

"This problem is a classic from the family — it gives me . The trade-off is , and I'd skip the pattern when ."