Designing under pressure · chapter 33 of 33
Your first full round, start to finish
Chapter 4.5 · Part 4, Designing under pressure · about 45 minutes
What you need before this chapter: chapters 4.1 to 4.4, and everything in Parts 1 to 3. This is the last chapter of the course. After it, the app takes over.
When you finish this chapter you will be able to:
- Walk through one complete attempt end to end, phase by phase, knowing what each phase asks for before you start it
- Explain the five scoring dimensions in your own words, and say which two are decided by a compiler rather than a person
- State the hire bar, and the one rule that overrides it no matter what your total score was
- Explain what "held" means, and why it is a stronger claim than "demonstrated"
- Start Phase 0 of your first problem the moment you finish reading this page
1. Picking a problem
This chapter walks one attempt at corpus/parking-lot, the problem chapters 4.1 through 4.3 already used. It is tier 1, the easiest tier in the corpus.
By now you have read its ambiguous prompt, its out_of_scope list, and a diagram of three of its classes.
Starting your first real attempt on a problem you already half know is not cheating. It means the first time you sit down to a full round, you learn the shape of the round alone, instead of the round and the problem at once.
A full round is eight rungs, called the Ladder inside the app. This chapter walks the first six, which are the ones a single attempt uses.
2. Phase 0: vocabulary, with no thinking required
Before any clock starts, Phase 0 has you type a short list of constructs from a blank file until each one compiles in under ninety seconds, twice.
An enum carrying its own behaviour is on the list. So is a record value object, a `sealed interface for a closed set of variants, an EnumMap, and a chain of Comparator`s. So is a builder once a constructor grows past four arguments, and the equals/hashCode contract. Round it out with a small exception hierarchy and the four shapes that appear in almost every later problem: a policy interface, a factory, a listener, a repository.
None of this is new. Parts 1 to 3 taught every one of these.
Phase 0 exists so typing them stops being a decision you make mid-round. An interviewer's clock does not pause while you recall the exact syntax for a sealed interface. The whole purpose is to move that recall below the level of thought, before the clock that matters starts.
3. Phase 1: requirement extraction, ten minutes, no code
This is chapter 4.1 and chapter 4.2, timed.
Ten minutes. Start from prompt_ambiguous. End with actors, entities, requirements, and an out_of_scope list. Add three clarifying questions and the core method signatures your design will need. No code gets written at any point.
Your answer is checked against must_haves, using the same stemmed word-overlap matcher chapter 4.1 described. You need 80% of the reference list, in your own words, to move on.
One detail worth knowing. A missed out_of_scope entry and a missed requirement route you to two different lessons afterwards, because skipping a requirement and forgetting to refuse a feature are two different mistakes with two different fixes.
4. Phase 2: the skeleton sprint, twelve minutes, types only
Twelve minutes to write enums, records, interfaces, and class stubs with real method signatures. No logic inside any method body yet.
One rule matters. It has to compile.
While you type, the editor tracks two required interface names live — here PricingPolicy and SpotAllocator — and lights each one up the moment it exists. Everything else is yours. Every class name, every field, every private method.
That is the actual rule the grader runs on, and not a courtesy. Hidden tests only ever call one file, Entry.create(), and everything on the far side of that line is invisible to them.
So a test can never fail because you called a field idNumber where the reference called it vehicleNumber. No test looks at a field. It sees only what ParkingLotApi declares.
Say that plainly, because it answers the fear most people bring into a first attempt. The app will never fail you on naming. A design with a working park method and an oddly named internal class passes.
And a design that never compiles, or whose Entry.create() never returns a working implementation, is not scored as a failure either. It is marked invalid, nothing is recorded against you, and you are told exactly which method is missing so you can run it again.
Naming quality is not ignored completely. It moves into how clearly your classes read as the actual problem, which is a small part of one dimension in section 8. There it can cost you a fraction of a score. It can never zero one, and it can never be why a run does not count.
5. Phase 3: the core build, thirty minutes to a green suite
This is where logic goes in.
Thirty minutes against a hidden JUnit suite whose @DisplayNames you can read before you start, so you know what is being checked without seeing the assertions.
A main method that actually runs your design end to end is not optional. Interviewers run the program before they read a line of source. A submission with no working driver is treated as not functioning at all, whatever the rest of the code gets right.
6. Phase 4: the curveball, fifteen minutes
Your working design from Phase 3 inherits a new requirement. For corpus/parking-lot, one recorded curveball lets two motorbikes share a single standard spot.
You get fifteen minutes to absorb it.
Two numbers come out. Whether the new test suite passes, and how many lines you touched in files that already existed before the curveball landed. New files are free.
Chapter 4.2 showed you the exact formula behind that second number. A scope decision you made ten minutes earlier, in Phase 1, is what this phase is quietly checking the bill for.
7. Phase 5: defence
Four kinds of question, asked in writing, clocked.
Why this pattern here, rather than the obvious alternative? How would you extend the design for a named future requirement? What would break under two threads, and where exactly would the race be?
Answers are graded against the problem's own decision log, the same way your code was graded against must_haves.
This single phase is 30 to 50% of a real interview's outcome, and almost nobody trains it alone. There is no compiler to tell you whether a written justification was any good.
8. The verdict
Every attempt is scored against five dimensions, and the weights are fixed:
| Dimension | What it checks | Weight | Who decides |
|---|---|---|---|
| D1 | Code design and structure | 30% | a model, reading your code |
| D2 | Working functionality | 25% | a compiler and a test runner |
| D3 | Design patterns and SOLID | 20% | a model, reading your code |
| D4 | Extensibility | 15% | a diff tool, measuring your curveball |
| D5 | Edge cases and error handling | 10% | a test suite plus a model |
Read that last column again.
D2 and D4 — 40% of your score — never go through a model at all. A compiler either accepts your code or it does not. A test either passes or it does not. A diff tool counts lines whether you like the count or not.
Nothing about those two numbers can be argued with. That is deliberate, and it is what makes the other 60% worth trusting.
Every dimension is scored on four levels. 0 for absent, 1 for attempted, 2 for competent, 3 for exemplary.
Level 2 is the hire bar, the score a candidate who actually gets the offer usually lands at. A weighted total at or above it earns a hire verdict.
With one exception that overrides everything. A single dimension scored at 0 is a no-hire, whatever the rest of your total adds up to. A real interviewer rejects on exactly that pattern: one glaring gap, however well the rest went.
9. Demonstrated, and held
Passing one problem once is not the finish line.
Every syllabus item — the 34 named skills chapters 1.1 through 4.4 have been teaching you — moves through three states.
Not yet: you have never cleared level 2 on it. Demonstrated: you cleared level 2 once, with a date attached. Held: you cleared level 2 twice, on two attempts at least three days apart.
Held is the real target, and that three-day gap is not an arbitrary delay. Reproducing a design choice on the evening you read about it is one claim. Producing it cold, three days later, is a stronger one.
The app's summary of your progress reads like this: "21 of 34 demonstrated, 14 held," followed by exactly which items still need a second attempt.
Notice that sentence has a denominator, and the denominator does not move. Low-level design, at the level this app trains, is a closed list. It is not an unbounded pile of things you might still not know.
Going deeper
Section 8 said D2 and D4 never go through a model. The other three do. So what stops a model grading the same code differently on two different days?
Every score above level 0 has to name evidence. A file and a line number, or a type name that actually appears in your submission. The harness checks each one mechanically before accepting the score.
Cite a file that does not exist in what you submitted, or a line number past the end of the file, and the whole response is rejected and asked for again once. Fail twice and that dimension is marked unscored instead of guessed at. Nothing is recorded against you, the same way a run that never compiles is marked invalid instead of failed.
At level 2 or 3, the model also has to name counter_evidence — something arguing against the score it just gave — or say plainly that it found none. That forces it to go looking for a reason it might be wrong before it can finish grading. A model held to that standard is measurably harder to flatter than one that only has to justify a number it already picked.
One in six full rounds gets graded twice, independently, and both scores are kept.
A one-level gap between the two is normal disagreement. A gap of two or more is not read as evidence that your work was ambiguous. It is logged as a defect in the anchor itself — the wording that tells the model what each level means — and that wording gets sharpened afterwards. When two readings disagree that badly, the standard is what is assumed broken.
None of that makes the 60% as certain as the 40% a compiler decides. It does mean every uncertain score has to show its work, in a form you can open and check line by line.
You are never asked to trust a number that arrived with no reasoning attached. That is the real bar for trusting a graded score. Not that a model is never wrong, but that being wrong leaves a trail — one you can read, question, and in the worst case throw out at no cost to yourself.
Next: close this course and open the Ladder. Pick corpus/parking-lot, tier 1, and start Phase 0. Type the vocabulary until it compiles twice under ninety seconds, then let Phase 1 hand you the same ambiguous prompt this chapter has been quoting from the start. You already know how to read it.