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. Count what it actually tells you.

Vehicles arrive. They park. They pay when they leave. Sizes differ. Rates differ. It has to run at the end.

Five facts in four sentences, and every one 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 it phrase by phrase. For each one ask: fact, or door left open?

"They park somewhere." Fact: a vehicle ends up occupying space. Door: 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 and never answers it.

"The rates aren't the same for all of them either." Fact: pricing depends on vehicle type. Door: everything about how that pricing works.

Is the fee 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, however many spots it used? Nothing rules any of it out.

"They pay on the way out." This one sounds like it settles the timing of payment. It does. 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 photocopied the old one is trying exactly that, and a design that never asked has no answer ready.

That is the real shape of an ambiguous prompt. It names the problem in ordinary words and 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 here.

3. From nouns to four lists

Read the prompt once more. This time hunt nouns instead of gaps.

Vehicle. Spot. Ticket. Rate. Lot. Driver.

Each noun is a candidate for something your design has to represent. Sorting them into four buckets is how a vague paragraph becomes a specification you can defend.

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

Write the first three down before you type a keyword like class or interface.

Skip that step and something specific goes wrong. A design built straight from a paragraph tends to model whatever noun the author happened to type first, instead of the noun the problem needs.

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

Once your three lists exist, the gaps in them turn into questions.

Not every question you can think of is worth asking out loud.

corpus/parking-lot/problem.json ships twelve real clarifying questions for this prompt. 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 decides something structural. The first decides how allocation works at all, because a single-spot allocator cannot answer a requirement it was never told existed. The second decides the shape of your timer logic. The third decides whether a truck quietly gets charged twice.

Now compare a question like "should I use an ArrayList or a HashMap for the spots?"

It has an answer. 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.

That question has no place on your clarifying list. Asking it spends clock time learning something your interviewer cannot answer for you, because the decision was always yours.

Here is the test, stated plainly:

If two different answers would produce two different class designs, ask it. If every answer leaves your classes exactly as they were, keep it in your own head.

5. What skipping one actually costs

Say you skip the truck-spots question and assume every vehicle takes one spot.

You design an allocator on that assumption. You write it. You test it. 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 exactly this problem. Mid-round, the rule changes: two motorbikes may now share one standard spot.

Take the two cases side by side.

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 costs a handful of lines in one class.

Or it was never told, and the one-spot assumption is buried inside a loop that long ago forgot it was ever an assumption. Now the same change means finding every place that loop's shape leaked out and reworking each one — under the clock that was already running.

The ten seconds a good clarifying question costs at minute two is the cheapest insurance you can buy against a change that lands at minute twenty-five.

6. When you are actually done

You are done extracting once you have written the three lists from section 3, plus the fourth one the next chapter covers.

Your wording does not have to match corpus/parking-lot's reference lists. A competent design can say "a driver picking up their car" where the reference says "driver leaving at the exit". Both count.

What has to match is the design underneath. The same actors. The same things modelled. The same behaviour expected of the system, in whatever words fit how you think.

That is what an interviewer is listening for. Not whether you guessed the reference author's phrasing, but whether you read the prompt closely enough to land on the same decisions.

Going deeper

Lesson F1 grades your extraction against the corpus's must_haves list. When no LLM is reachable the grading is entirely mechanical, and you should know exactly how rather than trusting it is fair.

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".

Then it asks one narrow question per reference item. Does any line you wrote share at least 60% of that item's words longer than three letters? An item counts as found only above that threshold, and you need 80% of the whole list to pass.

That number should change how you 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, and the matcher only counts words.

So writing your list in the 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.

The same mechanism scores out_of_scope in chapter 4.2, where a missed item routes you 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 →