Running an LLD Round

The 35–45 minute flow

LLD interviews grade process, not just the final diagram. A repeatable structure keeps you from jumping to code or over-designing.

Phase	Time	Output
Clarify requirements	5 min	Functional + non-functional list, out-of-scope
Identify entities	5 min	Nouns → classes, verbs → methods
Define public API	5–8 min	Key method signatures on the core facade
Class relationships	8–10 min	Boxes, arrows, cardinality (1:N, M:N)
Deep-dive one use case	10–12 min	Trace happy path through objects
Extensions & trade-offs	5 min	"What if we add X?" + what you'd defer

Requirements clarification checklist

Ask about: actors (user, admin, system), scale (single machine vs distributed — usually out of scope), concurrency (thread-safe or single-threaded?), persistence (in-memory OK?), failure modes (what happens on invalid input?). Write answers visibly — interviewers use them as rubric anchors.

Entity identification heuristics

Nouns often become classes; adjectives often become enums or strategies; verbs become methods. Resist one-class-per-noun: Ticket and ParkingSpot are classes; "parking" is a method on ParkingLot. Look for join entities in M:N relationships (Loan connects Member and BookItem).

When to start coding

Start coding only after API + core relationships are agreed — typically minute 20–25. Implement the happy path of one method, not the full system. Pseudocode or real syntax both work; narrate invariants as you write.

Senior-level signal

Narrate your thinking: "Before I draw classes, let me confirm we're in-memory and single-threaded — that simplifies the rate limiter." Pause after the API sketch and ask: "Does this surface match what you had in mind?" Driving the conversation is scored as strongly as correctness.

Where this goes next

Trade-offs, Extensibility & Communication covers how to discuss YAGNI, compare designs, and narrate decisions — the senior differentiator after the diagram is drawn.