Why this matters

OOP design interviews (often called "Low-Level Design" or "Object-Oriented Design" rounds, distinct from system design — see the companion HLD & LLD book for how they relate) are judged less on whether you reach a "correct" design and more on whether your process shows judgment. This closing chapter distills the pattern used consistently across Chapters 15–17 into a repeatable approach, plus the specific things interviewers are actually listening for.

The repeatable process

[BEGINNER] The same shape worked for the parking lot, the library, and the elevator:

1. Clarify requirements before designing anything. Ask about scale, edge cases, and which features are truly in scope — this alone distinguishes strong candidates, since a design built on wrong assumptions is wasted effort regardless of code quality.
2. Identify the core entities and their relationships. Sketch (verbally or on a whiteboard) which relationships are composition, aggregation, association, and inheritance (Chapter 11) — get this right before writing any code, since it drives every class's responsibilities.
3. Assign responsibilities using SRP (Chapter 9) — each entity protects its own invariant; a service/orchestrator class only coordinates across entities (Chapter 12's anemic-model line, drawn live).
4. Introduce interfaces where there's a genuine, current need for multiple implementations (payment methods, notification channels) — and explicitly justify not introducing one where there isn't (Chapter 14's premature-abstraction lesson, applied out loud).
5. Write the code for the core interactions, not every method — a working sketch of the 3–4 methods that matter most beats a complete but shallow class listing.
6. Proactively name trade-offs and edge cases: concurrency (Chapter 14), what was deliberately left out of scope, and what would need to change for a stated follow-up ("what if this needed to scale to 10,000 elevators?").

What interviewers are actually listening for

[SENIOR INSIGHT] Beyond "does the code compile," interviewers are typically evaluating:

Signal	What it demonstrates
Asking clarifying questions before designing	Won't build the wrong thing confidently
Naming relationships precisely (composition vs. aggregation vs. association)	Real understanding, not memorized vocabulary (Chapter 11)
Justifying why an interface exists, or why it doesn't	Judgment, not reflexive pattern application (Chapter 14)
Catching an invariant and enforcing it structurally, unprompted	Internalized Chapter 1's core lesson, not just able to recite "encapsulation"
Flagging a concurrency or scale concern without being asked	Senior-level awareness beyond the immediate exercise
Adapting the design cleanly when the interviewer changes a requirement mid-exercise	Design wasn't fragile — a sign it was built around real relationships, not guesses

[IN PRACTICE] The single most common failure mode in these interviews isn't a wrong answer — it's silence. Talking through the reasoning (even reasoning that turns out imperfect) gives the interviewer far more signal than a correct design delivered with no visible thought process, because the entire point of the exercise is evaluating how you design, not just what you produce.

Handling a mid-interview curveball

[SENIOR INSIGHT] Interviewers frequently change a requirement partway through specifically to see how the design responds — this is not a trick, it's often the actual point of the exercise. A design that required rewriting from scratch when, say, the parking lot exercise added "support for reserved spots" reveals it was built too rigidly around the original requirements. A design where that same change is a small, localized addition (a new field, one new check in Spot.canFit, no restructuring) reveals the entities and relationships were modeled at the right level of generality — not too specific, and not over-engineered for imagined flexibility either (echoing Chapter 14 one more time: the right amount of flexibility is driven by real requirements, including the ones revealed mid-conversation, not by guessing every possible future one in advance).

Common mistakes

1. Diving into code before clarifying requirements or sketching relationships — the single most common and most avoidable mistake, and the first thing this checklist addresses for a reason.
2. Building a deep, "impressive-looking" class hierarchy to demonstrate OOP knowledge, when a flatter, composition-based design (Chapter 7) would actually be the better answer — interviewers experienced with OOP design rounds recognize over-engineering as a negative signal, not a positive one.
3. Going silent while thinking. Even tentative, out-loud reasoning ("I'm considering an interface here because...") gives far more signal than a long pause followed by a finished class diagram.
4. Treating a mid-interview requirement change as an attack to defend against, rather than as useful information about how the design should flex — react by adapting the design, not by justifying why the original design was already fine.

Checklist: an OOP interview, start to finish

1. Spend the first few minutes on clarifying questions — scope, scale, and which features are actually required, not assumed.
2. Name relationships explicitly (composition, aggregation, association, inheritance) before writing class definitions.
3. Assign one clear responsibility per entity, and justify any orchestrating/service class by naming what it coordinates across, not what invariant it enforces (that belongs on the entity).
4. Introduce each interface with an explicit reason ("multiple implementations exist/are required") — and say out loud when you're deliberately not introducing one.
5. Narrate trade-offs and scope boundaries proactively — concurrency, what's out of scope, and how the design would need to change for a larger scale.

Discussion / interview questions

(This chapter's own discussion questions are about the interview process itself — a fitting way to close the book.)

1. "What's the biggest signal you look for in the first two minutes of an OOD interview, if you were the interviewer?" Strong answer: Whether the candidate asks clarifying questions before designing, rather than starting to write classes immediately — names this as the single most common differentiator.

2. "How should a candidate react when the interviewer changes a requirement mid-design?" Strong answer: Treat it as information about how the design should flex, and adapt incrementally rather than defending or scrapping the original design — and recognizes that a design requiring a full rewrite for a small requirement change reveals it was too rigid.

3. "Is a more complex design (more classes, more interfaces) generally a stronger interview answer?" Strong answer: No — cites Chapter 14's premature-abstraction lesson; an experienced interviewer reads unjustified complexity as a negative signal, not a demonstration of knowledge.

4. "What should you do if you're unsure whether something should be a class, an interface, or just a field/enum value?" Strong answer: Say the uncertainty out loud and reason through it using the book's tests (does it need multiple implementations? is there a genuine is-a relationship? Chapters 8, 9, 14) rather than silently picking one and hoping it's not questioned.

5. "Looking back across the three design exercises in this book (parking lot, library, elevator), what's the one judgment call that recurred in all three?" Strong answer: Recognizes the repeated pattern: deciding where an interface/hierarchy is genuinely justified (multiple current implementations) versus where a plain class or enum-parameterized field suffices — the premature-abstraction judgment call, applied consistently across all three exercises.

Chapter summary / cheat sheet

• The repeatable process: clarify requirements → identify entities and relationships (Chapter 11's vocabulary) → assign responsibilities via SRP → justify each interface individually → code the core interactions → proactively name trade-offs.
• Interviewers weigh process — clarifying questions, precise vocabulary, justified decisions, unprompted trade-off awareness — as heavily as the resulting design.
• Silence is the most common failure mode; narrate reasoning even when uncertain.
• A mid-interview requirement change is a design-flexibility test, not an attack — react by adapting, and notice if adapting is easy (a sign of a well-modeled design) or hard (a sign it was over-fit to the original requirements).
• The premature-abstraction judgment call (Chapter 14) is the single most recurring theme across every design exercise in this book — it is, in a real sense, the practical center of gravity of the entire subject.

---

End of Book

"Objects First: A Practical Guide to Object-Oriented Programming" — 18 chapters, complete.

Next book in the suggested reading order: Design Patterns.