The five-phase script: clarifying the prompt and writing requirements

Every one of the eleven design problems in this course is worked with the same five-phase script, on the same clock. Memorise the clock, not the answers.

This lesson lays out the script and its time budget, then works the first two phases — the ten minutes before any modelling — on a car rental prompt. The next lesson carries the same example through modelling and code.

The script

Why the budget looks like this

Ten minutes before any modelling feels wasteful and is not. Those ten minutes decide which problem you are solving. A candidate who skips them models a single-floor flat-fee parking lot while the interviewer had a multi-floor size-based one in mind, and the mismatch surfaces at minute thirty when it is expensive.

Fifteen minutes for modelling is tight and deliberately so. It is enough for six to nine classes with relationships, which is the right size for this round. If you need longer, your scope is too big — cut a requirement rather than borrowing time from coding.

Fifteen minutes for code is enough for two or three methods written properly. It is not enough for a whole system, which is why choosing which methods to write is itself a scored decision (Phase 5: coding the core, and what to skip).

Running the clock in the room

Say the phase boundaries out loud. "That's my requirements list — I'm going to move to classes now unless you want to add anything." Three things happen: the interviewer gets a chance to redirect you cheaply, they see you managing time, and you get an implicit checkpoint.

If the interviewer interrupts with a new requirement at minute thirty, say what it costs: "That's a real requirement. Adding it properly means changing the pricing interface — I'd rather finish the exit flow first and then come back to it, is that alright?" Naming the trade-off out loud scores; silently trying to do both does not.

Phase 1: clarifying questions that earn points

The prompt is one sentence because the interviewer wants to see which sentence you turn it into. This phase is not a formality; it is the first scored thing you do.

Three kinds of question

Scope questions decide how many classes exist.

• "One location or many?"
• "Is payment in scope, or do I assume a payment service exists?"
• "Do we need to persist anything, or is this in-memory for the session?"

Behaviour questions decide what the states and rules are.

• "What happens if payment fails halfway through?"
• "Can a booking be cancelled? Refunded?"
• "Is there a timeout anywhere — a held seat, an expired parcel, an idle session?"

Scale and concurrency questions decide the hard parts.

• "How many concurrent users hit this — one entry gate or six?"
• "Is this a single process, or do I need to worry about two instances?"
• "Roughly how many items are we storing? Hundreds, or millions?"

The third group is where candidates under-ask. In this round the answer is nearly always "one process, several threads", and asking gets you the concurrency conversation early rather than at minute forty-three.

Stop after four or five

There is a real failure mode of asking twelve questions and burning eight minutes. The interviewer starts to suspect you are stalling.

The rule: ask the questions whose answers change the class model. "Is pricing tiered?" changes the model — it is the difference between a field and a strategy interface. "What colour is the app?" does not.

When you have four answers that change the model, stop and say so: "That's enough for me to start. I'll make assumptions on anything else and call them out as I go." That last clause is important — it gives you permission to decide things unilaterally for the rest of the hour, as long as you say them aloud.

Phase 2: writing requirements down

Five minutes, written on the board, in two short lists. This is the cheapest scoring opportunity in the whole round and the one most often skipped.

Functional requirements are verb phrases

Short. One line each. Six to eight of them.

For the car rental prompt from the Phase 1 exchange above:

FUNCTIONAL1. Search available cars by class and date range2. Reserve a car for a date range3. Pick up: convert reservation to an active rental4. Return: close rental, compute charge5. Compute price by class, duration, weekly discount6. Cancel a reservation

Notice they are all verbs. "Car" is not a requirement; "reserve a car" is. This matters because in Phase 3 the verbs become methods and the nouns become classes, so writing requirements as verb phrases does half of the modelling work for you.

Non-functional requirements are constraints

Two or three. These are the ones that create the interesting parts of the design.

NON-FUNCTIONAL- A car must never be double-booked for overlapping dates- Adding a new pricing rule must not modify existing pricing code- Search must not scan every car in the fleet

Each of those forces a specific decision later: the first forces a locking or reservation strategy, the second forces a Strategy interface (The seven patterns that actually appear), the third forces an index rather than a list. A design conversation with no non-functional requirements has nothing to be interesting about.

The cut list is a scored artifact

Write a third short list of what you are not doing.

OUT OF SCOPE (named, not forgotten)- Multi-branch inventory and car transfers- Loyalty points, insurance upsells- Damage inspection workflow

This looks like admitting defeat. It is the opposite. An interviewer cannot tell the difference between "did not think of insurance" and "decided insurance was not worth the forty-five minutes" unless you tell them. Writing it down converts a gap into a judgement call.

It also gives you a lever. At minute thirty-five when you are behind, you point at the board and say "I'm going to move cancellation to the cut list and spend the time on the double-booking problem instead." That is a sentence a senior engineer says.

Keeping the interviewer aligned

Read the list back, then ask one question: "Anything on here you'd add, or anything you'd rather I dropped?"

Interviewers frequently answer this with the real thing they wanted to test. "I'd add that a returned car needs a cleaning state before it can be rented again" tells you the round is about state machines. That is an enormous amount of information for one question.