Object-Oriented Design Interview Questions 2026 — Machine Coding and LLD

Most engineers who fail an object oriented design interview don't fail because they don't know SOLID. They fail because they write a working parking lot in 45 minutes that has every vehicle type as a switch-case inside a 300-line ParkingLot class — and then the interviewer adds one requirement ("now handle EV charging slots") and the whole design has to be rewritten.

The machine coding round doesn't test whether you can code. It tests whether your code survives contact with the second requirement. That's the lens to bring into every OOD/LLD round — not "does this compile?" but "how much do I rewrite when the problem changes?"

---

What Object Oriented Design Interviews Actually Test (Not What You Think)

The official framing is: class hierarchy, design patterns, SOLID principles. The real framing, from anyone who has run these rounds at Flipkart, Razorpay, or Swiggy, is: can you model a real problem into stable abstractions that survive requirement changes?

Code Design & Structure carries roughly 30% of the score at most Indian product companies. Working functionality — code that actually runs — is 25%. Design patterns and SOLID applied appropriately: 20%. Extensibility: 15%. Edge cases: 10%. That breakdown from machine coding rubrics at companies like Flipkart and Swiggy is load-bearing: a clean skeleton that demonstrates good design scores higher than a fully-working monolith.

The other thing that surprises candidates: object oriented design interviews at these companies are not silent coding sessions. They're design conversations. Razorpay runs live pairing sessions where you narrate your design choices. Swiggy evaluates how you respond to scope changes mid-session. A good design you can't articulate is indistinguishable from a bad design.

---

OOD Interview Questions by Company Type

Not all LLD rounds look the same. Understanding what each company style tests lets you prep specifically.

OOD Interview Question Frequency by Company

| Company | Round format | Time | Primary focus | Typical problem | |---|---|---|---|---| | Flipkart | Machine coding (console app) | 90 min | Extensibility, OOP structure | Expense splitter, parking lot, ride-sharing | | Razorpay | Live pairing / machine coding | 60–90 min | SOLID under pressure, working code | ATM, rate limiter, version control system | | Swiggy | Machine coding + code review | 90 min | Working code + extensibility under change | Food ordering, delivery assignment system | | Coupang | LLD + HLD combined round | 60 min | Object modeling for e-commerce workflows | Order processing pipeline, inventory system | | Walmart Global Tech | LLD + concurrency | 45–60 min | Thread-safety, object-oriented concurrency | News feed (publisher-subscriber), hostel booking | | Stripe | System design (class-level) | 60 min | Clean abstractions for payment primitives | Payment processor, retry/idempotency layer |

The commonality across all six: they want to see interfaces before classes. At every company on this list, candidates who start writing class implementations without defining interfaces first are flagged as a weak signal in the first 10 minutes.

---

SOLID Principles — What Interviewers Look for in Practice

Interviewers don't ask "define SRP." They give you a problem where violating SRP creates an obvious mess — and watch whether you avoid the violation naturally, without being prompted.

Single Responsibility Principle: Each class has one reason to change. The classic violation: a ParkingLot class that handles slot assignment, fee calculation, and SMS notification simultaneously. If you describe a class using "and" — "manages slots and calculates fees and sends alerts" — it's three classes wearing one coat.

Open/Closed Principle: The test is the extension question. At Flipkart, interviewers often add "now handle EV charging slots" 20 minutes in. If your code requires modifying ParkingSlot to add EV-specific logic, you've failed OCP. If EV slots extend an abstract ParkingSlot class and the core allocation logic doesn't change, you've passed. Every new feature should be a new class, not a modified existing one.

Liskov Substitution Principle: The violation most candidates miss: PremiumParkingSlot extends ParkingSlot where PremiumParkingSlot.calculateFee() throws an exception for vehicle types the parent allowed. The practical test: can you substitute any subclass anywhere the parent is used without breaking callers?

Interface Segregation Principle: A fat IVehicle interface with startEngine(), chargeBattery(), foldMirrors(), and playMusic() forces a Bicycle class to implement stub methods it doesn't need. Split by capability: IMotorVehicle, IElectricVehicle, IAudioCapable. Each class implements only what's relevant.

Dependency Inversion Principle: The principle that enables testability. If ParkingLot holds a concrete reference to TwilioSMSService, you cannot test ParkingLot without a live Twilio account. If it holds INotificationService, you inject a mock. At Razorpay, DIP is directly probed: "how would you swap the payment gateway without changing your core domain logic?"

---

Design Patterns That Appear in 80% of Machine Coding Problems

You don't need all 23 Gang of Four patterns. In the machine coding rounds I've evaluated, five patterns show up in at least 80% of problems. Memorizing all 23 and applying the wrong one is worse than knowing five and applying them precisely.

Strategy Pattern — the single most-tested pattern because it directly demonstrates OCP and composition over inheritance. Reach for it whenever you have interchangeable algorithms: fee calculation (hourly, flat, surge-priced), delivery partner assignment (nearest, highest-rated), payment processing (card, UPI, wallet). The signal that impresses: IFeeCalculationStrategy as an interface, HourlyFeeStrategy and FlatRateStrategy as implementations, injected via constructor. The caller (ParkingLot, OrderService) never changes when you add a new strategy.

Observer Pattern — for event-driven state changes with multiple downstream consumers. In Swiggy's machine coding problems, the food delivery order lifecycle almost always needs this: status change in Order → CustomerNotificationObserver, DriverAssignmentObserver, RestaurantKitchenObserver all fire independently. Subject interface with subscribe, unsubscribe, notifyObservers. Adding a fraud detection observer requires zero changes to Order.

Factory / Abstract Factory Pattern — for object creation that depends on runtime input. Callers never call new ConcreteClass() directly. They call VehicleFactory.create(VehicleType.EV). Adding a new vehicle type is one new class plus one factory line — existing code untouched.

State Pattern — less common, but when a problem needs it, it's the central design challenge. ATM machines (IDLE → CARD_INSERTED → PIN_ENTERED → AUTHENTICATED → DISPENSING), vending machines, order lifecycle. The failure shows up when the interviewer asks "what happens if dispenseItem() is called on a vending machine in IDLE state?" With enum + switch-case, you get a buried runtime check. With State pattern, each concrete state class only implements valid operations — invalid calls are structurally impossible.

Command Pattern — for operations that need rollback, queuing, or audit logging. Booking cancellations, undo/redo, payment idempotency. Less common in machine coding rounds, more common when the interviewer asks "how would you handle partial failures?"

---

The 8 Machine Coding Problems That Appear Most Often

These are the problems that show up in Tier 1 frequency across Flipkart, Razorpay, Swiggy, Coupang, and Walmart interview reports as of 2026.

High-Frequency OOD Machine Coding Problems

| Problem | Companies | Core design challenge | Pattern to reach for | |---|---|---|---| | Parking Lot | Amazon, Flipkart, Walmart | Multi-type slots, extensible vehicle types | Strategy (fee), Factory (vehicle), State (slot) | | Food Delivery System | Swiggy, Coupang, Zomato | Order state machine + assignment | State (order), Observer (notifications), Strategy (matching) | | Expense Splitter (Splitwise) | Flipkart, CRED | Settlement algorithm, group dynamics | Strategy (split type), Observer (balance updates) | | Vending Machine | Razorpay, Walmart, Google | State transitions, inventory | State (machine), Factory (items) | | ATM Machine | Razorpay, TCS, Infosys | Security states, cash denomination | State (ATM), Command (transactions) | | Ride-Sharing (Uber/Ola) | Swiggy, Coupang, Ola | Real-time matching, ride lifecycle | State (ride), Strategy (matching), Observer (updates) | | Library Management | Walmart, Amazon SDE-1/2 | Book vs copy distinction, reservations | Observer (waitlist), Command (borrow/return) | | Rate Limiter | Razorpay, Swiggy, Stripe | Algorithm choice (token bucket vs sliding window), thread safety | Strategy (algorithm), Singleton (registry) |

The most important non-obvious insight about the Parking Lot problem: Every interviewer has seen 50 parking lot solutions. The ones that stand out are not the ones with the most features — they're the ones where adding EV charging requires zero modifications to existing classes. Design for the extension the interviewer hasn't mentioned yet.

On the Food Delivery System: The hard part isn't the happy path. It's the order state machine. Use an explicit State pattern — not a sequence of booleans (isConfirmed, isPreparing, isPickedUp). Boolean state is unordered by definition: nothing prevents an order from being simultaneously isPickedUp = true and isConfirmed = false. A State machine makes invalid states structurally impossible.

On the Rate Limiter: This is a Razorpay and Stripe favorite because it tests algorithm knowledge (token bucket, leaky bucket, fixed window, sliding window log — each with different accuracy-vs-memory tradeoffs) and concurrency (what happens when two requests arrive simultaneously — you need atomic operations on the counter). At Stripe-style interviews, expect to also discuss idempotency: a rate limiter that counts duplicate retries as separate requests is broken.

---

The Mistake That Fails 40% of Otherwise-Strong Candidates

Here's the pattern I see most often in machine coding failures: the candidate has solid OOP knowledge, designs reasonable classes, applies Strategy or Observer correctly — and then models state as an enum + a cascade of if/else blocks spread across five methods.

The code works. The tests pass. Then the interviewer says: "What happens if confirmOrder() is called after the order is already in DELIVERED state?" And the candidate's answer involves tracing through three methods to find which if block handles that edge case.

The right answer is that invalid state transitions should not be possible by construction — not checked at runtime in scattered conditionals.

The production consequence of getting this wrong is real. Swiggy's engineering team has documented cases where order state bugs — orders stuck in limbo between PREPARING and PICKED_UP — caused delivery partner payouts to fail silently. The root cause was almost always a boolean-flag state model that allowed partial state updates. A proper State pattern with explicit transition methods (order.confirmPickup() only callable from PreparingState) makes this class of bug impossible.

Composition over inheritance is the other consistently wrong default. The reflex for many candidates is to reach for inheritance when modeling a hierarchy — ElectricVehicle extends Vehicle, PremiumElectricVehicle extends ElectricVehicle. Three levels of inheritance in and you've got method resolution that even you can't trace. Prefer composition: a Vehicle has a ChargingCapability (or doesn't), has a PremiumFeePolicy (or doesn't). Capability injection via interfaces keeps the hierarchy flat and the behavior modular.

---

How India's Product Unicorns Run LLD Rounds (What No Generic Guide Covers)

The India-Specific OOD Interview Breakdown

Flipkart (SDE-2/SDE-3): 90 minutes, no IDE hints, produce a working console application. Interviewers add one scope extension mid-session (20–30 minutes in) specifically to test whether your design bends or breaks. The Splitwise-style expense splitter is reported frequently for SDE-2, with the extension "now support unequal splits by percentage." Candidates who hardcoded equal-split into the core Group class fail here.

Razorpay (SDE-2 and above): The most SOLID-explicit company in this list. Interviewers will pause mid-session and ask "which principle does this decision follow?" They want design rationale articulated, not just coded. The ATM state machine is frequently reported, with the concurrency twist: "now handle two users accessing the same account simultaneously" — requiring both the State pattern and thread-safe transitions (ReentrantLock in Java, asyncio.Lock in Python).

Swiggy (SDE-2/SDE-3): Uniquely combines a machine coding session with a follow-up code review. You write the solution, then the interviewer reads your code and asks: "Why Observer instead of a direct callback?" "What breaks if we add a fourth restaurant type?" Candidates who applied patterns without knowing why get exposed in the review.

Coupang (Senior SWE / L5): LLD often combined with HLD in 60 minutes. Focus on e-commerce workflow object modeling — order processing, inventory, return flows. Bengaluru-office pattern (2025 reports): design order processing, then extend it for cross-border orders with customs calculation. Tests whether Order → OrderProcessor is extensible via Strategy or requires touching core logic.

Walmart Global Tech (Bengaluru, SDE-2/3): Adds a concurrency angle others don't. The live news feed (publisher-subscriber) problem is frequently reported, with follow-up: "make this thread-safe for 10,000 concurrent users." Requires CopyOnWriteArrayList for observer lists or explicit synchronization. Pure OOP candidates without concurrency knowledge get filtered.

---

The 45-Minute OOD Framework That Works Across All Companies

This is the sequence to internalize until it's automatic:

Minutes 0–5: Requirements and boundary setting. Ask: What are the 3 core use cases? Any specific scale I should design for? Any extensions you'd like me to design toward? Do not start coding yet. The 5 minutes of clarification saves you from building the wrong thing — and signals a senior engineering mindset to the interviewer.

Minutes 5–15: Define interfaces and entities. List the nouns (entities) and behaviors (interfaces). Write interface definitions before concrete classes. At the end of this phase you should have: named interfaces, entity relationships sketched (has-a / is-a), and the one design pattern you're going to anchor the design on. Still no implementation.

Minutes 15–30: Implement the happy path. Code the primary use case end-to-end. Focus on correct class relationships and interface implementations. Skip edge cases and error handling — you'll add those in the next phase. At the 30-minute mark, the interviewer should be able to run your code against the primary use case.

Minutes 30–42: Extensions and patterns. Add the design pattern you identified (State machine for lifecycle objects, Strategy for interchangeable algorithms, Observer for event-driven notifications). Handle the extension the interviewer raised in requirements. Add basic error handling.

Minutes 42–45: Design review. Walk through your design verbally. Explain one key trade-off: "I used Strategy for fee calculation because the business changes pricing rules frequently — adding a new tier is a new class, not a code change." Proactively mention what a production version would add: thread-safety, persistence layer, monitoring.

---

What to Practice and In What Order

The machine coding round rewards pattern recognition from solved problems — but only if you solved them yourself under time pressure. Reading solutions builds zero intuition. Building 8–10 complete applications under time constraints builds the muscle memory the interview tests.

The recommended sequence, ordered by concept coverage per problem:

1. Parking Lot — covers Factory (vehicle types), Strategy (fee calculation), core OOP relationships. The "hello world" of machine coding.
2. Vending Machine — covers State pattern completely. Build it twice: once with enum + switch-case, once with State pattern. The contrast is the lesson.
3. Food Delivery (Swiggy model) — covers Observer (notifications), State (order lifecycle), Strategy (partner assignment). Three patterns in one problem.
4. Expense Splitter (Splitwise) — covers Strategy for different split algorithms, graph-based settlement. More algorithmic than the others — bridges OOD and DSA.
5. ATM Machine — covers State + concurrency. Add ReentrantLock around state transitions for thread-safety practice.
6. Rate Limiter — covers algorithm knowledge (token bucket vs sliding window) + concurrency + Strategy. Directly applicable at Razorpay and Stripe.

If you want structured machine coding practice with class diagram walkthroughs and AI grading on your design choices, the LLD / Low-Level Design module on KnowEase covers all 25 of these problems with SOLID principle breakdowns and step-by-step solutions. For the full SDE interview picture — including how LLD connects to HLD rounds — the system design interview guide for product companies covers the combined prep path.

---

5 Object Oriented Design Interview Questions with Full Answers

These are the conceptual questions interviewers ask after the machine coding session to probe your design thinking.

Q: How would you decide between inheritance and composition?

Default to composition. Use inheritance only when you have a genuine is-a relationship and need to share stable implementation across multiple classes. If you're inheriting purely for code reuse, you're coupling classes that will diverge later. Composition says "this object has a capability" rather than "this object is a type of X" — capabilities can be swapped or removed independently. The Vehicle with a ChargingCapability interface is more extensible than ElectricVehicle extends Vehicle extends LicensedVehicle.

Q: What's wrong with making every service a Singleton?

Singletons couple every caller to a concrete implementation, making unit tests impossible without hacks. They also introduce hidden global state — any method anywhere can modify the Singleton's state, making concurrency bugs invisible. Use Singletons for truly stateless utilities (a connection pool, a logger registry). For anything with domain logic — a PaymentService, a NotificationService — inject via interface.

Q: When does Command pattern beat a direct method call?

When you need undo/redo (the Command captures enough state to reverse), queuing (Commands serialize and replay), or audit logging. In payment processing, every transaction is a Command with an idempotency key — if received twice (network retry), the second execution is a no-op. This is the Stripe pattern: PaymentCommand carries an idempotency_key, the Command executor rejects duplicates before they reach the payment processor.

Q: What's the difference between Abstract Factory and Factory Method?

Factory Method: one creator method that subclasses override to produce different concrete types. Abstract Factory: a family of factories that create families of related objects that must be consistent together — a UIThemeFactory creates Button, TextField, and Dropdown objects all styled to the same theme. If you're creating individual unrelated objects, Factory Method is simpler and sufficient.

Q: How do you design a notification system where the channel list keeps growing?

Factory Pattern for creation: NotificationFactory.create(channel) instantiates the right INotificationSender without the caller knowing the concrete class. Observer Pattern for triggering: OrderService is a subject; each notification channel registers as an observer. When order.updateStatus(DELIVERED), all observers fire independently. Adding WhatsApp is one new class plus one factory registration — zero changes to OrderService or existing channels.

---

The direction OOD interviews are moving is worth noting: as more companies shift to AI-assisted coding tools in production, the interview bar has moved up on design quality, not down. Interviewers know that a candidate with Copilot can get to working code faster — so they're more specifically testing whether you understand why you're making each design decision, not just whether the code compiles. The engineer who can explain "I chose Observer here because future notification channels shouldn't require touching the order domain" is the one getting the offer. That clarity comes from building real systems and failing at the wrong abstractions a few times. The interview is checking whether you've already paid that tuition.