How to Approach an Object-Oriented Design Interview

Description

The classic object-oriented design problems - a parking lot, a library, Splitwise, an elevator, a movie booking system - are less about any one pattern than about running the round well: clarifying scope, modeling the domain, getting a thin slice working, and absorbing the follow-up requirement the interviewer adds halfway through. This skill is the playbook for that round; the project skills that follow apply it to each classic problem.

An object-oriented design round hands you a prompt - "design a library system", "build Splitwise", "implement a parking lot" - and 60 to 120 minutes to produce working code in an editor. Two ways to fail it are far more common than not knowing a pattern:

// Minute 75 of 90: a thorough design with nothing that runs
interface Notifier {}                       // "for later"
abstract class AbstractBookFactory {}       // one kind of book exists
class LibraryFacadeBuilder {}               // builds... a facade
class Library {
    // TODO borrow
    // TODO giveBack
}

# Minute 75 of 90: a thorough design with nothing that runs
class Notifier(ABC): ...                    # "for later"
class AbstractBookFactory(ABC): ...         # one kind of book exists
class LibraryFacadeBuilder: ...             # builds... a facade
class Library:
    pass
    # TODO borrow
    # TODO give_back

The other failure is the mirror image: one 600-line class that parses input, applies the rules, stores everything in parallel lists and prints results - it runs, but the first follow-up ("now members can reserve books") means editing every method. Graders rarely fail you for missing a clever optimization. They fail you for code that doesn't run, or that can't absorb a change.

We'll go from simple to more technical:

1. The five steps and a time budget for a 90-minute round.
2. The pieces that pay off in every round: packages, in-memory storage, an injected clock, a demo.
3. How rounds are graded.
4. The classic failure modes, and the tradeoffs to state out loud.

The five steps

The same five steps work for every prompt; the time budget below assumes a 90-minute round.

• Clarify by asking about operations and rules, not UI: Which operations? What limits? What happens when a book is already on loan - return a value or throw? Is it concurrent? Is persistence needed, or is in-memory fine? Write the answers at the top of your file; they're your spec.
• Model from the operations: the nouns that carry state or identity become classes, closed sets become enums, and one service or facade owns the rules. A subclass hierarchy earns its place only when behavior differs.
• Build the core around the hot operations: pick structures that make them cheap (a map from ID to object, a free list, a running count when reads far outnumber writes), and keep them private.
• Extend where the interviewer pushes - they will add a requirement mid-round. A design with the varying part behind an interface absorbs it with a new class.

The pieces in code

Packages make the design visible at a glance; a thin slice makes it real. For a library:

library/
  model/        Book, Loan                      (records: value types)
  repository/   LoanRepository                  (interface)
                InMemoryLoanRepository          (a HashMap - no database in the round)
  service/      LibraryService                  (the rules)
  Main.java                                     (the demo you run)

public class LibraryService {
    private final LoanRepository loans;
    private final Clock clock;                       // injected: tests and demos fix "now"

    public LibraryService(LoanRepository loans, Clock clock) {
        this.loans = loans;
        this.clock = clock;
    }

    public Loan borrow(String isbn, String memberId) {
        if (loans.findByIsbn(isbn).isPresent()) throw new IllegalStateException(isbn + " is already on loan");
        Loan loan = new Loan(isbn, memberId, LocalDate.now(clock).plusDays(14));
        loans.save(loan);
        return loan;
    }
}

from collections.abc import Callable
from datetime import datetime, timedelta


class LibraryService:
    def __init__(self, loans: LoanRepository, now: Callable[[], datetime]):
        self._loans = loans
        self._now = now                                  # injected: tests and demos fix "now"

    def borrow(self, isbn: str, member_id: str) -> Loan:
        if self._loans.find_by_isbn(isbn) is not None:
            raise RuntimeError(f"{isbn} is already on loan")
        loan = Loan(isbn, member_id, self._now().date() + timedelta(days=14))
        self._loans.save(loan)
        return loan

public static void main(String[] args) {
    Clock clock = Clock.fixed(Instant.parse("2026-03-01T10:00:00Z"), ZoneOffset.UTC);
    LibraryService library = new LibraryService(new InMemoryLoanRepository(), clock);
    System.out.println(library.borrow("978-0134685991", "m-7"));   // Loan[..., due=2026-03-15]
}

def main() -> None:
    fixed = datetime(2026, 3, 1, 10, 0, tzinfo=timezone.utc)
    library = LibraryService(InMemoryLoanRepository(), now=lambda: fixed)
    print(library.borrow("978-0134685991", "m-7"))   # Loan(..., due=datetime.date(2026, 3, 15))


if __name__ == "__main__":
    main()

In Python the same layout is a package - library/model.py (frozen dataclasses), library/repository.py (an abstract base class or a Protocol, plus a dict-backed class), library/service.py, and a library/__main__.py you run with python -m library.

Three choices here pay off repeatedly in rounds:

• Storage behind an interface, implemented with a Map. Nobody expects a database in 90 minutes, and "it's a HashMap today, a JPA repository tomorrow" is a design point you can show rather than claim.
• An injected Clock (or Supplier<Instant>; in Python, a now: Callable[[], datetime]) instead of LocalDate.now() scattered through the rules. Anything with due dates, expiry, rate windows or schedules becomes testable - you can demo "15 days later" without waiting.
• A Main that exercises the happy path and one rejection. It proves the pieces connect, catches integration mistakes early, and gives the interviewer something to run.

How the round is graded

Most object-oriented design rubrics - at companies that run these rounds for backend roles - score roughly the same things, in roughly this order:

1. It works: the required operations run, and the demo or tests show it.
2. Structure: sensible classes and packages, each with one reason to change; no god class.
3. Extensibility: the follow-up requirement fits without rewriting working code.
4. Correctness under edge cases: bad input is rejected clearly, invariants hold, failures change nothing.
5. Communication: you stated assumptions, tradeoffs and what you'd do with more time.

Clever optimizations and exotic patterns aren't on the list - they only count when a requirement needs them.

Which tool for which job?

Common mistakes

Check yourself

Try to answer before opening each one - recalling beats re-reading.

1. At minute 60 of 90 you have a clean class diagram and interfaces, but nothing compiles end to end. What should you do next?

2. Why inject a Clock into a service that computes due dates, instead of calling LocalDate.now() inside it?

3. Halfway through, the interviewer says: "Members can now also reserve a book that's on loan." Your borrow method is the only place that knows about availability. What's the good response?

Key takeaways

• The round grades working, readable, extensible code - in that order. A thin slice that runs beats a complete design that doesn't.
• Clarify operations and rules first; model from the operations; agree the API before coding.
• Packages plus a Main demo make the design visible; in-memory repositories and an injected Clock keep it testable.
• Add patterns only where the requirements vary - and expect the interviewer to add a requirement mid-round.
• State assumptions and tradeoffs out loud: what's out of scope, what production would add, where concurrency would bite.