01 — What LLD Interviews Actually Test
An LLD interview is a 45–60 minute live conversation where you take a loosely-specified problem ("design a rate limiter"), pin down requirements, and walk the interviewer through a class-level design. You will write interfaces, sketch relationships, and talk through tradeoffs. You may write real code or pseudocode depending on the company.
What's being measured is not whether you know the "right answer" — there isn't one. It's whether you think like an engineer who can own a system: clarify scope, pick abstractions for real reasons, anticipate failure modes, and communicate the whole thing clearly under time pressure.
Why this matters more at senior levels
At SDE1 or new-grad levels, a correct solution and clean code are often enough. From SDE2 onward, interviewers are projecting forward: will this person design systems I can hand to a team? Will they defend their choices when a skeptical staff engineer pushes back? Will they see the second-order problems — concurrency, scale, failure modes — without being prompted? Every minute of the interview is signal on those questions, not just the final class diagram.
What a Good Answer Looks Like
Four things characterize a strong LLD answer. Notice none of them are "you got the design right":
- Requirements are explicit. The interviewer watches you clarify. A senior candidate asks why a requirement exists, not just what it is. "Should the system support X?" is junior. "If X is in scope, the bookkeeping cost goes up — is X valuable enough to pay that?" is senior.
- Abstractions are justified by tradeoffs, not memorized patterns. You don't say "I'll use Strategy here." You say "these two behaviors need to vary independently of the caller, so I'll inject an interface." Same thing, different framing — one sounds like a CS student, the other like a tech lead.
- The design evolves under pressure. The interviewer will ask "what if we need X?" A senior candidate treats this as welcome. You say "here's how I'd evolve the design" — you don't redo it from scratch.
- Nonfunctional concerns are volunteered, not forced. Concurrency, failure, scale, observability — these come up without the interviewer begging. Senior candidates talk about them before the code is even finished.
Common Interview Flow
Every LLD interview, whether Amazon, Google, Meta, or a series-C startup, has the same five-phase skeleton:
| Phase | Time | What you do | What they're grading |
|---|---|---|---|
| Intro / problem statement | 3 min | Read the prompt, ask the first few clarifying questions. | Do you jump to solutioning or do you clarify first? |
| Requirements | 5–10 min | Pin down scope. Surface nonfunctional requirements. Confirm out-of-scope. | Did you miss obvious edge cases? Did you trap yourself with over-scope? |
| Design | 20–30 min | Entities, interfaces, relationships, class sketch, key method bodies. | Is the model clean? Are your contracts right? Do you name things well? |
| Deep dive / follow-ups | 10–15 min | Interviewer probes: concurrency, scale, "what if we added X." | Do you evolve the design or panic? |
| Wrap | 2–3 min | Recap, acknowledge what you'd do with more time. | Self-awareness. |
The 30-minute rule: by the 30-minute mark, your class diagram should be on the board and you should be in deep-dive territory. Candidates who are still arguing with themselves about entity naming at 30 minutes run out of runway.
SDE2 vs SDE3
These are Amazon's levels, but the shape generalizes. Google L4→L5, Meta E4→E5, Microsoft 63→64 all expect a similar rise in judgment.
| Dimension | SDE2 (3–5 YOE) | SDE3 (6+ YOE) |
|---|---|---|
| Requirements | Asks standard clarifying questions. Confirms scope. | Identifies unspoken requirements. Proactively scopes down when ambiguity threatens the timebox. Pushes back on requirements that would balloon complexity. |
| Abstractions | Uses interfaces correctly. Picks reasonable patterns. | Justifies every interface with a specific pressure it absorbs. Avoids patterns when simpler code suffices. Names abstractions from the domain, not the pattern. |
| Tradeoffs | Can compare two options when asked. | Volunteers 3-way comparisons with concrete criteria (memory, throughput, cognitive cost). Flags when a tradeoff is irreversible vs. easily changed. |
| Concurrency | Recognizes there's a race condition when pointed at. | Identifies the contended resource, picks a locking strategy, and sketches the critical section without prompting. Discusses lock granularity vs throughput. |
| Scale | Knows "this won't scale" but hand-waves the fix. | Identifies the bottleneck (memory, CPU, I/O, contention), proposes a specific next step (shard, partition, cache), and acknowledges what it costs to go there. |
| Evolution | Rewrites when requirements change. | Shows the seam where the new requirement plugs in. "This is why IAssignmentStrategy is an interface — swapping to time-based assignment is a new class, not a refactor." |
| Communication | Explains what they built. | Explains why they didn't build the alternatives. |
| Failure handling | Happy path first, errors bolted on. | Error paths are part of the contract. Idempotency, retries, partial failure are discussed before the interviewer asks. |
| Follow-up response | Treats probes as challenges. | Treats probes as collaboration. "Good catch — I'd extend X by..." is the SDE3 reflex. |
The single best heuristic
If the interviewer asks "what if we need X?" and you can answer in under 30 seconds with a concrete modification (new class / interface / method) without erasing anything on the whiteboard, you are operating at senior level. If you start erasing, you weren't designing for extensibility — you were designing for today's requirements and hoping.
What They Are Not Testing
- Memorized patterns. Dropping "I'll use Visitor" into a problem that doesn't need Visitor is a negative signal.
- Language trivia. They don't care if you know every TypeScript utility type or C++ move-semantics rule.
- Textbook-perfect UML. Sketches are fine. Over-formalized UML often suggests you've been studying books instead of shipping code.
- Optimal algorithms. LLD is not DSA. An O(n) lookup inside a reasonable class is usually fine — picking the right abstraction matters more than picking the right data structure.
How to Prepare (6+ YOE)
If you have 6+ years of experience, you have designed more systems than any single LLD prompt can test. Your prep problem is not learning new design concepts — it's translating what you already do at work into interview vocabulary.
Three concrete drills:
- Pattern labeling on your own code. Pick three systems you've shipped. Name the design patterns at work, even if they weren't intentional. You'll be surprised how often you already used Strategy without calling it that.
- Clarifying-question reflex. Take 10 LLD prompts. For each, write down the first 5 questions you'd ask. The top 3 should be nonfunctional (scale, consistency, single-writer-multi-reader, etc.), not "what does the user want?"
- The 45-minute timer. Pick one problem from Section 3. Set a timer. Speak the answer out loud as if in the interview. Record yourself. Watch it back. You will hear yourself hedge, wander, skip concurrency — all the things that drop you a level.
The goal is not to study LLD. The goal is to teach your interviewer's brain to recognize the senior engineer you already are.