Every LLD prompt is deliberately under-specified. The interviewer wants to see whether you'll define the box before you fill it. Skipping this step is the single most common reason candidates build the wrong design and run out of time.
The four buckets to always cover
Ask questions from each of these buckets; you rarely need more than five or six total.
1. Scope and core use cases
- What are the must-have operations versus nice-to-haves?
- Who are the actors? (For a parking lot: drivers, attendants, admins.)
- What's explicitly out of scope? (Payments? Persistence? Auth?)
2. Entities and their dimensions
- What types/variants exist? (Spot sizes, vehicle types, payment methods.)
- What are the cardinalities? (One floor → many spots; one lot → many gates.)
- Are there limits? (Max capacity, max items.)
3. Non-functional requirements
- Concurrency — will multiple actors hit shared state at once? (Two cars, one spot.)
- Scale — in-memory single process, or distributed? (Usually in-memory for LLD.)
- Extensibility — which dimensions are expected to grow? (New pricing schemes, new channels.)
4. Constraints and conventions
- Should the code compile and run, or is a class diagram enough?
- Any specific patterns or APIs the interviewer wants to see?
A reusable checklist
SCOPE core ops? actors? out of scope? TYPES variants? cardinalities? limits? NFRs concurrency? scale? extensibility? FORMAT compilable code or diagram? required patterns?
The payoff
Each answer prunes the design space. "No persistence" removes repositories and DTOs. "Concurrent gates" forces you to think about thread-safety from the start instead of bolting it on. "Pluggable pricing" tells you Strategy will earn its place.