OOD Interview Approach (45-Minute Framework)

1. What Is It?

An OOD interview asks you to design a software system at the class level — what objects exist, how they relate, what responsibilities they hold. Unlike system design interviews (which focus on infrastructure, scaling, and services), OOD interviews test your ability to apply object-oriented principles to produce a clean, extensible class structure.

Without a structured approach, candidates either rush into code (missing the design conversation) or over-clarify forever (never reaching the implementation). The 45-minute framework divides the interview into well-paced phases so you demonstrate clear thinking, communicate a design, and show coding ability — all within the time constraint.

2. How It Works

The 6-Phase Framework

Total: ~45 minutes

Phase 1 — Requirements & Use Cases (5–7 min)

Do this first, always. Rushing to design before clarifying scope is the most common mistake.

Steps:

1. Restate the problem in your own words to confirm understanding.
2. Identify actors — who or what interacts with the system? (Users, external systems, devices)
3. List 4–6 core use cases — what are the primary things the system must do?
4. State scope boundaries — explicitly name what you are NOT designing (persistence layer, auth, payment provider APIs, distributed concerns).
5. Surface assumptions — single-user vs. multi-user? In-memory or persistent? Concurrency expected?

What interviewers are testing: Do you clarify before coding? Can you identify the boundaries of the problem?

Pitfall: Over-clarifying. Ask 3–4 focused questions, then commit to reasonable assumptions. Don't wait for the interviewer to specify every detail.

Phase 2 — Object Modeling (5–7 min)

Extract candidate classes from the use cases using the noun extraction technique: walk each use case and identify the key nouns. Every noun is a candidate class.

Then for each class, state:

• Its single responsibility (one sentence)
• What it owns (data it holds)
• What it does (behavior it offers)

Steps:

1. List all candidate classes from noun extraction.
2. Cull non-classes: remove attributes masquerading as classes (e.g., "color" is an attribute of Car, not a class).
3. Assign responsibilities using SRP.
4. Sketch relationships in plain English before drawing: "A ParkingLot has many ParkingFloors. Each ParkingFloor has many ParkingSpots."

What interviewers are testing: Can you break a problem into cohesive objects? Do you understand SRP?

Phase 3 — Class Design & Relationships (10–12 min)

This is the core of the interview. Produce a UML class diagram.

Steps:

1. Define inheritance vs. composition for each relationship ("is-a" vs. "has-a").
2. Define interfaces and abstract classes with their method signatures.
3. Assign attributes and methods to each class (with types and signatures).
4. Draw the UML class diagram showing all classes, attributes, key methods, and labeled relationships with multiplicities.

Diagram checklist:

• All major classes present
• Attributes have types
• Key methods have signatures
• Every relationship labeled with multiplicity (1, 0..1, *, 1..*)
• Inheritance vs. composition distinction clear
• Interfaces/abstract classes marked with stereotypes

What interviewers are testing: UML fluency, OOP principle application, ability to communicate a design without code.

Phase 4 — Design Patterns (5–7 min)

Identify 2–3 patterns that fit naturally and justify each.

For each pattern:

1. Name it and state which GoF category it belongs to (creational, structural, behavioral).
2. Explain the problem it solves in this specific design — not a textbook definition.
3. Show where it integrates — which class changes, which new classes are added.

Common patterns by problem type:

What interviewers are testing: Pattern recognition, ability to justify application (not just name-dropping).

Pitfall: Applying patterns for their own sake. Every pattern must solve a real problem in the design.

Phase 5 — Key Implementation (10–12 min)

Implement the most representative classes.

Steps:

1. State scope: "I'll implement the core domain model and the [key flow] — that's where the most interesting design decisions are."
2. Implement in your strongest language unless the interviewer specifies otherwise.
3. Show the pattern from Phase 4 in code — not just the data classes.
4. Implement at least one end-to-end flow (e.g., vehicle enters → spot assigned → ticket issued).

Code quality checklist:

• Descriptive names (no x, tmp, data)
• Proper encapsulation (private fields, public interface)
• No dead code
• Idiomatic for the language (type hints + ABC in Python; interfaces + generics in Java)
• Pattern implementation visible in code

What interviewers are testing: Can you write real, production-quality code? Not just stubs.

Phase 6 — Extensibility & Trade-offs (3–5 min)

The interviewer introduces new requirements. You defend and evolve the design.

Be ready to discuss:

1. New requirements: "What if we add X?" Walk through how the design handles it.
2. Design alternatives: For one major decision, describe the alternative you considered and why you rejected it.
3. Known weaknesses: Proactively name what would break at scale or under new constraints. This signals maturity.
4. Executive summary: Close with the 3 key design decisions and why they were right.

What interviewers are testing: Can you think beyond the happy path? Do you understand the trade-offs of your own design?

Time Management Tips

0:00 - 0:07   Phase 1: Requirements
0:07 - 0:14   Phase 2: Object Modeling
0:14 - 0:26   Phase 3: Class Design + UML
0:26 - 0:33   Phase 4: Patterns
0:33 - 0:43   Phase 5: Implementation
0:40 - 0:45   Phase 6: Trade-offs (overlap with Phase 5 wrap-up)

If the interviewer spends extra time in Phase 1, compress Phases 4 and 6 — never skip Phases 3 (diagram) and 5 (code).

3. Variants & Comparisons

OOD vs. System Design scope boundary:

• OOD scope: classes, interfaces, methods, relationships, in-process patterns
• Out of scope in OOD: databases (schema design may be discussed briefly), message queues, CDNs, sharding, replication, API gateways

4. When to Use It (and When NOT To)

Use this framework when:

• The interview is explicitly an OOD interview (not system design, not algorithms).
• You are asked to "design [a thing]" with an emphasis on classes and relationships.
• The interviewer expects a UML diagram and code.

Adapt the framework when:

• The interviewer fast-forwards a phase — follow their lead, don't insist on completing every step.
• The interview is 30 minutes — compress to: Requirements (3 min) → Object Model + UML (10 min) → Implementation (12 min) → Trade-offs (5 min).
• You're asked to focus on a specific pattern — spend more time on Phase 4/5 and reduce Phase 1.

Anti-patterns:

• Diving into code immediately: Shows you can't think structurally. Always sketch the class diagram first.
• Over-scoping: Designing authentication, persistence, and distributed concerns when the interview is about OOD. Scope to class-level design.
• Passive candidate: Waiting for the interviewer to drive. You own the design conversation — ask clarifying questions, make decisions, explain trade-offs.
• Perfect design paralysis: There is no perfect OOD. Commit to a design, name the trade-offs, and keep moving.

5. Real-World Usage

1. FAANG OOD interviews Amazon, Google, and Meta use OOD rounds specifically to test class design skills. The problems are classic: Parking Lot, Library System, Elevator System, Chess. The framework maps directly to what these interviewers score you on: requirements clarity, object modeling, diagram quality, pattern application, code quality.

2. Design review meetings The same 6-phase structure applies in professional design reviews: clarify scope, extract components, define interfaces, identify patterns, review code, discuss trade-offs. The interview framework is a compressed version of real engineering practice.

3. Open-source contribution onboarding Reading large open-source projects (like Spring Framework or Django) follows the same mental model: identify the major classes, find the inheritance hierarchies, locate the patterns (Strategy, Observer, Template Method), then read the key implementation flows. The framework trains the same cognitive skill.

6. Interview Cheat Sheet

Key sentences to say:

1. "Before I start designing, let me clarify scope — I want to make sure I'm solving the right problem."
2. "I'll identify the actors and core use cases first, then extract objects from those use cases."
3. "Let me sketch the class diagram — I want the relationships explicit before writing any code."
4. "I see a natural fit for [Pattern] here because [specific problem in this design]. Let me show how it integrates."
5. "The biggest trade-off in my design is [X]. The alternative was [Y], but I chose [X] because [reason]."

Common follow-up questions:

Q: How do you decide what's a class vs. an attribute? A: If the thing has its own behavior (methods) or multiple attributes, it's a class. If it's a single scalar value that describes another object, it's an attribute. Example: Color as a string is an attribute of Car. But if colors have hex codes, display names, and conversion methods, Color earns its own class.

Q: How do you handle persistence? A: In an OOD interview, I scope persistence out. I'll design the domain model and note "these objects would be persisted — the repository pattern would handle that — but that's out of scope for this design."

Q: How do you handle concurrency? A: I acknowledge it as a constraint and surface it in Phase 1 ("should I design for thread safety?"). If yes, I add thread-safety notes to the relevant classes. But unless the problem is specifically about concurrency (Tier 5 problems), I scope it as a known limitation.

Q: What if the interviewer asks for a different design mid-way? A: Treat it as a Phase 6 extensibility question. Walk through how the change affects the existing design — is it additive (open/closed) or does it require structural changes? If structural, explain what you'd refactor and why.

Connections to other concepts:

• Phases 1–2 apply OOP pillar thinking: identify entities and their responsibilities.
• Phase 3 applies SOLID principles directly: SRP to assign responsibilities, OCP to choose inheritance vs. composition, LSP to validate inheritance, ISP to define interfaces, DIP to depend on abstractions.
• Phase 4 applies design patterns: the framework assumes you know GoF creational, structural, and behavioral patterns.
• Phase 5 validates that your design is implementable — a design you can't code is not a real design.