Low-Level Design Interview Questions (The Most Common Ones)

Low-level design (LLD) interviews reuse a small set of fewer than twenty problems, and each one is chosen because it tests a named skill. The list is: elevator system, vending machine, traffic light, parking lot, library management, hotel booking, LRU cache, in-memory key-value store, rate limiter, logging framework, notification service, file system, tic-tac-toe, chess, snake and ladder, movie ticket booking, meeting scheduler, and Splitwise. The sections below group them by skill and say what the interviewer is checking in each.

If you wanted to know how the round itself is run, its length, and what the interviewer says at the start, that is covered in What to Expect in a Low-Level Design Interview Round. This page lists the problems.

State machines: elevator, vending machine, traffic light

A state machine is an object that is always in exactly one named state and moves between states only on defined events.

• Elevator system. Tests whether you model idle, moving up, moving down, and doors open as states, and how you schedule requests from several floors.
• Vending machine. Tests the states no coin, has coin, dispensing, and out of stock, and what happens when a coin is inserted in each.
• Traffic light. The simplest of the three, used to check that you express the transitions as a table rather than a chain of if statements.

Composition and enums: parking lot, library, hotel booking

Composition is the relationship in which one object owns others, such as a lot that owns floors that own spots. An enum is a fixed set of named values, such as vehicle sizes.

• Parking lot. Tests the ownership chain from lot to floor to spot, the enum of vehicle and spot sizes, and the rule that matches one to the other.
• Library management. Tests the split between a book title and a physical copy, and the entities member, loan, and reservation.
• Hotel booking. Tests room types as an enum, a reservation that spans dates, and the check that two bookings do not overlap.

Data structure design: LRU cache, key-value store, rate limiter

• LRU cache. An LRU cache evicts the least recently used entry when full, and the expected design is a hash map plus a doubly linked list so that get and put both run in constant time.
• In-memory key-value store. Tests a hash map with expiry, and whether you add a write-ahead log, which is a file every write goes to before memory, for recovery after a crash.
• Rate limiter with token bucket. A token bucket holds a fixed number of tokens, refills them at a steady rate, and rejects a request when no token is left. Tests the refill arithmetic and where the bucket is stored when there are many servers.

Design patterns: logging framework, notification service, file system

• Logging framework. Tests chain of responsibility, in which each handler either processes a message or passes it to the next, applied to debug, info, and error levels.
• Notification service. Tests observer, where subscribers register to be told of an event, and strategy, where the sending channel (email, SMS, push) is an interchangeable object.
• File system. Tests composite, where a directory and a file share one interface so that size or search can be computed on either.

Game state: tic-tac-toe, chess, snake and ladder

• Tic-tac-toe. Tests a board class, a move validator, and a win check, kept separate from the player and the game loop.
• Chess. Tests inheritance done well: a Piece base class with one subclass per piece type, each owning its own move rule.
• Snake and ladder. Tests a board with jump rules stored as a map from square to square, a dice abstraction, and turn order.

Concurrency: movie ticket booking, meeting scheduler

• Movie ticket booking with seat locking. Tests what happens when two users pick the same seat at the same time; the expected answer holds the seat with a lock or a temporary reservation that expires in about 5 minutes.
• Meeting scheduler. Tests interval overlap logic, and whether two organizers can double-book a room when they submit at the same time.

Graph and arithmetic: Splitwise

• Splitwise expense settlement. Tests modeling debts as a graph in which each edge records who owes whom, then reducing the number of payments needed to settle the group, usually by pairing the largest creditor with the largest debtor.

What the interviewer checks in every one

• Class boundaries. Each class has one reason to change. The interviewer asks what happens when a requirement changes, to see whether one class or five are affected.
• Extension without modification. Adding a new vehicle type, piece, or notification channel should mean adding a class, not editing a switch statement.
• Two or three patterns used correctly. Named as you use them, and not forced where a plain method would do.
• One concurrency case handled. Almost every problem has one shared piece of state, and you are expected to find it and say how the race is prevented.

A 45-minute plan

Spend the first 5 minutes clarifying who the users are, which operations matter, and the scale. A cache for one server and a cache for a cluster are different designs. Spend 5 minutes listing entities as the nouns in the requirements. Spend 15 minutes drawing the class diagram with fields and relationships, and name the pattern each part uses as you draw it. Spend 15 minutes writing the two most important methods in full, such as allow() for the rate limiter or bookSeat() for the ticket system. Use the last 5 minutes to discuss extension: pick one requirement change and show which single class needs to change.

How to Prepare

• Solve the list, one per day. Eighteen problems in three weeks, each drawn as a class diagram and two methods, covers every skill above.
• Write one design down fully. The document form of the same work is described in What Goes in a Low-Level Design Document.
• Know the coding variant. Some companies ask you to build the design as a running program instead; Machine Coding Round vs LLD Round explains the difference.
• Work through the standard problems with solutions. Grokking the Object-Oriented Design Interview covers the parking lot, library, hotel, chess, and movie ticket booking designs.
• Practice the concurrency case. Grokking Multithreading and Concurrency for Coding Interviews covers locks, atomic operations, and the seat-booking race.