How to Handle an Object-Oriented Design Interview Step by Step

An object-oriented design interview tests whether you can turn a loose problem into clear responsibilities, sensible interfaces, and code that can change without collapsing. The safest approach is to clarify the scope, name the core use cases, assign behavior to objects, sketch their relationships, and then test the design against one normal flow and one change request. You do not need a perfect class diagram; you need a design you can explain and revise.

What is an object-oriented design interview actually testing?

The interviewer is watching how you make design decisions at code level. A system design round asks about services, storage, traffic, reliability, and distributed trade-offs. An object-oriented design round, sometimes called low-level design, moves closer to classes, interfaces, state, and collaboration between objects. If you are also preparing for the broader architecture round, use this system design interview study plan separately so the two formats do not blur together.

Most prompts sound deceptively small: design a parking lot, elevator, library, card game, vending machine, or ride-booking component. The real task is to decide what belongs in the first version and show that your model can handle likely changes. An interviewer may ask you to write method signatures or a few important classes, but a long production-ready implementation is rarely the best use of the round.

Strong candidates make their reasoning visible. They ask which actors matter, identify the behaviors that must work, choose where state lives, and explain why one object owns a decision instead of another. They also notice where requirements are still uncertain. Naming that uncertainty is better than quietly building around an assumption.

How should you divide a 45-minute OOD round?

Use time boxes as a steering aid, not a rigid script. If the interviewer wants code early, adapt, but keep the same decision order.

Time	Focus	What you should produce
0-5 minutes	Clarify scope	Actors, core use cases, constraints, and explicit exclusions
5-10 minutes	Build the model	Main objects, their responsibilities, and important state
10-20 minutes	Define behavior	Public methods, object relationships, and one happy-path flow
20-33 minutes	Deepen the design	Key classes or interfaces, validation, and error handling
33-40 minutes	Test changeability	One edge case and one new requirement
40-45 minutes	Review	Trade-offs, missing pieces, and the next thing you would implement

This sequence protects you from a common failure: spending twenty minutes naming classes before confirming what the product must do. It also creates natural checkpoints where the interviewer can correct your direction without forcing a complete restart.

Which questions should you ask before drawing classes?

Start with behavior and boundaries. For a parking-lot prompt, ask whether the system serves one location or several, which vehicle and spot types exist, how entry and exit work, whether reservations are included, and whether pricing or payments are in scope. Four useful question types cover most prompts:

• Who uses the system, and what outcome does each actor need?
• Which two or three use cases must work in this round?
• Which constraints change the model, such as capacity, concurrency, or multiple locations?
• What can we explicitly leave out of the first version?

Do not interrogate the interviewer for every detail. Ask the questions that change your classes or APIs, state your smaller assumptions, and move forward. A good transition sounds like this: "I will model one parking facility with cars and motorcycles, automatic ticket creation at entry, and payment at exit. I will leave reservations out unless you want that included".

That short summary gives the interviewer a chance to correct the scope. It also proves that you can convert a conversation into a working contract before you start designing.

How do you turn requirements into objects without making a noun list?

Pull candidate concepts from the prompt, then test each one for responsibility. A noun deserves to become an object when it owns meaningful state or behavior. A term that only carries two values may be a value object. A term that merely describes a calculation may belong as a policy behind an interface rather than as a large entity.

Use this progression:

1. Write the core use cases as verbs, such as admit a vehicle, assign a spot, issue a ticket, calculate a fee, and release a spot.
2. Find the information each action needs and the state it changes.
3. Give each decision a clear owner. The facility may find a compatible spot, while a pricing policy calculates the charge.
4. Define public methods from the use cases instead of exposing every field.
5. Walk through one request from the caller to the final state change and remove objects that do no real work.

This is where many memorised solutions go wrong. They start with familiar class names and force the prompt into a diagram they have seen before. Your design should grow from the agreed behavior. Patterns can help after a variation appears, but announcing a pattern before the problem demands it often adds ceremony.

What does a worked parking-lot design look like?

Assume one facility accepts cars and motorcycles. A driver receives a ticket on entry, pays on exit, and the system must never assign the same spot twice. Reservations, lost tickets, and multiple facilities are outside the first scope.

The core entities can be Vehicle, ParkingSpot, and Ticket. Vehicle carries an identifier and a type. ParkingSpot owns its spot type and occupancy state. Ticket records the vehicle, assigned spot, entry time, and lifecycle status. ParkingLot coordinates entry and exit, but it should not absorb every rule.

A small SpotAssignmentPolicy can choose a compatible available spot. A PricingPolicy can calculate a fee from ticket data. Those interfaces earn their place because the prompt has obvious variations: a facility may prefer compact spots first, and pricing may differ by location or time. The entities remain readable while changeable decisions stay replaceable.

Your entry flow might sound like this: the gate calls ParkingLot.enter(vehicle). The lot asks the assignment policy for a spot, marks that spot occupied, creates an active ticket, stores it, and returns it. If no compatible spot exists, it returns a named failure instead of a half-created ticket. On exit, the lot retrieves the active ticket, asks the pricing policy for the charge, records payment, releases the spot, and closes the ticket.

The ordering matters. If ticket storage fails after the spot becomes occupied, the system needs to roll back that state or perform the operation inside one transaction boundary. You do not need to build the persistence layer, but you should notice the consistency problem. Saying "I want spot assignment and ticket creation to succeed or fail together" is more valuable than decorating the diagram with database classes.

When the interviewer asks for a change, use it to test your boundaries. Adding electric-vehicle charging might introduce a capability on selected spots rather than a new branch throughout the code. Adding weekend pricing should require another pricing policy, not edits to Vehicle, Ticket, and the exit gate. If one request touches half the model, explain what you would reshape.

Should you use inheritance, composition, or a design pattern?

Prefer composition when behavior may vary independently. A parking lot can hold a PricingPolicy; it does not need subclasses such as WeekendParkingLot, AirportParkingLot, and HolidayAirportParkingLot. Composition keeps the stable concept separate from a rule that changes.

Inheritance fits a genuine subtype relationship with a stable shared contract. Even then, ask whether the subclasses behave differently or merely carry different data. If car and motorcycle only affect compatible spot size, an enum or value type may be enough. Creating a subclass for every label produces code that looks formal without making change easier.

Use SOLID principles as diagnostic questions. Does one class have several reasons to change? Can callers depend on a small interface? Would a new variation require editing a central conditional? You do not need to recite five definitions. Apply the principle to a decision in front of you and explain the trade-off.

Patterns work the same way. Strategy is useful for pricing or assignment because those rules vary. Factory can help when object creation is genuinely complex. Observer may fit a notification requirement. A pattern should solve a requirement you can point to; it should not be a badge added to impress the interviewer.

How much code should you write during the interview?

Ask what level of implementation the interviewer expects. If they want a design discussion, write interfaces and one important flow. If they want executable code, agree on which slice to complete rather than trying to implement the whole system.

Start with signatures that expose your decisions:

Ticket enter(Vehicle vehicle)
Receipt exit(TicketId ticketId, Payment payment)
Optional<ParkingSpot> findSpot(Vehicle vehicle)
Money calculatePrice(Ticket ticket, Instant exitTime)

Then implement the path with the most design value. For the parking lot, that is usually entry or exit because it crosses policies, state changes, and failure cases. Keep domain rules close to the objects that own them, use names that reflect the interview vocabulary, and avoid spending time on getters, framework setup, or boilerplate.

Talk while you code, but do not narrate every keystroke. Explain the reason for a branch, the invariant you are protecting, or the alternative you considered. The same habits in these live coding interview tips help when the round shifts from a diagram to an implementation.

What mistakes weaken an otherwise reasonable design?

The first is designing in silence. The interviewer cannot score reasoning they never hear, and they cannot redirect assumptions they do not know about. Give short summaries at each transition: scope, model, main flow, and trade-offs.

The second is building a god object. If ParkingLot finds spots, calculates prices, processes payments, sends notifications, and formats receipts, every new rule changes the same class. Split a responsibility only when you can name the separate reason it changes.

The third is premature abstraction. Five interfaces around one fixed calculation make the design harder to read. Begin with the simplest boundary that supports the stated variation, then extract another seam when the interviewer introduces a new rule.

The fourth is ignoring failure and state transitions. Ask what happens when capacity is full, a ticket is already closed, payment fails, or two entry gates request the last compatible spot. You can describe locking or a transaction boundary without implementing infrastructure. What matters is recognizing the invariant and placing responsibility for protecting it.

How do you recover when the interviewer challenges your design?

Treat the challenge as new information. Restate it, identify which assumption changed, and trace the smallest affected area. You might say, "Supporting reservations means availability is no longer the same as unoccupied, so I would introduce a spot-allocation service that considers both current occupancy and reservation windows".

Do not defend an early diagram as if changing it proves you failed. Revision is part of the test. Keep names readable, cross out or replace a relationship clearly, and explain what remains stable. If your first model put pricing inside Ticket, moving it behind PricingPolicy after a location-specific rule appears demonstrates judgment.

If you become stuck, return to one use case. Walk through the caller, required data, decision owner, state change, and returned result. That concrete path usually reveals the missing responsibility. Hiintly can help you practise explaining that reasoning aloud: its free 10-minute live session becomes available again after a 5-minute cooldown, which is enough for repeated scope-and-model drills without rehearsing a fixed script.

How should you practise before the interview?

Choose three prompts with different pressure points: a parking lot for assignment and state, a vending machine for transactions and failure recovery, and a card game or library for domain rules. Give yourself 45 minutes for the first attempt, then repeat only the weak stage.

After each mock, score whether you clarified scope, named the core use cases, gave each decision one owner, walked a full flow, handled one failure, accepted a change request, and explained at least one trade-off. Record yourself if possible. You will hear where explanations become vague or where class names appear before the requirement that justifies them.

Your final preparation should focus on transfer, not memorisation. Change one requirement in every prompt and see whether the design bends in one place or breaks everywhere. The goal is to enter the interview with a repeatable way to think, speak, and revise when the prompt is unfamiliar.