Object-Oriented Design Interview Questions And Answers
I've sat on both sides of these interviews for years. The design round isn't about getting one right answer. It's about watching how you think when you don't know the answer yet. Here's how to actually prepare instead of memorizing LeetCode solutions that fall apart the moment they ask you to handle a new constraint. Most people walk into these expecting a test. It's a conversation where you're given an open-ended system to design and they watch you talk through it. A typical question might be something like "Design a parking lot" or "Design a file system" or "Design an elevator." Nothing fancy. The trick is that they'll keep adding requirements mid-interview. Here's a common one that shows up constantly: design a vending machine. I'll walk through how to actually approach it rather than just listing answers.
Start by clarifying requirements. Not by diving into code. Say something like "Is this a basic machine that takes cash only? Or do we need card payments, inventory tracking, restocking alerts?" The interviewer wants to see you ask before you build. When someone immediately starts drawing classes without understanding scope, that's a red flag. For the vending machine specifically, the objects you'll end up with are things like VendingMachine, Product, Inventory, Payment, and ChangeDispenser. But here's what most candidates get wrong: they create a Product class with a single price field and move on. That works until the interviewer says "what about products that are on sale?" or "what about bulk pricing?" The workaround I use is to separate pricing logic from product data entirely. Create a PricingStrategy interface with implementations for FixedPrice, DiscountedPrice, and BulkPrice. This way you can add new pricing models without touching Product at all. I had a candidate once who spent twenty minutes debugging why changing discount logic broke inventory tracking. That happened because pricing and inventory were coupled in the same class.
When asked about the payment flow, don't just say "the machine accepts money." Walk through the state transitions. A vending machine goes through states like Idle, SelectionMade, PaymentReceived, and Dispensing. Each state has valid transitions. Going from Dispensing back to Idle without completing the transaction is a bug waiting to happen. Here's a counter-intuitive point that separates good candidates from great ones: don't over-engineer the first version. Start with the simplest thing that could work. Get a basic path from selection to product dispensing working. Then iterate. I've seen people spend thirty minutes designing a full dependency injection framework before they wrote a single line of actual vending machine logic. That's not impressive. It's avoidance disguised as thoroughness. Another thing nobody talks about: error handling. What happens when the machine runs out of stock but someone still pays? What about when change can't be dispensed? These edge cases are where the real design decisions show. A candidate who proactively mentions "we'd need a refund mechanism when change can't be returned" looks like someone who's actually built things.
Get the Full Details
For the parking lot question, the common pitfall is modeling spaces as individual objects when you should model zones or sections. A real parking lot has hierarchical structure. You don't create 500 ParkingSpace objects for a small lot. You create levels, then sections, then slots. The aggregation matters for both performance and realism. I once interviewed someone who designed a perfect parking lot with vehicle type validation, hourly rates, and license plate recognition. Beautiful design. Then I asked "how does this handle a space that's occupied but the car left three hours ago and the sensor failed?" They had no answer. The design was elegant but brittle. That's the difference between textbook OOP and actual production thinking.
What Interviewers Are Actually Testing
They want to know three things: can you break a problem into objects? Do your objects communicate through interfaces rather than concrete dependencies? And can you change your mind when new information comes up? The last point is huge. The best candidates are the ones who say "that's a good point, let me revise my approach." Rigid adherence to an initial design when the requirements clearly evolved shows stubbornness, not dedication. When they ask about patterns, mention Strategy for extensible behaviors, Observer for notifications like inventory warnings, and Factory when object creation gets complex. But don't name-drop patterns you can't explain. I've seen candidates claim they used the Observer pattern when they literally just added a boolean flag to check if something happened.
The honest truth is that most of these interview questions have no perfect solution. You're being evaluated on how you handle ambiguity, how you structure your thoughts under pressure, and whether you think about tradeoffs. A design that covers 80% of cases with clear acknowledgment of what it doesn't handle will almost always beat a perfect theoretical design that falls apart at the first edge case. One more thing: practice explaining your design out loud. Not on paper, not in code. Out loud. Record yourself. You'll notice when you use vague language like "the system would handle that" instead of actually describing the mechanism. That gap between what you think you said and what actually came out is where interview problems usually hide.
