The Design Patterns That Keep Showing Up in LLD Interviews

Ask a candidate to define the Singleton pattern and most rattle it off in five seconds flat. Ask them why a payment service handling three regional providers probably shouldn't use one, and the room goes quiet. That gap, reciting a pattern versus knowing when it actually breaks something, is what most design patterns interview questions are testing in 2026, not whether you memorized a UML diagram, and it's exactly the kind of live judgment call our AI Interview Copilot is built to help you reason through once you're actually in the room.

The three buckets, and the patterns interviewers actually reach for

The original Gang of Four book split 23 patterns into three buckets: creational, structural, and behavioral. Refactoring.Guru's public catalog groups them the same way and is still the cleanest free reference for the full list, if you want to see all 23 laid out with diagrams (Refactoring.Guru, Design Patterns Catalog). Most design patterns interview questions in an actual LLD round don't touch anywhere near 23 patterns. In practice, eight or nine patterns cover something close to 90% of what actually gets asked, and interviewers care a lot less about which bucket a pattern sits in than whether you can explain what breaks without it. If you want a quick self-check on where you stand before you get there, LastRoundAI's free career tools include a couple of short assessments worth running first.

That's eight patterns out of 23, not all of them. I'd personally skip memorizing Visitor and Flyweight for most SDE-2 and SDE-3 loops. I've seen them come up maybe twice across a couple years of interview prep conversations, and both times the interviewer was fine with "I'd just use a loop here instead."

Creational patterns: how systems build the things they need

Singleton restricts a class to exactly one instance and gives every caller a shared access point to it. The classic real-world version is a country's central bank: you don't want fifty regional banks each setting their own interest rate independently, you want one source of truth. In code, that usually shows up as a config loader, a connection pool, or a logging sink.

class ConfigLoader:
  _instance = None

  def __new__(cls):
    if cls._instance is None:
      cls._instance = super().__new__(cls)
      cls._instance.settings = {}
    return cls._instance

That's the whole pattern, maybe eight lines. The interesting part isn't the code. It's what happens when two threads call ConfigLoader() at the exact same moment before _instance gets set. That race condition is a real follow-up question, not a hypothetical, and it's usually the first sign an interviewer wants to see if you actually understand what you wrote.

Factory Method and Abstract Factory both decouple object creation from the code that uses the object. Factory Method hands back one product without the caller needing to know the exact subclass, the way a recruiter routes a candidate to a phone-screen interviewer or a system-design interviewer without the candidate needing to know which interviewer class got instantiated. Abstract Factory goes a step further and produces whole families of related objects that have to match, the way an IKEA showroom sells a matched dining set (table plus four chairs) and would never let you mix pieces across two different collections.

Builder solves a narrower, more annoying problem: constructors with too many optional parameters, sometimes called the telescoping constructor problem. Instead of a constructor with twelve boolean flags, you build the object step by step. Ordering a burger with a dozen possible customizations at a counter works the same way, you add instructions one at a time rather than filling out a form with twelve checkboxes up front.

Structural patterns: making pieces that don't fit, fit

Adapter bridges an existing interface to the one a client expects, without touching the original code. A travel plug adapter is the textbook analogy, but the version that shows up in interviews is closer to wrapping a legacy vendor API that only speaks XML behind a class that emits JSON, so the rest of the codebase never has to know the mismatch exists.

Decorator attaches new responsibility to an object at runtime without changing its class or triggering a subclass explosion. A coffee order is the standard example and it's a good one: base espresso, wrapped in milk, wrapped in caramel, wrapped in whipped cream, each wrapper adding cost and behavior on top of an object whose original class never changes.

Facade hides a tangle of subsystem calls behind one simple entry point. Turning a car key triggers the fuel pump, the starter motor, and the ignition coil, but the driver only ever interacts with one action. Facade's failure mode is worth knowing too: it can hide too much. When a caller needs to bypass the simplified path for one edge case and the facade doesn't expose a way to do that, you end up with an ugly workaround bolted onto the outside, or a rewrite.

Behavioral patterns: Observer and Strategy

Observer handles one-to-many notification. A YouTube channel's subscribers all get notified when a new video drops, and the channel never has to know anything about who's subscribed or how many there are. This is the backbone behind most pub-sub systems, UI event listeners, and MVC view updates, so recognizing Observer under an unfamiliar prompt is a genuinely useful skill.

Strategy swaps out an algorithm at runtime instead of growing an if-else chain forever.

class PaymentStrategy:
  def pay(self, amount):
    raise NotImplementedError

class CreditCard(PaymentStrategy):
  def pay(self, amount):
    return f"Charged ${amount} to card"

class Checkout:
  def __init__(self, strategy: PaymentStrategy):
    self.strategy = strategy

  def complete(self, amount):
    return self.strategy.pay(amount)

Add PayPal or Apple Pay later and you write a new class. You don't touch Checkout at all, which is really the Open/Closed Principle showing up with a different name on it.

Where this actually shows up in an LLD round

Interviewers rarely say "implement the Observer pattern." They say "design a notification system for a ride-share app" or "design a parking lot" or "design a rate limiter," and the pattern is the thing you're expected to reach for without being told its name. Design a parking lot and Factory tends to surface when you're deciding how vehicles get matched to slots. Design a notification system and Observer is almost always the backbone. Design a logging framework and Singleton, or its safer cousin, a single instance passed in through a constructor, comes up constantly, which is also exactly where it gets misused most.

Our companion breakdown of low-level design interview questions walks through eight of these prompts end to end, clarifying questions through class diagrams, if you want the fuller LLD picture beyond just the pattern names. Amazon's SDE-2 loop is a good concrete example of where this gets tested in the room: system design and pattern-heavy follow-ups both show up there, and our Amazon SDE-2 interview questions breakdown covers what candidates actually report being asked. Landing that loop in the first place usually starts with a resume that gets you shortlisted, which is what LastRoundAI's resume builder is built for.

On LastRoundAI's mock interview reviews for backend and LLD rounds, the score gap we keep seeing isn't pattern recall. It's candidates who can code Singleton from memory but stumble the moment we ask why two threads calling getInstance() at the same time is a problem, or what they'd do instead inside a stateless microservice. Naming the pattern is table stakes. Defending the trade-off, out loud, under a follow-up question, is the actual interview.

The Singleton problem, and how patterns tie back to SOLID

Singleton is the pattern interviewers love to attack, and for good reason. Miško Hevery, a Google engineer, argued back in 2008 that singletons hide dependencies, classes reach into global state without declaring it anywhere in their constructor, which makes unit testing painful and couples code that had no business being coupled (Google Testing Blog, "Root Cause of Singletons," 2008). That critique is almost two decades old now and it still holds up. If you reach for Singleton in an interview, the strong move is naming the cost out loud, harder to test, harder to parallelize, a magnet for hidden state, and then explaining why you're accepting that cost anyway, or why you'd inject a single instance through a constructor instead and get the same guarantee without the global access point.

Most of the patterns above are really SOLID principles wearing a name. Strategy and Observer are the Open/Closed Principle in practice: you add a new payment method or a new subscriber without touching existing code. Factory and Abstract Factory lean on Dependency Inversion, since the calling code depends on an interface, not a concrete class. Decorator and Adapter both avoid modifying existing classes, which is Open/Closed again from a different angle. If you haven't looked at SOLID directly yet, our SOLID principles breakdown is the shorter, more foundational read this post is quietly assuming you've done.

Sample design patterns interview questions

What's the difference between Factory Method and Abstract Factory?

Factory Method creates one product through a single overridden method, usually via subclassing. Abstract Factory creates a whole family of related products through one interface, so a UI toolkit's WindowsFactory and MacFactory each produce a matched button, checkbox, and scrollbar that never get mixed across platforms. If the interviewer only mentions one product type, they probably want Factory Method.

When would you reach for Builder instead of a constructor with optional parameters?

Once a constructor needs more than four or five optional parameters, or the object has to be built across several steps with validation in between, Builder wins. A classic interview tell: if the prompt says "some fields are required, some optional, and order matters," that's Builder, not a constructor with a dozen boolean flags.

Why do interviewers push back on Singleton so often?

Because it's the pattern most likely to be misused. Singleton makes sense for something that genuinely must be unique and largely stateless, like a logging sink. It stops making sense the moment you need to test the class in isolation, run it safely across threads, or scale the service horizontally, since a singleton in one process instance doesn't coordinate with a singleton in another process at all.

How is Adapter different from Decorator, since both wrap an object?

Adapter changes an interface so two incompatible systems can talk to each other. Decorator keeps the same interface and adds behavior on top of it. Translating one shape into another, XML into JSON, an old API into a new one, is Adapter. Layering extra behavior onto an object that already speaks the right interface, adding logging, caching, or compression around a service call, is Decorator.

Design a system that notifies multiple services when an order ships. Which pattern fits?

Observer. The order service publishes a single "shipped" event, and each interested party, email, SMS, the warehouse dashboard, subscribes independently without the order service knowing who's listening or how many. This is also the shape behind most pub-sub and event-driven systems, so naming Observer here signals you understand the broader pattern too, beyond this one prompt.

When would you choose Strategy over a long if-else chain?

The moment a new "type" gets added often enough that you keep editing the same conditional every few weeks. Strategy moves each branch into its own class, so adding PayPal or Apple Pay as a payment option means writing a new class, not touching checkout logic that already works and is already tested.

What does Facade solve, and where does it become a liability?

Facade hides a subsystem's internal complexity behind one clean method, like a single startEngine() call that quietly handles the fuel pump, starter motor, and ignition coil. It becomes a liability when a caller needs to bypass the simplified path for one edge case and the facade doesn't expose a way to do that, which forces an ugly workaround or, eventually, a rewrite.

How do design patterns relate to the SOLID principles?

Most of the patterns above are SOLID principles with a name attached to them. Strategy and Decorator both extend behavior without modifying existing code, which is Open/Closed. Factory and Abstract Factory push callers to depend on interfaces rather than concrete classes, which is Dependency Inversion. An interviewer asking this question usually wants to hear that connection stated directly, rather than a recap of each pattern's mechanics.

Can you combine multiple patterns in one design?

Yes, and interviewers expect it once the round goes beyond a single class. A payment gateway is a common example: Factory decides which provider class to instantiate, Strategy defines how each provider processes a charge, and Observer notifies downstream services once the payment settles. Naming all three, and explaining why each one earns its place, is a stronger answer than picking just one and stopping there.

What's a red flag when a candidate over-uses patterns in an interview?

Reaching for a pattern before there's a real problem to solve. Introducing a Factory for a class that will only ever have one implementation, or wrapping something in a Decorator that never needs runtime flexibility, reads as pattern-matching from a study guide rather than actual design judgment. I'd honestly rather hear "a plain class works fine here, I don't need a pattern yet" than a Singleton bolted onto something that never needed one.

Is it okay to not remember every pattern's exact name in an interview?

Mostly, yes. I don't think perfect terminology recall matters as much as candidates assume. If you describe "a class that hands out shared config" and forget the word Singleton for a second, most interviewers will let it go, or supply the name themselves, as long as the underlying design reasoning is sound. Where it stops being okay is using the wrong pattern's mechanics while using the right pattern's name.

Reciting nine patterns off a flashcard deck gets you through the first thirty seconds of an LLD round. The rest of it is defending the trade-off out loud, under a bit of pressure, while someone asks what happens if a fourth payment provider gets added next month. That's the part most candidates skip practicing, and it's exactly what LastRoundAI's voice mock interviews are built to drill, live follow-up questions included. Pick the one pattern you're weakest at defending, not naming, and start there.

How this list was built

Worth being straight about where these questions come from, because plenty of pages in this category are not. The set was compiled from a research pass across official documentation, vendor release notes, published engineering writing and public discussion of hiring processes, then cross-checked against the current version of each technology so nothing here describes behaviour that has since changed.

What that means in practice: these are the questions the material supports as reasonable and current for this role, not a transcript of any one company's loop. We have not sat in on your interview and we are not going to claim we have. Treat the list as well-sourced preparation rather than a leaked question bank, and expect your panel to phrase things their own way.

If you spot something out of date, tell us at contact@lastroundai.com and we will fix it.

Frequently asked questions

What design patterns topics come up most often?

Interviewers concentrate on the parts that cause production incidents rather than the parts that are pleasant to learn. Expect the fundamentals to be assumed and the follow-up questions to sit one layer below what a tutorial covers.

Do I need hands-on design patterns experience to pass?

It shows quickly either way. Textbook answers hold up until the interviewer asks what you did when it broke, and that is usually the question that separates candidates. A small real project you can discuss honestly beats a longer list of familiarity claims.

Is design patterns still worth learning in 2026?

For interview purposes the question is really whether the teams you are targeting use it, which is worth checking against their actual job postings rather than general popularity rankings. Where it is in use it tends to be deeply embedded and slow to replace.

Should I memorise design patterns syntax for the interview?

Rarely worth it. Most interviewers care that you know what to reach for and why, and will not fail you for forgetting an exact flag. Being confidently wrong about behaviour costs far more than admitting you would check the documentation.

What is the most common mistake in design patterns interviews?

Answering the question that was asked and stopping there. The strongest candidates add the trade-off or the failure mode without being prompted, which is what signals real use rather than revision.