LLD Dojo

Designing under pressure · chapter 29 of 33

Reading a vague prompt without panicking

Chapter 4.1 · Part 4, Designing under pressure · about 30 minutes

What you need before this chapter: Parts 1 to 3 of this course. Nothing here is code. It is the skill of reading a problem before you design one, and it uses the vocabulary those parts built — classes, interfaces, and the seams chapter 3.1 called Strategy.

When you finish this chapter you will be able to:

1. The prompt you are actually given

This is corpus/parking-lot's opening prompt, word for word, the same one lesson F1 hands you:

"Design the software for a parking lot at a shopping mall. Vehicles arrive, they park somewhere, and they pay on the way out. Not every vehicle is the same size, and the rates aren't the same for all of them either. I'd like to see it run at the end."

Read it again and count what it actually tells you. Vehicles arrive, they park, and they pay when they leave. Sizes differ, and so do rates. It has to run at the end. Five facts, in four sentences, and every one of them is true of almost any parking lot on earth. That is what an ambiguous prompt looks like: short, plausible, and silent about the exact things a working design needs answered.

2. What is stated, and what is only implied

Go through the prompt phrase by phrase and ask, for each one, whether it is a fact or a door left open.

"They park somewhere" is a fact that a vehicle ends up occupying space, and a door on exactly how much space. A motorbike and a truck are both vehicles. Does a truck take one spot or two? The prompt never says. "Not every vehicle is the same size" all but forces the question, but it never answers it.

"The rates aren't the same for all of them either" is a fact that pricing depends on vehicle type, and a door on everything about how that pricing actually works. Is the fee charged per minute, or rounded up to a whole hour? Is a truck occupying two spots charged twice, once per spot, or once for the vehicle regardless of how many spots it used? Nothing in the prompt rules any of these out.

"They pay on the way out" sounds like it settles the timing of payment. It does, but it also opens a question the prompt never touches: what happens to a ticket once it has been used. Can the same ticket be presented twice at the exit? A driver who lost a ticket and photocopies the old one is trying exactly that, and a design that never asked has no answer ready.

This is the actual shape of an ambiguous prompt. It names the problem in ordinary words, and it leaves every convention that would decide the design unstated. Closing that gap, on purpose, before you write a line of code, is the whole skill this chapter teaches.

3. From nouns to four lists

Read the prompt once more, this time hunting nouns instead of gaps: vehicle, spot, ticket, rate, lot, driver. Each noun is a candidate for something your design has to represent, and sorting them into four buckets is how a vague paragraph turns into a specification you can defend.

corpus/parking-lot/problem.json calls the whole bundle must_haves, and it has four parts:

Write all three of the first lists down before you touch a keyword like class or interface. A design built straight from a paragraph, with no list in between, tends to model whatever noun the author happened to type first rather than the noun the problem actually needs.

4. A question that changes the design, and one that does not

Once your three lists exist, gaps in them turn into questions, and not every question you can think of is worth asking out loud. corpus/parking-lot/problem.json ships twelve real clarifying questions for this exact prompt. Here are three of them:

"How many spots does each vehicle type need, and do a truck's spots have to be adjacent?" "Which way does the fee round — is one minute already a full hour?" "Are the rates per vehicle or per spot occupied?"

Each one decides something structural. The first decides how allocation works at all — a single-spot allocator cannot answer a requirement it was never told existed. The second decides the shape of the timer logic your fee calculation needs. The third decides whether a truck quietly gets charged twice.

Compare that against a question like "should I use an ArrayList or a HashMap for the spots?" That question has an answer, and the answer might even matter for performance later, but it changes nothing about what the design has to do. It only changes how the thing you already decided gets built. A question like that has no place on your clarifying list. Asking it spends clock time to learn something the interviewer cannot answer for you anyway, because that decision was always yours.

The test, stated plainly: if two different answers to your question would produce two different class designs, ask it. If every answer leaves your classes exactly as they were, it belongs in your own head, not in front of the interviewer.

5. What skipping one actually costs

Say you skip the question about truck spots and simply assume every vehicle takes one. You design an allocator on that assumption, write it, test it, and every test passes — because your own test data never included a truck occupying two spots. The design looks finished.

corpus/parking-lot/curveballs/01-motorbikes-share-a-spot is a recorded curveball for this exact problem: mid-round, the rule changes to let two motorbikes share one standard spot. Say your allocator was already told, even roughly, that "how many spots does a vehicle type need" has more than one possible answer. Absorbing the change then costs a handful of lines in one class. Say instead it was never told, and the one-spot assumption is buried inside a loop that has long since forgotten it was ever an assumption. The same change now means finding every place that loop's shape leaked out, and reworking each one, under the same clock that was already running. The ten seconds a good clarifying question costs at minute two is not a nicety. It is the cheapest insurance available against a change that lands at minute twenty-five.

6. When you are actually done

You are done extracting once you have written down the three lists from section 3, plus the fourth one the next chapter covers. Your own wording does not need to match corpus/parking-lot's reference lists exactly. A competent design can say "a driver picking up their car" where the reference says "driver leaving at the exit," and both count. What has to match is the underlying design: the same actors, the same things being modelled, the same behaviour expected of the system, each in whatever words fit how you think. That is what an interviewer is actually listening for. Not whether you happened to guess the reference author's phrasing, but whether you read the prompt closely enough to land on the same decisions they did.

Going deeper

Lesson F1 grades your extraction against the corpus's must_haves list, and when no LLM is reachable the grading is entirely mechanical. That is worth knowing exactly, rather than trusting it is fair on faith. server/lib/grade-phase1.mjs stems every phrase: it lower-cases the text, strips punctuation, and splits camelCase at the boundary so vehicleType reads the same as "vehicle type." It then asks one narrow question per reference item: does any line you wrote share at least 60% of that item's words that are longer than three letters? An item counts as found only above that threshold, and you need to clear 80% of the whole list to pass.

That number changes how you should write your answer. "The lot has to reject entry when nothing fits" and "no room, no ticket" mean the same thing to a person. They share almost no words, though, and the matcher only counts words. Writing your list in the same plain domain terms the prompt itself used, spot, vehicle, ticket, fee, is not a style choice. It is what the matcher rewards, and, not by coincidence, it is also what reads as precise to a human grader on the runs where one is available instead. The same mechanism scores out_of_scope in chapter 4.2, where a missed item routes to a different lesson than a missed item here does.

Next: chapter 4.2, Saying what you will not build — where the fourth list, the one you refuse to build, gets the same scrutiny the other three just did.

← 3.10 Composite and Iterator: trees and traversal · All chapters · 4.2 Saying what you will not build →