Low Level Design (LLD) Interview: What It Is and How to Answer One

A low level design interview asks you to design the classes inside one system. The question is short. "Design a parking lot." "Design an elevator." You get about 45 minutes.

What you hand back is a class design. Which classes exist, what each one is responsible for, and how they connect.

This is not the system design round. That round is about servers, databases, and traffic. This one stays inside a single service, at the level of code.

This article explains what the round asks for and gives a seven-step method. It then works one question end to end and lists the questions that come up most.

What a low level design interview is

The question is vague on purpose. "Design a parking lot" does not say how many floors it has, or whether parking is paid.

Making it specific is the first part of your job. After that, the hour has a predictable shape. You name the classes, give each one a clear job, connect them, and then absorb one new requirement at the end.

Most interviewers want a class diagram, which is a drawing of the classes and the lines between them. Some want working code instead. That variant is called a machine coding round, and it usually runs 90 minutes or longer.

The skill being measured is the same in both. Can you turn a loose description into a structure that another engineer could build?

LLD, OOD, and machine coding are the same round

People search for this material under several names and reasonably conclude they are different topics. They are not.

One distinction is worth keeping. OOP is not OOD. Object-oriented programming (OOP) is the feature set your language gives you: inheritance, polymorphism, encapsulation, and abstraction. Object-oriented design (OOD) is the skill of deciding which classes should exist and what each one owns.

An interviewer who asks you to design a parking lot is testing OOD. An interviewer who asks what an abstract class is, is testing OOP.

If you can do the first, you can answer the second. It does not work in reverse.

Low level design vs system design

These are two different rounds, and some loops include both. The difference is altitude.

Preparing for one does not prepare you for the other. Engineers who spend six weeks on databases and load balancers, then get asked to design a parking lot, have prepared hard for the wrong round.

Check your recruiter's email for the round name before you choose what to study. Types of system design interviews covers how the two are scheduled and named.

How to answer a low level design question

The same seven steps work for every question in this round.

1. Agree on what the system does. List the features in scope, and say out loud what you are leaving out. Two or three minutes here saves the whole hour.
2. Find the entities. Read your requirements and pull out the nouns. Most of them become classes.
3. Give each class one job. A class that handles parking, payment, and reporting is hard to test and hard to change. One clear responsibility each.
4. Model the relationships. Decide what contains what, what extends what, and where an interface belongs. Prefer composition, which means one class holding another, over inheritance.
5. Use a pattern only where it earns its place. Naming a pattern is worth little. Saying why this problem needs a factory, and what it costs, is worth a lot.
6. Handle concurrency if the problem has any. Two cars must never be given the same spot. Say how you would prevent that.
7. Show that it extends. The closing question is almost always a new requirement. A good design absorbs it with one new class.

The most expensive mistake is starting step 2 before step 1 is finished.

The parking lot, worked in seven steps

Parking lot is the standard opening question, so it makes a good example.

Agree on what it does. Cars enter, take a ticket, park, pay at exit. Multiple floors, multiple spot sizes. No reservations, no monthly passes.

Find the entities. ParkingLot, Floor, ParkingSpot, Vehicle, Ticket, Payment, DisplayBoard, EntrancePanel, ExitPanel.

Give each class one job. ParkingSpot knows whether it is free and what size it is. Ticket records entry time. Payment computes what is owed. The lot itself only assigns and releases spots.

Model the relationships. A ParkingLot has many Floors, and a Floor has many ParkingSpots. Vehicle and ParkingSpot each get a type, held as an enum: a small fixed list of named values. Spot types run from handicapped and compact through large, motorbike, and electric.

Use a pattern where it helps. Rates change by vehicle type and by hour. A strategy, which is one interface with several swappable implementations, keeps that logic out of the payment class.

Handle concurrency. Assigning a spot must be atomic, meaning no two threads can claim the same spot. Say which lock or which atomic operation you would use.

Extend it. The closing requirement is monthly passes. A good design adds a Pass class and one more rate strategy. A rigid one needs the payment class rewritten.

That is the whole method. The classes change per question; the seven steps do not.

The questions asked most often

The list of questions in this round is short and stable. These are the ones that keep appearing:

Everyday objects. Parking lot, library management, ATM, elevator system, vending machine.

Booking and inventory. Movie ticket booking, hotel management, car rental, restaurant management, airline management.

Games and rules. Blackjack and a deck of cards, chess.

Platforms and feeds. Stack Overflow, Cricinfo, LinkedIn, Facebook, Amazon online shopping, online stock brokerage.

Service-shaped problems. Splitwise, a notification service, an in-memory cache, a ride sharing service. These appear more often in senior loops.

Working four or five of these is enough to see the moves repeat. That transfer is what carries you through a question you have never seen.

Five design mistakes that cost the round

Writing classes before the requirements are agreed. The design ends up matching a problem nobody asked for.

One class doing everything. A ParkingLot class that also prices and also prints receipts cannot be tested or changed.

Inheritance where composition belonged. A Truck is not a special kind of ParkingSpot. This is the most common structural error in the round.

Naming a pattern without defending it. Saying "I will use a singleton" invites the question of what it costs you. Have the answer ready.

No concurrency story. In a machine coding round, a design that is not thread safe is usually marked as incomplete.

How to practice, with or without a course

If you design class models at work every week, you may not need a course. Take parking lot, chess, and an elevator, and design each on paper in 30 minutes. Then add one new requirement to each and see whether your design absorbs it.

If you can code well but have never structured a system into classes under time pressure, a course removes that specific failure. Grokking the Object Oriented Design Interview is built for that gap.

It runs 49 lessons across six chapters. The first two cover object-oriented basics and UML. A third covers how the round itself runs.

The rest is 22 case studies. Each one goes from requirements to a class diagram to running code in Python, Java, and C++. More than 60,000 engineers have taken it, and it costs $30 once, with lifetime access.

Two honest gaps are worth naming. Concurrency is not covered there, and it appears constantly in machine coding rounds; that material sits in Grokking Multithreading and Concurrency instead. And the course applies design patterns inside its case studies rather than teaching them as a subject, which is what Grokking Design Patterns is for.

Frequently asked questions

What is the difference between LLD and OOD? In interview practice, almost nothing. LLD is the more common term in India and OOD in the US. Both describe a round where you design the classes inside one system. Some companies use LLD to include concurrency and API design as well.

Is low level design the same as system design? No. System design is the high-level round about scaling a service across machines. Low level design is about the classes inside one service. Some loops run both as separate rounds. The full comparison is here.

Do LLD interviews include concurrency? Often, and machine coding rounds nearly always do. A thread-safe design is a common closing requirement. It is the most under-prepared part of the round.

How many design patterns do I need? Enough to reach the right one and defend it. Factory, strategy, observer, decorator, singleton, adapter, and builder cover most of what appears. Reciting all 23 Gang of Four patterns is not useful.

Is there a Grokking low level design course? Ours is Grokking the Object Oriented Design Interview, which covers this round under the other common name for it. A separate course with a similar name, Grokking the Low Level Design Interview Using OOD Principles, is published by Educative. They are different courses from different companies. Check the domain on your receipt.

Which companies ask low level design questions? It is most standard at Indian product companies, and for backend roles at mid to senior level. Some large companies fold it into a coding round rather than running it separately.

Is there a PDF of the course? No official PDF exists. Copies circulating on file sharing sites are text extracts, usually years out of date, and they exclude the code environments.

Related reading

• Types of system design interviews. Product, infrastructure, OOD, and API design rounds, and how to tell which one you have.
• Beginner's guide to object-oriented programming. The OOP fundamentals this round assumes you already have.
• LLD vs HLD. The short answer on how the two rounds differ.
• What is an example of low level design?. One worked example in brief.
• System design interview fundamentals. If your loop has a high-level round too, start here.

Before you buy anything, design one question on paper. Parking lot is the standard opener.

Write the classes, give each a job, and draw the relationships. Then add one requirement and see whether your design survives it. That tells you more about your readiness than any course description, including this one.