Object-oriented design interview (low-level design): a complete guide

A six-step approach

1. Clarify requirements and scope: what must the system do, and what is out of scope?
2. List the main use cases and actors.
3. Identify the core objects (nouns) and their responsibilities.
4. Define relationships: inheritance, composition, association, interfaces.
5. Write the key methods and walk through one use case end to end.
6. Discuss extensions: new types, concurrency, persistence, edge cases.

The classic problems

Our worked parking lot design shows the approach applied end to end.

Principles interviewers listen for

• Single responsibility: a ParkingSpot shouldn't calculate fees; a FeeCalculator should.
• Open/closed: adding an electric-vehicle spot shouldn't require editing existing classes — use an interface or a strategy.
• Composition over inheritance: a Vehicle has a size; deep inheritance trees for every vehicle type are brittle.
• Interfaces at boundaries: PaymentMethod as an interface lets cash, card and app payments vary independently.
• Encapsulation: state changes go through methods that enforce rules, not public fields.

Design patterns that come up

You don't need to name patterns to do well, but recognising them speeds you up. Strategy fits interchangeable algorithms such as pricing or spot allocation. State fits objects whose behaviour depends on their mode, such as a vending machine or an elevator. Factory creates objects of the right subtype. Observer notifies interested parties, such as displays when spots fill. Singleton comes up but is often a smell; mention its testing costs if you use it. See design patterns interview questions.

Drawing it quickly

You don't need formal UML, but a consistent shorthand saves time on a whiteboard or shared doc. Write each class as a box with its name, its key fields and its key methods. Draw a plain line with an arrow for “uses”, a hollow triangle arrow for “is a” (inheritance or implements), and a filled diamond for “owns” (composition, where the part cannot exist without the whole). Mark multiplicities such as 1 and * on the lines. Keep the first diagram to five or six classes; add detail only where the interviewer wants to go deeper. A tidy small diagram that you walk through with one use case communicates far more than a sprawling one.

Machine coding rounds

Some companies, particularly in India, run a “machine coding” variant: 60 to 120 minutes to implement a working, modular solution, often with a command-line interface and tests. The emphasis shifts to clean, extensible code that actually runs. Keep classes small, separate the domain model from input handling, and get a minimal end-to-end path working before adding features.

Concurrency and edge cases

Strong candidates raise concurrency before being asked: two cars arriving for the last spot, two people booking the same seat. Explain where you'd lock, or how an atomic operation or a database constraint would prevent double allocation. Also cover invalid input, capacity limits and what happens on failure mid-operation.

What separates strong answers

Practising

Work through the classic problems with a timer, out loud, then compare with a reference design and note what you missed. Do at least two as machine coding exercises in your interview language. A free AI interview assistant such as CoPilot Interview can play the interviewer and push follow-ups like “now add electric-vehicle charging”. See also OOP interview questions.

Disclosure: CoPilot Interview is our product, so weigh what we say about it accordingly. Everything else on this page applies whichever tool you use, or none.

Frequently asked questions

What is a low-level design interview?

A round where you model a system as classes, interfaces, relationships and methods — such as a parking lot or elevator — and sometimes implement it, with attention to clean responsibilities, extensibility and edge cases.

How is low-level design different from system design?

System design covers distributed architecture: services, databases, scaling and availability. Low-level design zooms into one component's classes, methods and interactions.

Do I need to know design patterns for OOD interviews?

Recognising common patterns such as Strategy, State, Factory and Observer helps, but clear responsibilities and good trade-off explanations matter more than naming patterns.

What is a machine coding round?

A timed exercise, typically 60 to 120 minutes, where you implement a working, modular solution to a design problem, often with tests. It emphasises clean, runnable code over diagrams.