Formats an LLD interview can take

13 min read · last reviewed 2026-10-17

Open in the interactive app: practice, quiz, mock interview →

In one minute

"Low-level design interview" covers several formats that test different things: the whiteboard object-oriented design round, the machine coding round, the component or API design round, the extend-or-refactor round, and the concurrency round. Take-homes and AI-assisted rounds are variations on these.
The formats differ in one dimension above all: how much running code is expected. A whiteboard round grades the model and the reasoning; a machine coding round grades working, readable, extensible code in 60 to 120 minutes.
Every format hides a curveball: a second requirement arrives late ("now add nested transactions", "now support two elevators"). The interviewer is measuring how much of your design has to change.
The winning habit is the same everywhere: pin the requirements, name the entities and invariants, build the smallest core that runs, then extend through the seams you planned.
With AI assistants now allowed in some rounds, the grade moves from typing speed to judgment: what you ask for, what you reject, and whether you can explain every line.

How it works

The whiteboard object-oriented design round

The classic prompt is "Design a parking lot" or "Design an elevator system", with 45 to 60 minutes, a whiteboard or a shared document, and little or no compiled code. You clarify requirements, identify entities, draw a class diagram, walk through one or two flows with a sequence diagram, and discuss which patterns fit and why. Interviewers grade the domain model (are the responsibilities in the right classes?), the handling of edge cases (a full lot, a vehicle that leaves without paying), and how the design absorbs a change. This course's design lessons follow this format: Design Parking Lot, Design Elevator System, Design Vending Machine, Design Movie Booking System. Class Diagram and Sequence Diagram cover the notation you will draw.

The machine coding round

Here the deliverable is a program that runs. You get a written problem statement (a snake and ladder game, a Splitwise clone, an in-memory key-value store with transactions), 60 to 120 minutes, your own IDE, and usually no database or network: everything is in memory, driven by a main or by tests. Often a 30-minute review follows, in which the interviewer reads the code, asks for a new feature and watches how many files you touch.

Graders look at, in order: does it run; is it modular (no 400-line main); does the late requirement fit without a rewrite; is it readable; is it tested. Over-engineering costs as much as under-engineering: 40 minutes on an abstract factory and no working get is a fail. Design Snake and Ladder, Design Tic Tac Toe and Design Splitwise are good rehearsal problems.

The component or API design round

A narrower prompt: "Design an LRU cache", "Design a rate limiter", "Design a logging framework", "Design a task scheduler". The scope is one library-sized component with a precise API and performance target ("get and put in O(1)"). Expect to write the core data structure, state its complexity, and discuss thread safety and configuration. Design LRU Cache, Design Rate Limiter, Design Logging Framework, Design Task Scheduler and Design Bloom Filter are this shape. The trap is spending the round on class hierarchy when the interviewer wanted the data structure.

The extend-or-refactor round

You are handed existing code, often deliberately messy, and asked to add a feature or review it. This is the round closest to real work and the one most affected by coding agents, because reading and judging code is now a larger share of the job. Interviewers look for whether you read before typing, find the seam where the change belongs, add a test first, and avoid rewriting what works. The principles lessons are the toolkit here: Single Responsibility Principle, Open/Closed Principle, Coupling and Cohesion, DRY and KISS.

The concurrency round

Some LLD rounds center on shared state: a thread-safe bounded queue, a seat-booking service where two users race for one seat, a rate limiter under concurrent requests. You are graded on identifying the critical section, choosing between a lock, an atomic, a channel or an optimistic version check, and explaining what happens under contention. The design lessons' "Concurrency and edge cases" sections prepare for this.

Take-homes and AI-assisted rounds

A take-home is a machine coding round with a weekend instead of 90 minutes, so expect to add tests, a README and clean commits. In AI-assisted rounds generating code is cheap, so you are graded on the requirements you pin down, the design you steer toward, the bugs you catch in the assistant's output, and whether you can explain and modify every line when the curveball arrives.

Reading the format before you start

Ask two questions in the first minute: "Do you want running code, or a design we discuss?" and "Should I optimise for extensibility or for finishing the core?". The answers tell you which format you are in. Then budget time. For a 90-minute machine coding round, a workable split is 10 minutes on requirements and entities, 50 on the core with a driver, 15 on the extension, 15 on tests and cleanup. How to Learn LLD? covers the long-term preparation; LLD vs HLD explains why talking about load balancers in any of these rounds is answering the wrong question.

The same shape elsewhere

Every format eventually asks for multi-step consistency: an operation made of several steps must either complete or leave no trace. In the key-value store it is a transaction; in Splitwise it is an expense that updates several balances; in a booking system it is holding seats then charging a card. The same shape appears in databases (savepoints), editors (undo groups) and infrastructure (Terraform plans that apply or roll back). The Practice builds the smallest version: nested transactions with rollback over an in-memory map.

Down the stack

Layer 1The contract

The interview itself has a contract, and it is worth stating as precisely as an API. Input: a problem statement, a time limit, and an interviewer who will answer clarifying questions. Output: a design or program that meets the stated requirements, plus evidence of how it handles a change. The rubric, whether written down or not, scores requirement gathering, modelling, code quality, correctness on edge cases, extensibility and communication. For the Practice problem the code contract is: rollback restores every key and every count to exactly what they were at the matching begin; a nested commit keeps changes only as long as its parent does; with no open transaction, commit and rollback fail without changing anything.

Layer 2The mechanism

Two mechanisms implement transactions in memory, and choosing between them is the core decision of the classic machine coding problem. A snapshot copies the whole map at begin; rollback swaps the copy back. It is simple and wrong for scale: each begin costs O(n). An undo log (SQLite's rollback journal is the disk version: it saves original pages before they are overwritten) records, for each write, the key and its previous value or "absent". Rollback replays the innermost log backwards; a nested commit appends its log to the parent's, so an outer rollback can still undo it; an outermost commit discards the log. Secondary indexes such as a value-to-count map are maintained by the same set and delete primitives that rollback uses, so they cannot drift. The alternative, a stack of overlay maps with tombstones, makes begin and commit cheap but makes get walk the stack and makes count hard. Postgres takes a third route: it never overwrites rows in place (MVCC), and implements SAVEPOINT with subtransactions, each with its own transaction id, which is why thousands of savepoints in one transaction can overflow a per-backend cache of 64 subtransaction ids and slow down every snapshot.

Layer 3The machine

The costs are concrete. A Python dict entry costs roughly 100 bytes including the key and value objects, so snapshotting a 1-million-key store at every begin copies around 100 MB and takes tens of milliseconds; a Go map of string to string is closer to 50 to 70 bytes per entry plus string data. An undo log entry is a key reference, a value reference and a flag: about 24 to 40 bytes, written only for keys that change. A transaction that touches 10 keys in a 1-million-key store costs 10 log entries with an undo log and a full copy with a snapshot, a ratio of 100,000 to 1. In a concurrent version a single mutex around the store serialises operations at roughly 20 to 50 ns per uncontended lock, which is fine for an interview and a reason Redis runs its command loop on one thread.

Why it's built this way

Interviewers have one hour and want a signal close to real work, so they pick a small domain that fits in memory and needs no infrastructure.
Working code is harder to fake than a diagram, so machine coding rounds ask for it; a diagram is quicker to discuss, so whiteboard rounds keep it for senior-level trade-off talk.
Real requirements change, so the round adds a requirement late and measures how much code moves.
Copying state is the obvious way to undo and scales with the store, so good answers record changes instead, and the same reasoning gives databases their undo logs and journals.
Generated code is now cheap, so rounds are shifting to grade the judgment that code generation cannot supply.

Diagram

flowchart TD
  P["Problem statement"] --> Q{"Running code expected?"}
  Q -- "No" --> W["Whiteboard OOD: entities, class diagram, flows"]
  Q -- "Yes, one component" --> C["Component round: data structure, complexity"]
  Q -- "Yes, full app" --> M["Machine coding: core, driver, tests"]
  Q -- "Given existing code" --> X["Extend or refactor: read, test, change"]
  W --> E["Curveball requirement"]
  C --> E
  M --> E
  X --> E
  E --> G["Graded on how much has to change"]

Worked example

A machine coding prompt: "Build an in-memory key-value store with set, get, delete, count(value), and transactions with begin, commit and rollback. Transactions can nest. 90 minutes."

Minutes 0 to 8: clarify. Does commit close only the innermost transaction? (Yes; changes become permanent at the outermost.) rollback with nothing open? (Error, no change.) Must count be O(1)? (Yes.) Writing the answers at the top of the file prevents the most common failure: building the wrong semantics.

Minutes 8 to 15: model. One TxStore class with a data map, a counts map, and a stack of undo logs. Two private primitives, _put and _remove, are the only code that touches data and counts, so the count index cannot drift. State the complexity: every operation O(1) except rollback, which is O(writes in that transaction).

Minutes 15 to 55: implement, driven by tests that mirror the clarified rules. Minutes 55 to 75: the curveball, "readers outside the transaction must not see uncommitted writes", is a real redesign (per-session overlays); the strong answer says so and sketches what it costs get. Minutes 75 to 90: clean up and walk through one rollback trace. That is about 60 lines of core logic and 50 of tests; the candidate who snapshotted the map at every begin finished faster and was asked "what about a million keys?".

Trade-offs

Format	What it measures	Typical length	Main risk for the candidate	Prepare with
Whiteboard OOD	Modelling, responsibilities, patterns, communication	45 to 60 min	Drawing classes without behaviour or edge cases	Design Parking Lot, Class Diagram
Machine coding	Working, modular, extensible code under time pressure	60 to 120 min	Over-engineering and not finishing the core	Design Snake and Ladder, Design Splitwise
Component / API	Data structures, complexity, API contract	45 to 60 min	Building a class hierarchy instead of the data structure	Design LRU Cache, Design Rate Limiter
Extend or refactor	Reading code, finding seams, testing first	45 to 60 min	Rewriting what works	SRP, OCP, Coupling and Cohesion
Concurrency	Critical sections, races, contention	45 to 60 min	Locking everything or nothing	Design Movie Booking System
Take-home	Completeness, tests, documentation	Hours to days	Gold-plating; mismatched effort	Any design problem, fully tested

Pitfalls in production

Starting to code before pinning semantics, then rebuilding at minute 60 when "commit" turns out to mean something else. Fix: write the clarified rules at the top of the file and turn each into a test.
A 400-line main that mixes parsing, state and printing. Fix: separate the model from the driver from the start; the driver should be the thinnest file.
Patterns used as decoration: a factory for one class, a strategy with one implementation. Fix: introduce an interface only where the prompt or the likely curveball names a variation.
Ignoring failure paths: rollback with nothing open crashes or silently succeeds. Fix: treat errors as part of the API and test them.
In AI-assisted rounds, accepting generated code you cannot explain. Fix: ask for small pieces, read every line, and run tests after each addition.

Leadership lens

Choose the format by the job. A team that mostly extends a large codebase learns more from an extend-or-refactor round than from "design a parking lot".
Write the rubric down, including what "extensible" means for each problem, and calibrate with mock interviews before using a new problem.
Rotate problems and keep each one's curveball private; once a problem's semantics circulate online, the round measures memory.
Decide your policy on AI assistants explicitly and tell candidates. Then grade what the policy makes scarce: requirements, design judgment and verification.

Check yourself

In a machine coding round you have 20 minutes left and two features unbuilt. What do you do?
Show answer
Make what exists run and pass its tests, then sketch where each missing feature would plug in. A running, extensible core scores better than two half-built features.
Why does an undo log scale better than a snapshot for nested transactions?
Show answer
A snapshot copies the whole store at every begin, so its cost grows with the store; an undo log records only the keys a transaction writes, so its cost grows with the transaction.
How should an inner commit interact with an outer rollback, and how does the undo log achieve it?
Show answer
The outer rollback must undo the inner transaction's changes too. The inner commit appends its log entries to the parent's log instead of discarding them, so the parent replays them on rollback.
You are told "design a rate limiter" in an LLD round. What is the likely format, and what should you spend most time on?
Show answer
A component round: spend the time on the algorithm and its data structure (token bucket or sliding window), the API, complexity and thread safety, not on a class hierarchy or on distributed infrastructure.

Watch

Flipkart Machine Coding Round Interview For SDE 2 & 3: Logging Library (Shubham Haritash): a full machine coding round on a logging library, showing the pace and what gets built first.
How to prepare Low level design for Interviews? Machine Coding rounds (Ayushi Sharma): an overview of the LLD round formats and a preparation plan.

Free resources

SAVEPOINT (PostgreSQL documentation): nested rollback points in a real database, the production version of the Practice problem.
SAVEPOINT, RELEASE and ROLLBACK TO (SQLite documentation): precise semantics for nested transactions, including what an inner release means.
Atomic Commit In SQLite: how a rollback journal records old pages so a transaction can be undone, the undo log at the disk level.
Transactions (Redis documentation): a contrasting design with queued commands and no rollback, worth comparing in the follow-up discussion.
How we hire (Google Careers): how one large employer describes its interview process and what it assesses.

Open in the interactive app: practice, quiz, mock interview →