What LLD interviews actually test

Why it matters

Candidates who know every pattern still fail low-level design rounds, usually for one of three reasons: they start drawing before they know the requirements, they produce a large diagram nobody can follow, or they freeze when the interviewer adds a twist. The round is scored on process and judgement as much as on the final design. Knowing the rubric lets you spend your 45 minutes on what is actually measured.

The idea

A low-level design round gives you a loosely specified problem ("design a parking lot", "design a library system") and watches how you turn it into a clear object model. Most interviewers score the same handful of dimensions.

A 45-minute plan

1. 1

   Clarify (about 5 minutes)

   Who are the users, what are the core use cases, what is explicitly out of scope? For a parking lot: multiple floors? vehicle sizes? payment at exit or entry? reservations? Write the agreed list where the interviewer can see it.
2. 2

   Find the entities and their responsibilities (about 10 minutes)

   Underline the nouns in the requirements for candidate classes and the verbs for behaviour. Keep the classes that own a rule or a lifecycle; fold the rest into attributes. Say each class's responsibility in one sentence.
3. 3

   Draw the relationships (about 10 minutes)

   A compact class diagram: the core classes, key fields and methods, and the relationships, choosing composition by default, interfaces where behaviour varies, inheritance only for genuine subtypes.
4. 4

   Walk the main flows (about 10 minutes)

   Trace one or two use cases through the objects: who calls whom, where each rule is checked, what happens on failure. A sequence diagram or plain narration both work.
5. 5

   Absorb a change and cover edge cases (about 10 minutes)

   The interviewer will add a requirement (electric vehicle charging, a new pricing rule, concurrency). Show the change lands in one place. Mention concurrency, invalid input and failure where they matter.

Mistakes that sink strong candidates

• Designing the whole world. Twenty classes for a parking lot signals an inability to prioritise. Model the core well and list extensions you would add later.
• Pattern-first thinking. Naming patterns before there is a problem for them to solve. Introduce a strategy when you meet a varying rule, not before.
• Anaemic models. Classes that are only fields with getters and setters, with all logic in a giant manager or service class. Put rules with the data they protect.
• Ignoring state. Bookings, orders, elevators and machines have lifecycles. Not modelling states and legal transitions is the most common gap in otherwise good answers.
• No concurrency story. Two users booking the last seat is the canonical twist. Say where the lock or transaction goes.
• Silence. Interviewers cannot score reasoning they do not hear. Narrate choices and trade-offs as you make them.

Trade-offs

There is tension between breadth and depth: covering every feature superficially loses to modelling the core deeply and naming the rest. There is also tension between extensibility and simplicity: designing hooks for every imaginable change produces abstraction nobody needs. The best answers state these trade-offs explicitly ("I am keeping pricing as a strategy because the interviewer hinted it changes; I am not abstracting vehicle types further until there is a reason").

In an interview

Open with the plan so the interviewer can steer: "I will spend a few minutes on requirements, then identify the main entities and their responsibilities, draw the class relationships, walk through parking and exit, and then we can stress the design with changes." It signals structure and invites the interviewer to redirect you early.