EngMock Logo
EngMock.com

🧩 OOD guide

How to run a high-quality Object-Oriented Design interview

Modeling responsibilities and boundaries in a real multi-file workspace — not reciting design patterns.
Start a OOD mockAll guides

What this interview tests

  • Whether you can find the right objects and responsibilities from an ambiguous prompt.
  • Whether your public API expresses the domain and protects its invariants.
  • Whether your code stays cohesive and testable as you add behavior across files.
  • Whether you apply patterns because a stated need requires them, not by reflex.

How the session is set up

  • Voice conversation plus a multi-file IDE workspace with a file tree.
  • You may create the classes and files you need, in any supported language.
  • In runnable mode you exercise the design from the main entrypoint and run it.
  • The interviewer never dictates complete classes or finished code.

The interview flow

This track is not phase-gated on a clock, but a strong session moves through these steps in order. Skipping a step is the most common reason a technically correct candidate scores poorly.

1

Clarify scope and invariants

Goal: Agree on the use cases, actors, and rules that must never be violated.

Strong signals

  • You enumerate the concrete operations the system must support.
  • You surface the invariants early, such as "a seat cannot be double-booked".
  • You explicitly defer features that would not fit the time box.

Common mistakes

  • Producing a class list before knowing what the system does.
  • Missing the concurrency or state rule that makes the problem interesting.
  • Designing for imagined future requirements nobody asked for.
2

Identify core objects and responsibilities

Goal: Establish a small set of objects with clear, non-overlapping ownership.

Strong signals

  • Each class has one reason to change and you can say it in a sentence.
  • You separate entities, value objects, services, and coordination logic.
  • You explain collaboration — who calls whom, and who owns which state.

Common mistakes

  • One god class holding all logic and all state.
  • Anemic classes that are just data bags with a separate manager doing everything.
  • Fifteen classes before a single behavior has been implemented.
3

Define the public API and relationships

Goal: Fix the contract before the implementation, and justify structural choices.

Strong signals

  • Method signatures that make illegal states hard to express.
  • You justify composition over inheritance, or an interface, with the need it serves.
  • You name a pattern only after describing the problem it is solving.

Common mistakes

  • Announcing "I will use a Strategy and a Factory" before any requirement demands it.
  • Deep inheritance hierarchies where composition would be simpler.
  • Exposing mutable internal state through getters.
4

Implement the central behavior

Goal: Write the core flow across files while keeping dependencies testable.

Strong signals

  • You implement the most interesting behavior first, not the boilerplate.
  • Dependencies are injected so the behavior can be tested in isolation.
  • Error and invalid-state handling is explicit rather than assumed.

Common mistakes

  • Spending the interview writing getters, setters, and constructors.
  • Hard-coded singletons and static state that make testing impossible.
  • Leaving the hardest rule unimplemented and unmentioned.
5

Validate and discuss trade-offs

Goal: Exercise the design with concrete scenarios and defend your structure.

Strong signals

  • You run or walk through a real scenario including an edge case.
  • You explain how a likely new requirement would be absorbed by the design.
  • You discuss concurrency, persistence, or scaling only where the prompt makes it relevant.

Common mistakes

  • Never executing or walking through the design at all.
  • Claiming extensibility without showing where the extension point is.
  • Bolting on thread-safety talk that the problem never required.

The bar at each level

This is the exact calibration the interviewer and the final report use for OOD.

Junior

A correct basic object model covering the main use cases, with understandable classes and representative validation. Bounded prompts are acceptable.

Mid

Independent decomposition, a clean public API, correct handling of the core invariants, and a credible walkthrough of the main scenarios.

Senior

Independent framing, cohesive responsibilities, well-defended structural choices, robust invariant handling, and a clear extensibility story.

Staff

Ownership of ambiguity and boundaries: interface contracts, evolution and migration paths, concurrency and failure behavior, and maintainability trade-offs across the wider system.

What a high-quality session looks like

  • Responsibilities before classes. Name what changes together before drawing boxes.
  • A pattern is an answer, so state the question first.
  • Implement the hard rule. The interesting invariant carries most of the signal.
  • Design for testability; it is the cheapest proxy for good boundaries.
  • Prefer a small, correct, extensible model over a large, incomplete one.

Red flags that sink interviews

  • A single class that owns all state and all behavior.
  • Pattern names used as justification instead of reasoning.
  • Public mutable state that lets callers break the invariants.
  • No validation of the design against a concrete scenario.
  • Unresolved compilation errors at the end of the session.

Readiness checklist

A mock is most useful when the basics are already in place. If several of these are shaky, study first — the session is meant to test performance, not teach fundamentals.

  • You can explain encapsulation, composition, and interfaces with a real example.
  • You know when inheritance causes more problems than it solves.
  • You have written multi-file code in your chosen language, including imports and entrypoints.
  • You can name the trade-off behind at least three common design patterns.

Where to study the fundamentals

EngMock does not try to replace these. They are the references we would point a candidate to before a real loop.

Refactoring Guru — Design Patterns ↗

Clear explanations of each pattern with the problem it solves.

SOLID principles (Martin) ↗

Baseline vocabulary for responsibility and dependency arguments.

Domain-Driven Design Reference ↗

Useful for entity, value object, and aggregate boundaries.

Other guides

🏗️System Design⌨️Coding / DSA🤖AI-Assisted Coding