Platforms
Where to practise LLD interviews
Short answer
Start with prompts and diagrams to learn the vocabulary of low-level design, then make repository-based practice your default before the interview. A class diagram can be reviewed quickly; a repository forces you to prove that interfaces, state transitions, and tests work together.
Written and reviewed by Sahil Srivastav
What each one actually is
Prompt and diagram practice asks you to model a domain, name responsibilities, and explain relationships. It is efficient for learning how to structure an answer.
Repository-based LLD practice adds interfaces, existing code, tests, and failure paths. It reveals whether the model can survive real method contracts and state changes.
The best sequence is concept, diagram, implementation, review. Stopping after diagrams leaves the most important LLD question unanswered: where does the invariant live and how is it tested?
Side by side
| Repository-based LLD practice | Diagram and prompt practice | |
|---|---|---|
| Primary output | Working model and tests | Diagram and verbal explanation |
| Feedback | Compiler, tests, and runtime behaviour | Reviewer or model-answer critique |
| State detail | Concrete transitions and persistence | Usually described at a higher level |
| Iteration | Refactor after observing coupling | Revise the design on paper |
| Best use | Final rehearsal for machine coding | Learn domain modelling and patterns |
| Time | Deeper sessions | Fast scenario coverage |
| Failure exposed | Leaky interfaces and missed edge cases | Missing actors or unclear responsibilities |
| Assessment match | Code-oriented LLD round | Design discussion or whiteboard round |
Choose Repository-based LLD practice when
- The interview includes code or a starter repository
- You struggle to turn a diagram into testable interfaces
- The domain has meaningful state transitions and failure paths
- You want to practise explaining a change while implementing it
Choose Diagram and prompt practice when
- You are learning LLD notation and basic modelling
- The interview is discussion-only
- You need breadth across many domains quickly
- You want to compare alternative designs before coding one
The trade-off in detail
Diagrams make coupling visible early, while code makes accidental coupling painful enough to fix. Use both: model the responsibilities, implement one flow, then revise the model based on what the tests and interfaces reveal.
Patterns should follow a repeated design pressure. A strategy interface is useful when behaviour varies and callers should remain stable; adding it to every class because a catalogue recommends it makes the design harder to change.
A repository exercise should not reward framework ceremony. The useful LLD signal is a clear contract, a small dependency surface, explicit state ownership, and tests for the invariant.
Things that are commonly said and are wrong
- “LLD practice means memorising design patterns.” Patterns are vocabulary; responsibility and change are the design.
- “A diagram is enough for a machine coding round.” The interviewer can ask you to implement it, where hidden coupling appears.
- “Repository practice must be a large project.” A small, bounded domain with executable tests gives better feedback than an unscoped application.
FAQ
Where should a beginner start?
Use short domain prompts to learn actors, responsibilities, and state. Then implement one small repository scenario so the model becomes concrete.
How should I review an LLD solution?
Ask where each invariant is enforced, what changes when a new variant appears, how dependencies are substituted in tests, and what happens on invalid or repeated input.
Is UML required?
No. A clear class or module sketch is enough if it communicates ownership and collaboration. The notation matters less than the behaviour and trade-offs.