Why this matters: the parking lot is the canonical machine-coding opener, and most candidates lose their first points before writing a single class — not because they can't design, but because they design the wrong lot. The prompt is thin on purpose. Noticing that, and converting the thinness into a requirements conversation, is the first thing being graded.

The prompt, as given

Here is the whole thing:

Design the software for a parking lot.

Vehicles arrive, park, and leave. The lot's operator wants software that decides where each vehicle goes, tracks what's parked where, and charges drivers on the way out.

Three sentences. No vehicle types, no layout, no pricing scheme, no definition of "full." An interviewer who hands you this is not being lazy — they have a detailed picture of the lot in their head, and they are waiting to see whether you go get it.

The wrong move is to start typing class ParkingLot. The right move is to spend the first several minutes asking questions — out loud, in an order that shows you know which answers will shape the design.

The questions, and why each one matters

A requirements conversation isn't a checklist recital. Each question below earns its place because the answer changes the code you're about to write. That's the test for whether a question is worth asking: if any answer would leave your design unchanged, skip it.

"What kinds of vehicles, and what kinds of spots?" This is the shape of your core model. One vehicle type means no fit logic at all; several sizes mean a fit rule. And the follow-up matters more than the first answer: can a small vehicle take a big spot? Whatever the interviewer says about size compatibility will sit at the center of your assignment logic, so you want it pinned before you model anything.

"How is the lot laid out — floors? sections?" Not because you'll model concrete floors in loving detail, but because layout determines whether "find a spot" is a lookup or a search, and whether "nearest" means anything.

"How many entry and exit points?" One gate means arrivals are naturally one-at-a-time. Multiple gates raise concurrent-assignment questions. You're not asking so you can build a distributed system — you're asking so you can say out loud which assumption you're designing under. Interviewers reward candidates who name their assumptions; they punish candidates who silently hold them.

"How does pricing work?" Flat fee, hourly, by vehicle, by spot? The specific scheme matters less than what it implies structurally: pricing is the requirement most likely to change in real life, so wherever it lives in your design, it should be easy to point at. Asking about rounding (partial hours?) signals you've thought about money before.

"What happens when the lot is full?" Every real system needs a refusal path. Asking about it up front means your entry flow will have one, instead of an unhandled case an interviewer can poke at later.

"What's out of scope?" Payments processing? Lost tickets? Persistence? A strong candidate volunteers boundaries rather than modeling the universe. Interviewers routinely say "out of scope, but tell me where it would live" — and having a seam ready for that answer is itself a design signal.

The requirement set this chapter builds against

For the rest of this chapter, we'll converge on a representative set of answers — the kind a real interviewer gives when you ask the questions above:

Vehicles      motorcycles, cars, small trucks
Spots         small, medium, large
Fit rule      a vehicle may take a LARGER spot than it needs,
              never a smaller one
Layout        4 floors, each a mix of spot sizes
Gates         one entry, one exit (single-gated today)
Assignment    nearest available spot to the entry gate,
              smallest size that fits
Pricing       flat hourly rate keyed to the SPOT size occupied;
              partial hours round up
Full lot      entry refused with a clear signal; no queue
Out of scope  payments processing, persistence, lost tickets

Two things about this table are worth internalizing.

First, notice how much design is already latent in it. The fit rule ("larger is fine, smaller never") will become one comparison in one place. "Nearest, smallest that fits" is a policy — the kind of thing operators change their minds about, which will push us toward isolating it. Pricing keyed to spot size is begging to be a table, not an if ladder.

Second — and this is the part that matters for your actual interview — a live interviewer's answers may differ from this set. Maybe their lot has valet-only zones, or per-vehicle pricing, or two gates from the start. The skill this lesson teaches is the conversation, not this particular outcome. If you've practiced asking the right questions for the right reasons, a different answer sheet just means a slightly different design — arrived at the same way.