Requirement Gathering & Clarifying Questions

Why you must never code a vague prompt

"Design a parking lot" silently hides a dozen forks. Are there different spot sizes for motorcycles, cars, and trucks? Can one vehicle span several spots? Do we charge by the hour? Is there one entrance or many? Each fork leads to a different class model. If you pick answers in your head and start coding, you are gambling that your private assumptions match the interviewer's hidden ones — and when they don't, you've built the wrong system and have to unwind it under time pressure. Asking up front is cheaper than rewriting later, every single time.

The categories of clarifying questions

Strong candidates don't ask questions at random — they sweep through a mental checklist of categories so nothing important is missed. The six that matter most for LLD:

• Functional scope — what must the system actually do? "Should it handle payments, or just allocate spots?" These answers become your core features and methods.
• Actors & use cases — who uses it and how? A driver, an attendant, an admin, a billing system — each actor implies entry points and permissions.
• Scale & volume — how big? How many spots, how many entrances, peak cars per hour? Scale decides whether a simple list is fine or you need indexed lookup.
• Constraints & assumptions — what's fixed or out of bounds? "Assume one physical lot, no multi-site." These trim the design surface.
• Edge cases — what happens at the boundaries? Lot full, vehicle too large for any free spot, lost ticket, double-entry. Naming these shows design maturity.
• Non-functional — qualities, not features: concurrency (two cars at two gates at once), persistence (does state survive a restart?), and — interview-specific — the time budget for the discussion itself.

State your assumptions out loud and get buy-in

You won't get an answer to every question, and you shouldn't try — that stalls the conversation. The senior move is to state an assumption explicitly and ask for confirmation: "I'll assume a single physical lot with three spot types — motorcycle, car, truck — and that one vehicle takes exactly one spot. Sound right?" This does three things: it keeps you moving, it makes your reasoning visible, and it hands the interviewer a clean moment to correct you before it's baked into code. Silent assumptions are a trap; spoken assumptions are a skill.

Bound the scope — in scope vs. out of scope

Equally important to deciding what you will build is declaring what you won't. Writing down an explicit in scope / out of scope / future work split protects you from sprawl and signals discipline. A written requirements block at the start of an LLD answer might look like:

=== ParkingLot — agreed requirements ===
IN SCOPE
  - Single physical lot, multiple floors
  - Spot types: motorcycle / car / truck
  - One vehicle occupies exactly one spot (no oversized spanning)
  - Park & unpark; find the nearest free spot of the right type
  - Charge by time on exit (hourly rate per spot type)

OUT OF SCOPE  (mention, then defer)
  - Multi-site / franchise network
  - Reservations & loyalty pricing
  - Real-time license-plate recognition

ASSUMPTIONS  (stated, awaiting buy-in)
  - At most a few thousand spots -> in-memory structures are fine
  - Single-process for now; concurrency handled with simple locking

Notice how much design is already implied: "find the nearest free spot of the right type" hints at a findSpot(VehicleType) method; "charge by time on exit" hints at a Ticket with an entry timestamp and a pricing strategy. The spec is the skeleton the classes hang on.

The interview-specific angle

Treat the first 3–5 minutes as a dedicated requirements phase, not optional small talk. Interviewers explicitly score whether you clarify before designing — jumping straight to classes is one of the most common ways strong coders fail LLD rounds. Lead with functional scope and a couple of sharp scale questions, write the answers down where you both can see them, confirm your assumptions, and only then start modeling. The written spec also becomes your anchor: when you're deep in code and start to drift, you glance back at it.

When to spend time clarifying

Run a deliberate requirements phase whenever the prompt is open-ended — which, in an LLD or system-design interview, is always. "Design X" with no further detail is a signal to clarify, not to code. The same applies on the job: a one-line ticket ("add export to the dashboard"), a feature kicked off from a hallway conversation, or any task where you find yourself guessing at intent. The fuzzier the brief and the higher the cost of building the wrong thing, the more the first few minutes of questions pay off.

When to stop and start building

Clarifying has diminishing returns. Once you have the functional scope, the key actors, a rough sense of scale, the hard constraints, and a written in-scope/out-of-scope line — stop. Confirm your assumptions, then start modeling. Chasing every remaining edge case before writing any code is its own failure mode: you run out of time with a perfect spec and no design. Lock the questions that change the shape of the solution; defer the rest as out of scope and revisit only if they bite.