🧭
LLD Fundamentals

LLD Interview Roadmap

45 Minute Mein Kya Kya Karna Hai
💡 LLD interview EK GHAR KA NAKSHA banane jaisa hai, ghar banane jaisa NAHI. Interviewer ye nahi dekhta ki tumne kitni deewarein khadi kar di — wo dekhta hai ki tumne kamre THEEK JAGAH rakhe, darwaze SAHI DISHA mein khole, aur naya kamra jodna aasaan chhoda.

LLD round mein 45 minute hote hain aur unka baantwara FIXED hona chahiye: 5-8 minute REQUIREMENTS clarify karne mein, 5 minute CORE ENTITIES nikalne mein, 10 minute CLASS DIAGRAM aur relationships mein, 15 minute CODE likhne mein, aur 5 minute EXTENSIONS discuss karne mein. Jo log seedhe code likhna shuru kar dete hain wo yahin fail hote hain.

Requirements clarify karna OPTIONAL nahi hai. "Parking lot design karo" ek ADHOORA sawaal hai — kitne floors? kaunse vehicle types? payment hourly hai ya slab-based? Ye sawaal poochna tumhe SENIOR dikhata hai, confused nahi. Assumptions bolkar likh do, phir unhi par design khada karo.

// Har LLD problem ka same skeleton hota hai:

// 1. Requirements  -> functional + non-functional, likhkar
// 2. Entities      -> noun nikaalo: Vehicle, Slot, Ticket, Floor
// 3. Relationships -> kaun kisko OWN karta hai, kaun kisko USE karta hai
// 4. Interfaces    -> jahan behaviour BADAL sakta hai wahan abstraction
// 5. Code          -> enums -> models -> services -> orchestrator
// 6. Extensions    -> "agar electric vehicle add karna ho to?"
🧭
LLD interview EK GHAR KA NAKSHA banane jaisa hai, ghar banane jaisa NAHI. Interviewer ye nahi dekhta ki tumne kitni deewarein khadi kar di — wo dekhta hai ki tumne kamre THEEK JAGAH rakhe, darwaze SAHI DISHA mein khole, aur naya kamra jodna aasaan chhoda.
1 / 2
⚡ Quick Recap
  • 45 minute ka fixed baantwara rakho — requirements, entities, diagram, code, extensions
  • Requirements clarify karna seniority ka signal hai, time waste nahi
  • Har problem ka skeleton same hai: noun nikaalo, relationship jodo, behaviour ko interface do
Is page mein (2 subtopics)

Har LLD problem mein yahi 6 sawaal kaam aate hain: SCALE kitna hai (10 users ya 10 lakh), kaunse ACTORS hain (user, admin, system), kya CONCURRENCY expect karni hai, PERSISTENCE chahiye ya in-memory chalega, kaunse EDGE CASES matter karte hain, aur kya EXTENSIONS aage aa sakte hain.

Ye sawaal poochne mein 5 minute lagte hain aur baaki 40 minute bacha lete hain, kyunki tumhara design ek FIXED target par bana hota hai. Bina poochhe design karne waale log 20 minute baad "actually main ye bhool gaya" bolte hain.

💡Tip: Interviewer ka jawab likh lo aur bolo — "to main maan raha hoon ki ye in-memory hai aur single machine par chal raha hai." Assumption bolna galat nahi hai; chhupa kar rakhna galat hai.

Problem statement ko padhkar NOUN underline karo — wo tumhaari CLASSES hain. VERB underline karo — wo tumhaare METHODS hain. "User books a ticket for a show" mein User, Ticket, Show classes hain aur book() method hai.

Iske baad har noun se poocho: iski STATE kya hai (fields) aur iska BEHAVIOUR kya hai (methods). Agar kisi class mein sirf fields hain aur koi behaviour nahi, to shayad wo alag class banne layak nahi thi — ya phir uska behaviour galti se kisi service mein chala gaya hai.

// "A user books a ticket for a show in a theatre"
//   Nouns -> User, Ticket, Show, Theatre     => classes
//   Verbs -> book                            => method

class BookingService {
  Ticket book(User user, Show show, List<Seat> seats) { ... }
}