Why scope before you design
Almost every LLD prompt is handed to you deliberately incomplete — "design a parking lot system"
is a sentence, not a specification. Candidates who start sketching classes immediately usually end
up solving a different problem than the one the interviewer had in mind, or spend their limited
time designing for edge cases nobody asked about.
The fix is a short, structured scoping conversation before any class gets written down. This
lesson gives you a repeatable set of questions to run through.
A repeatable scoping checklist
1. Who are the actors?
Who or what interacts with the system? For a parking lot: drivers, parking attendants, and
possibly a payment system. Naming actors early often reveals classes you'd otherwise miss.
2. What are the core actions?
List the two or three actions the system must obviously support, in plain language, before
worrying about how. For a parking lot: a vehicle enters, a vehicle is assigned a spot, a vehicle
exits and pays.
3. What varies, and what's fixed?
Ask specifically what's expected to change. Multiple vehicle types (motorcycle, car, bus)?
Multiple pricing strategies (hourly vs. flat rate)? These signal where an abstraction earns its
keep — this is the same "what varies" question from the first lesson in this module, applied
deliberately during scoping rather than discovered by accident mid-design.
4. What's explicitly out of scope?
State what you're not designing, out loud. "I'll assume payment processing itself is handled by
an external system I just call into" is a completely reasonable scoping decision — as long as you
say it.
5. What are the constraints?
Are there numeric constraints (a fixed number of spots per level)? Concurrency concerns (two
vehicles claiming the same spot at once)? Constraints often change which design is "correct" for
this particular version of the problem.
Functional requirements vs. non-goals
A useful habit: write two short lists before designing anything.
- Functional requirements — the concrete behaviours the system must support, in a sentence
each. E.g. "A vehicle can be assigned the nearest available spot for its type." - Non-goals — behaviours you are deliberately not handling in this version. E.g. "Reservations
ahead of arrival are out of scope."
This isn't busywork — it gives the interviewer a chance to correct your scope before you spend
ten minutes designing something they didn't want, and it gives you a concrete list to design
against instead of an open-ended prompt.
A common trap
Don't over-scope in the other direction either. Spending five of your fifteen minutes asking
questions about requirements that don't materially change the design is its own mistake. Ask
enough to design confidently, then move.
Worked example: a vending machine
Applying the checklist to "design a vending machine":
- Actors: a customer, a restocker.
- Core actions: select an item, insert payment, dispense the item, return change.
- What varies: payment method (cash, card), inventory per slot.
- Out of scope (for a first pass): refund flows, multi-currency support.
- Constraints: each slot holds one product type with a limited quantity.
From here, the functional requirements list writes itself: "a customer can select a slot," "the
machine rejects selection if the slot is empty," "the machine calculates and returns change." Each
of those becomes a method on a class before you've drawn a single box.
Key takeaways
Key takeaways
- Scoping is not a formality — skipping it is one of the most common reasons a candidate designs the wrong system.
- Run through actors, core actions, what varies, non-goals and constraints before drafting a single class.
- Writing down non-goals explicitly protects you from over-designing and gives the interviewer a chance to redirect you early.
Further reading
Further reading
- Introduction to Low-Level Design — Revisit for how scoped requirements turn into classes.
- Module 2, Object-Oriented Foundations, continues once it publishes.