How the OOD round is scored, how candidates lose it, and how to practise

Knowing what the round is only helps if you know how it is graded. This lesson covers the scorecard the interviewer fills in, the four ways candidates reliably lose, and the practice routine that turns this course into performance under a clock.

Interviewers are not grading a diagram against a reference answer. They are filling in a rubric with four rows, and three of them have nothing to do with knowing patterns.

The four rows

1. Decomposition. Did you break the problem into pieces that make sense? A grader looks for: does each class have one job, are the names drawn from the problem domain, and is there anything that is a class only because you did not know where else to put it.

2. Extensibility. Does the model survive a change? This is what the extension question at minute 40 is testing. "Now the lot has electric-vehicle charging spots" should be a new class and one line of configuration, not an edit to six existing classes.

3. Code quality. Are the two or three methods you wrote clean? Meaningful names, short methods, no method with five levels of nesting, no branch on a type code where polymorphism belongs.

4. Communication. Did you narrate the reasoning? Every choice you make silently scores zero, because the interviewer cannot distinguish a considered decision from a lucky one.

Partial and good beats complete and bad

This surprises people, so it is worth stating plainly. A design that models three of five entities cleanly, with correct relationships and one well-written method, scores higher than a design that covers every entity in a single 300-line class.

The reason is that the round is a proxy for future work. An interviewer is asking: if this person joined and I gave them a feature, what would the pull request look like? A clean partial model answers that question. A complete tangle answers it badly.

This has a direct tactical consequence. When you are running out of time, do not start a new class. Finish the one you are in, then say out loud what the remaining pieces would be: "Payment I'd model as an interface with card and cash implementations; I'd wire it into the ticket's exit flow. I'll leave it there and spend the time on the concurrency question." That sentence earns most of the credit the class would have earned, in eight seconds.

The thing that multiplies all four rows

Talking. Not narrating your typing — narrating your reasoning. Compare:

"Now I'm making a class called PricingStrategy with a method calculate."

"Pricing is the thing most likely to change here — hourly today, but weekend rates and monthly passes are obvious next asks. So I'll put it behind an interface rather than inline in the ticket, and each rule becomes its own class."

Identical code. The second sentence is the one that gets scored.

The failure modes

Four ways to lose this round. They are common enough that an interviewer can usually tell which one is happening within the first ten minutes — and each one is the opposite of something on the rubric above.

1. Coding before modelling

The candidate hears "design a parking lot" and starts typing class ParkingLot {. Twenty minutes later there are four classes, none of them thought about, and a change is expensive because everything already refers to everything.

The tell is that no requirement was ever written down. The fix is a hard rule: nothing gets typed for the first ten minutes. Clarify, then list requirements, then name classes in words, then draw. Section 2 (A Framework for the OOD Interview) turns this into a timed script.

2. The god class

One class named after the whole system holds every field and every method. ParkingLot has the spots, the pricing, the payment processing, the receipt formatting, and the gate hardware.

It is seductive because it is fast, and it fails the one-sentence test from Phase 4: assigning responsibilities: you cannot state that class's job without using "and" four times. Every extension then lands in the same file, and nothing can be tested in isolation.

3. Pattern soup

The opposite error, and it is now more common than it used to be because candidates study patterns first. Six patterns appear in a design that needed one: an abstract factory to make a vehicle, a singleton for a lot that could have been passed in, an observer where a method call would do, a builder for a class with two fields.

Each pattern adds a class and an indirection. An interviewer reads unnecessary indirection as inability to judge cost, which is worse than not knowing the pattern at all.

4. Silence

The candidate thinks well and says nothing for four minutes. The interviewer has no evidence. In a remote interview this is fatal, because the interviewer cannot even see the pen moving.

How to catch yourself

Four checks you can run mid-interview, silently:

• Am I typing? If yes and it is before minute fifteen, stop and go back to the board.
• Can I say this class's job in one sentence with no "and"? If not, split it.
• What change does this pattern make cheap? If you cannot name the change, remove the pattern.
• When did I last speak? If you cannot remember, say what you are thinking right now, even if it is "I'm deciding whether Ticket should hold the fee or compute it."

How to use this course

This course fails as passive reading. If you read the eleven design sections the way you would read a novel, you will finish knowing what a good parking lot design looks like and still be unable to produce one under time pressure.

The protocol

For each of Sections 4 through 14:

1. Read the problem statement at the top of its first lesson, and stop. Every design section opens with the prompt and a stop sign for this reason.
2. Set a 45-minute timer. Paper and a pen, or a plain text file. No editor with autocomplete, no internet.
3. Work the problem out loud. Talk to an empty room, or record yourself. This feels ridiculous and is the single highest-value part of the exercise, because narration is one of the four scored rows and it is the only one you cannot practise silently.
4. Then read the section, and diff your work against it. The diff matters more than the reading. Write down the two or three places you differed and why.
5. Reattempt one week later for any problem where the diff was large.

Forty-five minutes plus forty minutes of reading, eleven times, is roughly sixteen hours. That is the actual cost of this course, and it is what makes the difference.

What "diffing" means here

You are not checking whether your class names match. You are checking four things:

• Missing entity. Did the lesson model something you left as a field, or a field you made into a class?
• Misplaced responsibility. Did a method end up on a different class, and why is that better?
• A pattern you did not reach for, or one you used and the lesson did not.
• A question you did not ask in the clarifying phase.

The fourth is the most common gap for people new to this round.

The language used here

Every design in this course is written in Java. It is the safest choice for this round: interfaces, enums, and access modifiers are explicit in the syntax, so a reader can see the design in the code. You do not have to interview in Java — use whatever you are fastest in — and where Python or another language would express something meaningfully differently, there is a note callout saying so.

Section 3 is a reference, not a chapter

Section 3 (OOP Fundamentals) is three reference lessons on encapsulation, abstraction, inheritance, polymorphism, composition, SOLID, UML, the seven patterns, and when not to use one. Read it once now if the terms are unfamiliar, then treat it as a lookup table. Every design section links back to the specific lesson in Section 3 that it depends on, so you never need to have memorised it first.