Free lesson · Low Level Design Interviews
What an LLD Interview Actually Is
What an LLD Interview Actually Is
by Brandon Carter - Principal Engineer, AWS S3. Amazon Bar Raiser. 300+ interviews conducted.
In 2012, I sat in a conference room in Mountain View with a Google engineer who asked me to design a parking lot. I'd been at IBM for four years writing enterprise Java that never touched anything algorithmic. I knew what classes were. I knew what inheritance was. I'd been promoted twice. I thought I was ready.
I spent 45 minutes drawing UML diagrams. I created a ParkingLot class, a Vehicle superclass, three subclasses for car, truck, and motorcycle. I added a Ticket class. I added a Payment class. I drew arrows between them. I felt good about my arrows.
What I didn't do: ask a single question about the actual problem. I didn't ask how many spots. I didn't ask whether vehicles had different sizes. I didn't ask what happens when the lot is full. I didn't ask what the parking lot actually needs to do. I built a beautiful, useless structure that answered no real questions.
I got the rejection email three days later. Polite, generic, no feedback.
What I didn't understand then - what I've spent the last twelve years understanding from both sides of the table - is that an LLD interview isn't a test of whether you can draw classes. It's something specific, and I want to spend this topic getting that specific.
What it actually is
Interactive animation: Objects, responsibilities and change - tested under time pressure, with a stranger watching and a five-sentence problem statement.
An LLD interview tests how you think about objects, responsibilities, and change - under time pressure, with a stranger watching, with incomplete information. That's the whole thing. Everything else is detail.
Let me unpack each piece because each one is doing work.
Objects. Not "object-oriented programming" as an academic discipline. Objects as in: what are the things in this problem, what do they know, what do they do, who owns what. If I ask you to design a chess game, the "objects" question is whether you can name what the chess game contains and what each piece of it is responsible for. Not "is your Board a singleton" - what does the Board know and what does it do?
Responsibilities. The "responsibilities" question is: when a thing happens in the system, which object handles it? If a knight moves, which object validates the move? Which object updates the position? Which object detects checkmate? You're being evaluated on whether you can assign responsibility to objects in a way that feels natural - not forced, not arbitrary.
Change. This is the one most candidates miss. Real systems change. Your design has to accommodate plausible changes without falling apart. If I ask you to design a chess game and you wire BlackPiece and WhitePiece everywhere, you're going to have a hard time when I say "now make it variant chess where there's a third color." You're not being tested on whether your code handles every imaginable future - you're being tested on whether you've thought about which futures are plausible.
Under time pressure. 45 minutes. Not "design the perfect parking lot system over a weekend." Design something defensible in 45 minutes. Time pressure forces choices. The interviewer is watching how you choose.
With a stranger watching. Performance anxiety is real. The interviewer knows you're nervous. They're not penalizing you for being nervous; they're evaluating how you handle the cognitive load when a stranger is staring at you and a clock is running.
With incomplete information. No requirements document. No PM. No spec. You have a five-sentence problem statement and a person across the table. Your first job is to make the problem definite enough that you can design for it.
What it's not
Here's where most candidates lose points before they've written a line of code. They misunderstand what they're being tested on.
It's not a coding test. Yes, you'll write code. The code is evidence of your thinking, not the thing being evaluated. Beautiful clean Java with the wrong responsibilities scores worse than messy code with the right responsibilities.
It's not a system design test. System design is about scale - load balancers, database choices, consistency models, geographic distribution. LLD is about objects and their relationships within a single process. If you start talking about Kafka in an LLD interview, you've misread the room.
It's not a behavioral test. Yes, the interviewer wants to see how you communicate. But they're not asking you to tell a STAR-format story about a time you had to solve a hard problem. The behavioral signal is built into how you handle this specific problem - do you clarify, do you defend, do you adjust, do you learn from feedback.
It's not a pattern recall test. This is where I want to spend extra time because it's the single biggest mistake I see. You don't get points for saying "Strategy pattern" or "Observer pattern." You get points for applying the right pattern when it fits - and not applying a pattern when it doesn't fit. Pattern dropping (mentioning patterns to signal sophistication) is an anti-signal. I've watched candidates name five patterns in five minutes and not implement any of them well. They thought they were demonstrating expertise. They were demonstrating they'd read a book.
It's not about getting the "right" answer. There is no right answer to "design a chess game." There are better and worse answers, but the variation across reasonable strong solutions is significant. Two senior candidates designing a chess game will produce different designs, both correct, with different trade-offs. The interviewer isn't checking your design against a key.
The honest signal
Here's what I'm actually looking for when I interview a candidate for L6 or L7 at Amazon. It's the same signal whether the candidate is writing Java, Python, or pseudocode. The signal is:
Can this person build something maintainable in 45 minutes that another engineer could read tomorrow?
That's the whole thing. Let me decompose it because each word matters.
Build something - they produce a concrete artifact, not just talk about one. There's actual code or detailed pseudocode at the end. Not just diagrams.
Maintainable - the structure can absorb plausible changes. The responsibilities are clear enough that the next change has an obvious home.
In 45 minutes - they paced themselves. They didn't spend 30 minutes on the perfect domain model and then run out of time. They didn't sprint into code without thinking. They knew when to move on.
Another engineer could read tomorrow - the design has internal logic that a reader could reconstruct. The naming makes sense. The structure tells a story. I shouldn't need a one-hour explanation to understand why each class exists.
If I can answer yes to that question with confidence, I'm voting hire. If I can answer yes to most of it with caveats, I'm voting borderline. If I can't answer yes - if their structure is incoherent, if their responsibilities are arbitrary, if their code is impressive but unmaintainable - I'm voting no, regardless of whether they got the "right" answer.
What candidates who pass actually do
When I think about the candidates I've voted hire on across 300+ interviews, they share a small set of behaviors. Not all of them, but most:
They asked questions before they designed. Not interrogation-style ("tell me every requirement"), but targeted ("when you say chess, do you mean standard rules or are we supporting variants?"). They wanted to make the problem definite.
They thought out loud. Not narrating every keystroke - explaining the choices. "I'm making this a separate class because I want the rule logic away from the move-execution logic." That sentence is gold. It tells me they're choosing, not pattern-matching.
They made deliberate decisions. When they reached a fork - composition vs inheritance, separate class vs method, mutable vs immutable - they paused and chose. Sometimes the wrong choice; we corrected together. But they were making decisions, not stumbling into structure.
They evolved the design when feedback came. I'd ask "what about variant chess?" and they'd consider it and either adjust or explain why their current design accommodates it. They didn't get defensive. They didn't pretend the question wasn't there. They engaged.
They paced themselves. Around 30 minutes in, they were transitioning from design to code. Around 40 minutes in, they were verifying their code worked for the basic case. Around 43 minutes in, they were checking that their structure would survive the variations I'd mentioned. They weren't rushing; they weren't drifting.
That's the pattern. Five behaviors. None of them are about pattern recall.
What I tell candidates I coach
When friends or former colleagues ask me to help them prep for LLD interviews, I tell them this. Not the patterns. Not the practice problems. This:
Important: Stop trying to know everything. Start trying to think clearly.
The candidates who pass LLD interviews aren't the ones who know every Gang of Four pattern by name. They're the ones who can take an ambiguous problem, make it definite, model the objects involved, build something that works, and explain their choices along the way.
If you can do that with twelve patterns in your toolkit, you'll pass. If you have all twenty-three patterns memorized but you can't reason through a new problem, you'll fail.
This isn't a knock on patterns. I love patterns. We'll cover them throughout this product. But patterns are tools you reach for when they fit. They're not a vocabulary you sprinkle to impress the interviewer.
What this topic is setting up
The rest of this module covers the specifics - what interviewers actually listen for (Topic 1.2), how the 45 minutes structure themselves (Topic 1.3), what strong performance concretely looks like (Topic 1.4), and what failure looks like and how to recover from it in real time (Topic 1.5). The remaining modules cover the methodology - how to clarify, how to model, how to design, how to implement, how to communicate.
But before any of that lands, this has to: the LLD interview is testing something specific. It's not the test you might think it is. The candidates who succeed have understood what's actually being measured. The ones who fail have often been preparing for the wrong test.
I spent four years at IBM thinking I was preparing for a coding interview. I was wrong. I spent three years at Oracle after that thinking I was preparing for a knowledge interview. I was wrong. It was only at Stripe - where I was actually building distributed systems at scale, making real trade-off decisions in production, watching my own designs evolve under real change - that I understood what interviewers were actually trying to find.
They're trying to find someone who can think about objects, responsibilities, and change, under time pressure, with incomplete information. That's the entire job.
Common mistakes
Warning: The most common LLD interview misunderstandings:
Treating it as a coding test. Writing clean code matters; getting the responsibilities right matters more. Code that's clean but wrong scores worse than code that's messy but right.
Pattern dropping. Mentioning patterns to signal sophistication. Interviewers see through this immediately. Use a pattern when it fits; otherwise don't reach for vocabulary.
No clarifying questions. Diving into design without making the problem definite. You end up designing for an imagined problem that doesn't match what the interviewer has in mind.
Silent thinking. Designing without explanation. The interviewer can't evaluate the thinking they can't see.
Defensive complexity. Adding layers of abstraction to look sophisticated. Senior interviewers read this as the opposite - junior engineers over-engineer; senior engineers simplify.
Sprinting into code. Twenty minutes of class structure before any code; thirty minutes of code in a panic; nothing works. Pace matters.
Try It
Exercise: Five questions to ask yourself before your next LLD interview:
If the interviewer asked me right now what an LLD interview tests, could I answer in one sentence? If not, you don't have a clear target.
For my last five mock interviews, did I clarify the problem before designing? If not, this is your highest-leverage change.
Could I name three patterns I'd avoid mentioning unless they genuinely fit? Pattern restraint is a skill; practice it.
If asked "why this design over alternatives," do I have a one-sentence answer for each major choice? This is the articulation skill that distinguishes strong candidates.
At minute 30 of a 45-minute interview, am I in design mode or implementation mode? Strong candidates have transitioned. Weak ones are still drawing diagrams.
The next topic (1.2) goes deeper into what interviewers actually listen for - the specific signals and anti-signals I'm scoring on as a Bar Raiser, and what each one tells me about whether to vote hire.