The LLD Interview, Start to Finish

In one line

Put Phases 1–3 together into one repeatable 45-minute script: requirements → entities → class diagram → core code → concurrency → extensions. Use it for every problem in Phase 4.

0/7 · 0%

Think of it like this

A doctor's check-up always runs in the same order: symptoms → examination → tests → diagnosis → treatment. A fixed order means nothing important gets skipped, even under pressure.

Key ideas

01
0–5 min: requirements. List actors, 4–6 use cases, rules, edge cases, and what's out of scope. Get a nod from the interviewer.
02
5–10 min: entities and relationships. Nouns → classes, and mark ownership (composition vs association) and multiplicity (1:N).
03
10–15 min: class diagram with interfaces at the points that will change (pricing, payment, notification, storage). Name the pattern only when it fits.
04
15–35 min: code the core flow first (the 'happy path' of the main use case), then the rules, then error handling. Clean names, small methods, no God class.
05
35–40 min: concurrency. Find the shared state (spots, seats, inventory, balances) and say how you protect it (lock per object, atomic compare-and-set, or DB row lock).
06
40–45 min: extensions. 'If you add EV spots, I add one enum value and one pricing strategy; nothing else changes.' Then mention the tests you'd write.
07
Common mistakes: coding before requirements, one giant class, patterns for show, ignoring concurrency, and using double for money.

Code & diagrams

LldAnswerSkeleton.mdmarkdown

Keep this skeleton in your head. Fill in the blanks for any problem.

1. REQUIREMENTS   actors | use cases | rules | edge cases | out of scope
2. ENTITIES       Noun → class  (identity? state? behaviour?)
3. RELATIONSHIPS  A 1──N B (owns / uses)   C ◇── D (composition)
4. INTERFACES     where will it change?  → Strategy / State / Factory / Observer
5. CORE CODE      main use case, happy path first, then rules & errors
6. CONCURRENCY    shared state = ___   protected by ___   (lock / CAS / DB)
7. EXTENSIONS     "new X → one new class, zero edits to ___"
8. TESTS          3–5 test names covering rules + edge cases

Pattern cheat sheet (problem → pattern):
  different algorithms (pricing, split, matching)  → Strategy
  object behaves differently per status            → State
  create one of many types                         → Factory
  notify many parties on change                    → Observer
  undo / queue / log actions                       → Command
  third-party API with a different shape           → Adapter
  add features by wrapping                         → Decorator
  tree of items and groups                         → Composite

Explain without notes

Walk through the 8-step skeleton for 'design an elevator' out loud, spending no more than 30 seconds per step.

Practice

Pick any three Phase 4 problems. For each, do steps 1–4 on paper in 15 minutes, then compare with the Phase 4 solution.

Trade-offs

↔
Time vs completeness: a clean, working core with clear extension points beats a half-finished 'complete' design every time.

Completion checklist

I follow the same 8-step skeleton for every LLD problem without looking at notes.
I always reach the concurrency and extension steps before time runs out.

Back to phase