What is the low-level design interview round?

A 45-minute whiteboard round where you turn a small, concrete problem — a parking lot, a vending machine, an LRU cache — into classes, interfaces, and state machines. It tests entity modelling, the SOLID principles, and whether you can keep a design small and explicit, rather than raw algorithm speed or large-scale system design.

How is low-level design different from system design?

System design works at the level of services, queues, databases, and the network between them. Low-level design works one zoom level in — the classes inside a single service, their relationships, and the API between them. The same hour, the same whiteboard, a different skill.

What gets graded in an OOD interview?

Entity naming, single responsibility, the open/closed principle, polymorphism instead of long type-check chains, making state explicit with a state machine, and pointing out where concurrency contends. A flawless lock matters less than naming where threads would race.

7 problems

Study path

Object-oriented design

The low-level design round is its own kind of interview. Same hour, same whiteboard, a different skill from the coding round and from system design. Nobody asks you to sort an array or to shard a database. Instead you take a small, concrete problem — a parking lot, a vending machine, an LRU cache — and turn it into classes: name the right entities, draw the relationships, model the state machine, and say out loud which edge cases you would handle. The seven pages below each work one problem the way a strong candidate would in 45 minutes — the requirements, the classes, the interfaces, the watch-outs — so you can practise the shape of the answer, not just the trivia.

The seven problems

Pick one and try to design it before you read the answer.

Each page is roughly 15–20 minutes of careful reading — the requirements, the class diagram, the interfaces, and the edge cases that catch most candidates.

The method

The shape of every OOD answer

The seven pages share a template. In the interview, walk it in roughly this order: clarifying questions, core entities, class diagram, interfaces, the state machine, concurrency, edge cases, extensions. Get the order into muscle memory and the blank whiteboard stops being intimidating.

Clarifying questions. Who uses it? What are the operations? Scale? Failure tolerance? Edge cases? Don't skip — the requirements decide 80% of the design.
Core entities. 4–8 nouns from the problem statement. Each one is a candidate class. Name them before you draw anything.
Class diagram. Boxes, arrows, has-a vs. is-a. Keep it small — the diagram is a conversation aid, not a finished spec.
Interfaces. The public API of each class. Method names, return types, the operations the calling code will reach for.
State machine, if relevant. States, transitions, the table of allowed moves. Vending machines, parking spots, calls — these live or die on state.
Concurrency. What runs at the same time? What needs a lock? Where does eventual consistency hide?
Edge cases. The interesting ones — capacity full, a malformed request, two operations racing for the same resource.
Extensions. "What would you add next?" — shows you can think past the minimum viable design.

The rubric

What an interviewer is actually marking.

Entity naming

Are the classes right? Did you spot the implicit objects hiding in the problem statement?

Single responsibility

Each class does one thing. ParkingLot should not also model Payment.

Open / closed

Adding a vehicle type or a card suit should extend the design, not edit existing classes.

Polymorphism over type checks

Long chains of isinstance checks signal a missing base class or interface.

State explicit

If a thing has states, draw the state machine. "It runs unless it doesn't" is not a state machine.

Concurrency on the page

Naming where threads contend matters more than a flawless lock. "One lock here; per-shard in production" is usually enough.

Where this connects

OOD doesn't sit on its own.

The design patterns you reach for here — state machine, observer, chain of responsibility — come straight from the patterns catalogue. And the moment you zoom out from "classes inside one service" to "services across a network", you're in system design. These two are the natural pages to read alongside this one.

Adjacent path

Design patterns, catalogued

State, observer, strategy, chain of responsibility — the patterns the seven problems lean on, each with the situation that calls for it.

One zoom out

The system-design playbook

When the question grows past one service — queues, caches, replication, partitioning — and the same modelling instinct applies at a larger scale.

Interview hub

Interview prep, all rounds

Where OOD lives alongside the coding-pattern drill, the system-design simulator, concept flashcards, and the levels guide.