What does an object-oriented design (OOD) interview actually test?

Not whether you can recite the twenty-three Gang of Four design patterns. It tests whether you can take a vague, few-sentence prompt — "design a parking lot," "design a vending machine" — and turn it into a small set of classes with clean responsibilities and clean seams between them: objects that each do one thing, relate to each other in ways that make sense, and can absorb the "now also handle X" follow-up without a rewrite. Patterns are vocabulary you reach for when a seam needs one, not the point of the exercise. The signal the interviewer is reading is modeling judgment: did you find the right nouns to make into classes, resist making everything into a class, state the rules that must always hold, and leave room to extend. A candidate who name-drops five patterns but models the domain badly scores worse than one who names none and gets the objects right.

How do you turn requirements into classes in an OOD interview?

Start with the oldest trick in object modeling: read the requirements and underline the nouns and the verbs. The concrete nouns — parking spot, ticket, vehicle, payment — are your candidate classes; the verbs — park, issue a ticket, calculate a fee, assign a spot — are your candidate methods and the relationships between those classes. It is only a candidate list, not the answer, because two honest edits follow. Some nouns are not classes at all: a color or a license-plate string is an attribute of another object, and promoting it to its own class is over-modeling — a real and common failure. And some verbs reveal a relationship rather than living inside one class ("a ticket belongs to a vehicle") which tells you how the objects connect. The nouns/verbs pass gets you a first draft of the model in about two minutes, which you then prune and refine out loud.

Which design patterns actually come up in OOD interviews?

Four earn their keep far more often than the rest. Factory — a single place that decides which concrete class to build, so the rest of the code asks for "a vehicle" without knowing the subtype. Strategy — a family of interchangeable algorithms behind one interface, so a parking lot can swap flat-rate for hourly fee calculation without touching the code that charges. Observer — objects that subscribe to an event and get notified when it happens, so a display board updates when a spot frees without the spot knowing who is watching. And State — an object whose behavior changes with its internal mode, where each mode is its own class and illegal actions are simply refused. Knowing these four cold, and more importantly knowing which seam each one fits, covers the large majority of what an OOD round asks. The rest of the catalog is worth recognizing but rarely worth reaching for under time pressure.

Why is composition preferred over inheritance in object-oriented design?

Because inheritance is the tighter, more brittle coupling, and interviewers watch for candidates who reach for it first. Inheritance says "a Car is a Vehicle" and locks the subclass to its parent's entire shape forever; the classic disaster is a deep hierarchy where "a SportsCar is a Car is a Vehicle" and then the requirements add an electric sports car and the tree has no clean place to put it. Composition says "a Car has an Engine" and "a ParkingLot has a FeeCalculator" — objects hold references to other objects and delegate to them, so you can swap the engine or the fee rule at runtime without disturbing the class that holds it. The guideline "favor composition over inheritance" is old precisely because deep inheritance trees are one of the most reliable ways an OOD design paints itself into a corner. Use inheritance for a genuine, stable is-a relationship; reach for composition — often via the Strategy pattern — for anything that varies.

Why are so many OOD interview problems really state machines?

Because a striking number of the classics — vending machine, elevator, ATM, an order or a document lifecycle, a turn-based game — are objects whose legal behavior depends entirely on what mode they are currently in, and that is the exact definition of a state machine. A vending machine in the "no coins" state must refuse "dispense"; the same machine in the "paid" state must accept it. Modeling that as a pile of boolean flags and nested if-statements is where these designs go wrong: the flags drift out of sync and illegal transitions slip through. Modeling it as an explicit set of named states, with a defined set of transitions between them and a guard on each transition (a condition that must hold for the move to be allowed), makes the illegal moves structurally impossible — the "dispense" event in the wrong state has nowhere to go. Spotting "this prompt is a state machine" early is the single highest-leverage move in an OOD round, because it hands you the whole skeleton of the answer at once.

The OOD Interview, Decoded

The object-design round looks like it wants pattern trivia. It is really grading one thing: can you turn four fuzzy sentences into a handful of objects with clean seams? We make the method legible — the nouns/verbs pass that turns a prompt into candidate classes and methods, composition over inheritance stated honestly, the invariants you say out loud, the four patterns that actually show up in the room (factory, strategy, observer, state) each with a five-line code moment, SOLID trimmed to the letters that earn their keep, and the secret weapon: most OOD classics are state machines wearing a costume. Click the nouns in a live requirements pass, level a design against the classic failures, and leave with the 45-minute LLD script.

Concept · Interview Craft. The source ↗

A free, interactive, animated visual explainer of The OOD Interview, Decoded — built to be understood, not skimmed.

Questions

What does an object-oriented design (OOD) interview actually test?: Not whether you can recite the twenty-three Gang of Four design patterns. It tests whether you can take a vague, few-sentence prompt — "design a parking lot," "design a vending machine" — and turn it into a small set of classes with clean responsibilities and clean seams between them: objects that each do one thing, relate to each other in ways that make sense, and can absorb the "now also handle X" follow-up without a rewrite. Patterns are vocabulary you reach for when a seam needs one, not the point of the exercise. The signal the interviewer is reading is modeling judgment: did you find the right nouns to make into classes, resist making everything into a class, state the rules that must always hold, and leave room to extend. A candidate who name-drops five patterns but models the domain badly scores worse than one who names none and gets the objects right.
How do you turn requirements into classes in an OOD interview?: Start with the oldest trick in object modeling: read the requirements and underline the nouns and the verbs. The concrete nouns — parking spot, ticket, vehicle, payment — are your candidate classes; the verbs — park, issue a ticket, calculate a fee, assign a spot — are your candidate methods and the relationships between those classes. It is only a candidate list, not the answer, because two honest edits follow. Some nouns are not classes at all: a color or a license-plate string is an attribute of another object, and promoting it to its own class is over-modeling — a real and common failure. And some verbs reveal a relationship rather than living inside one class ("a ticket belongs to a vehicle") which tells you how the objects connect. The nouns/verbs pass gets you a first draft of the model in about two minutes, which you then prune and refine out loud.
Which design patterns actually come up in OOD interviews?: Four earn their keep far more often than the rest. Factory — a single place that decides which concrete class to build, so the rest of the code asks for "a vehicle" without knowing the subtype. Strategy — a family of interchangeable algorithms behind one interface, so a parking lot can swap flat-rate for hourly fee calculation without touching the code that charges. Observer — objects that subscribe to an event and get notified when it happens, so a display board updates when a spot frees without the spot knowing who is watching. And State — an object whose behavior changes with its internal mode, where each mode is its own class and illegal actions are simply refused. Knowing these four cold, and more importantly knowing which seam each one fits, covers the large majority of what an OOD round asks. The rest of the catalog is worth recognizing but rarely worth reaching for under time pressure.
Why is composition preferred over inheritance in object-oriented design?: Because inheritance is the tighter, more brittle coupling, and interviewers watch for candidates who reach for it first. Inheritance says "a Car is a Vehicle" and locks the subclass to its parent's entire shape forever; the classic disaster is a deep hierarchy where "a SportsCar is a Car is a Vehicle" and then the requirements add an electric sports car and the tree has no clean place to put it. Composition says "a Car has an Engine" and "a ParkingLot has a FeeCalculator" — objects hold references to other objects and delegate to them, so you can swap the engine or the fee rule at runtime without disturbing the class that holds it. The guideline "favor composition over inheritance" is old precisely because deep inheritance trees are one of the most reliable ways an OOD design paints itself into a corner. Use inheritance for a genuine, stable is-a relationship; reach for composition — often via the Strategy pattern — for anything that varies.
Why are so many OOD interview problems really state machines?: Because a striking number of the classics — vending machine, elevator, ATM, an order or a document lifecycle, a turn-based game — are objects whose legal behavior depends entirely on what mode they are currently in, and that is the exact definition of a state machine. A vending machine in the "no coins" state must refuse "dispense"; the same machine in the "paid" state must accept it. Modeling that as a pile of boolean flags and nested if-statements is where these designs go wrong: the flags drift out of sync and illegal transitions slip through. Modeling it as an explicit set of named states, with a defined set of transitions between them and a guard on each transition (a condition that must hold for the move to be allowed), makes the illegal moves structurally impossible — the "dispense" event in the wrong state has nowhere to go. Spotting "this prompt is a state machine" early is the single highest-leverage move in an OOD round, because it hands you the whole skeleton of the answer at once.

The OOD Interview, Decoded

Questions

Related explainers