How to Pass the Amazon SDE-2 LLD Interview

Amazon's SDE-2 low-level design interview is notorious for exposing engineers who can hack together an algorithm but freeze when asked for clean, extensible object-oriented design under pressure. High-level system design focuses on distributed systems and scalability. Low-level design (LLD), on the other hand, expects you to write actual, compilable code modeling complex business rules. You'll need to define interfaces, encapsulate state, correctly apply design patterns, and prove your code handles future requirements without needing a total rewrite. We're going to break down exactly how Amazon evaluates your object-oriented design skills. We'll analyze the hiring loop and deconstruct two of their most frequently asked LLD questions: the Unix File Search API and the Amazon Locker system.

Why Amazon's SDE-2 LLD Round Catches Top Engineers Off Guard

A lot of candidates fail the Amazon LLD round simply because they treat it like a LeetCode problem. They immediately jump into writing a massive script full of deeply nested if-else statements and global variables. That might produce the right output for the initial prompt, but it completely misses the point of the interview. Amazon wants to see how you structure code for a collaborative, enterprise-level environment. They look for modularity, a clear separation of concerns, and strict adherence to SOLID principles. If your solution forces you to modify core logic every time a new feature pops up, you'll fail the round. It doesn't matter if your code technically runs.

Time constraints are the second major trap. An Amazon interview usually lasts 45 to 50 minutes, but the first 15 to 20 minutes are strictly reserved for behavioral questions tied to Amazon's Leadership Principles. That leaves you with just 25 to 30 minutes to gather requirements, design a class structure, discuss trade-offs, and write working code. You simply don't have time to second-guess your architecture halfway through. You need a systematic approach to quickly turn ambiguous requirements into robust interfaces.

The Amazon SDE-2 Interview Process

You have to understand where the LLD round fits into the broader Amazon hiring loop. The SDE-2 loop is notoriously rigorous, indexing heavily on both technical depth and cultural fit. Every single round includes at least two Leadership Principle questions, and these carry just as much weight as the technical component.

The 50/50 Split: Balancing Leadership Principles with Extensible Code

As the process breakdown shows, the LLD round isn't just about code. The interviewer will kick things off by asking something like, 'Tell me about a time you had to deal with ambiguous requirements,' or 'Describe a situation where you had to push back on a design decision.' You need to deliver a concise, high-impact answer using the STAR method (Situation, Task, Action, Result) in under 4 minutes. If you ramble for 10 minutes, you're eating directly into your coding time. The strongest candidates practice transitioning smoothly from the behavioral segment into the technical problem, effectively taking control of the clock.

Core Amazon LLD Interview Questions

To succeed in the LLD round, recognize that interviewers aren't hunting for a single correct answer. They want a conversation about trade-offs. Let's deconstruct two of the most common and revealing LLD questions asked at Amazon, framing them exactly as you'll encounter them in the interview.

How do I design a Unix File Search API?

The prompt usually starts off simple: 'Design an API that allows a user to search for files in a file system.' Then, the interviewer asks you to support searching by file name, file size, and file extension. A naive approach is creating a SearchEngine class with a method like searchFiles(Directory dir, String name, Integer size, String extension). Inside that method, you'd write a Breadth-First Search (BFS) or Depth-First Search (DFS) traversal, checking each file against the parameters using a massive block of if-else statements. Don't fall for this trap. The interviewer will immediately follow up with: 'What if I want to search for files created after a certain date? What if I want to search for files larger than 5MB but smaller than 10MB?' If you have to modify your core search algorithm to support these new filters, you've just violated the Open/Closed Principle.

The correct architectural approach uses the Specification Pattern. You absolutely must decouple the search traversal logic from the filtering logic. Here's how you structure that:

• Define an interface called Filter (or ISpecification) featuring a single boolean method: isSatisfied(File file).
• Create concrete classes implementing this interface, such as NameFilter, SizeFilter, and ExtensionFilter.
• Implement Composite Patterns to handle complex queries. Create an AndFilter and an OrFilter that also implement the Filter interface. These composite classes take a list of Filters in their constructor and iterate through them within their isSatisfied method.
• Refactor the SearchEngine class. The search method should now accept a Directory and a single Filter object. Your traversal logic (BFS/DFS) then simply calls filter.isSatisfied(currentFile) on every node.

Applying this design gives you true extensibility. When the interviewer inevitably asks you to add a 'CreationDateFilter', you just create a new class implementing the Filter interface. You don't touch the SearchEngine class, and you leave existing filters alone. The time complexity of the search remains O(N), where N is the total number of files in the directory tree. Space complexity sits at O(D), where D is the maximum depth of the directory for the DFS call stack, plus the minimal memory overhead of instantiating the filter objects. Explaining this demonstrates a deep understanding of object-oriented design and maintainable code.

How do I design an Amazon Locker system?

The Amazon Locker problem tests your ability to model state and handle resource allocation. The prompt goes like this: 'Design the software for an Amazon Locker system where delivery drivers can drop off packages and customers can pick them up using a code.' The core entities you need to identify right away are Locker, LockerLocation, Package, Order, and User. The two primary technical challenges here involve the locker assignment algorithm and managing the lifecycle of a single locker box.

For the assignment algorithm, you have to match a package to a locker of an appropriate size (Small, Medium, Large, Extra Large). The Strategy Pattern is your best friend here. Define an interface called ILockerAssignmentStrategy with a method assignLocker(LockerLocation location, Package pkg). From there, you can implement different strategies. A 'StrictMatchStrategy' might only assign a medium package to a medium locker. Meanwhile, an 'OptimizedUpgradeStrategy' could assign a medium package to a large locker if no medium lockers are available—but only if the large locker utilization sits below a certain threshold. Injecting this strategy into your LockerService lets the business change routing logic down the line without altering the core system.

Your second challenge is managing the locker state. A locker box transitions through multiple phases: Available, Booked (when an order is placed but not yet delivered), ClosedWithPackage (when the driver drops it off), and OpenForPickup (when the customer enters their code). If you use a single string or enum and manage transitions with giant switch statements, your code becomes brittle. It also gets prone to illegal state transitions, like a customer trying to pick up a package from an 'Available' locker. Instead, rely on the State Pattern. Define a LockerState interface with methods like book(), open(), close(), and completeDelivery(). Each state, such as AvailableState or BookedState, implements this interface. If an action is invalid for a given state, the method throws an IllegalStateException. This perfectly encapsulates the transition logic and makes the entire system incredibly robust.

How Amazon Evaluates Your Design: SOLID Principles and Extensibility

Throughout the interview, your interviewer is quietly grading you against SOLID principles. They aren't waiting for you to name-drop the acronym. Instead, they want to see you apply the concepts naturally. The two most critical principles for the SDE-2 level are the Single Responsibility Principle (SRP) and the Open/Closed Principle (OCP).

• Single Responsibility Principle: Does your Locker class hold state information while also handling database saving logic? If so, you just failed SRP. The Locker should only represent the physical entity. A separate LockerRepository needs to handle data persistence.
• Open/Closed Principle: Can your system accept new behaviors without modifying existing source code? Using the Specification Pattern in the File Search problem perfectly demonstrates OCP.
• Liskov Substitution Principle: If you create a subclass, can it replace its parent class without breaking the program? Ensure your inheritance hierarchies make logical sense and never force subclasses to implement methods they don't actually need.
• Interface Segregation Principle: Keep your interfaces small and highly focused. Instead of building one massive IMachine interface, break it down into IScanner, IKeypad, and IDisplay.
• Dependency Inversion Principle: High-level modules shouldn't depend on low-level modules. Both should depend entirely on abstractions. Pass interfaces into your constructors rather than instantiating concrete classes directly inside your services.

The Live Coding Trap: Why Pseudo-Code and Over-Engineering Fail

Candidates constantly make the mistake of spending 20 minutes drawing UML diagrams, only to follow up with high-level pseudo-code that can't compile. Amazon SDE-2 interviews demand executable, or at least near-executable, object-oriented code. You have to define the actual class structures, type signatures, and the core algorithmic logic. If they ask you to design a Parking Lot, you need to write the actual code that parks the vehicle and calculates the fee. Empty method stubs won't cut it.

How to Use AcePrompt AI to Co-Pilot Your Live OOD and LLD Rounds

Mastering low-level design takes intense practice. Performing under the pressure of a live interview, however, is a completely different skill. Trying to remember the exact implementation details of the Strategy Pattern while simultaneously fielding behavioral questions can overwhelm even the most seasoned senior engineers. That's exactly where having a real-time copilot becomes invaluable.

AcePrompt AI listens to your live interview and delivers structured, highly technical guidance right to your screen. If your interviewer asks you to add a new filter to your File Search API, AcePrompt instantly suggests the Specification Pattern. It outlines the exact interfaces and composite classes you need to write. The tool helps you stay focused on clean architecture and SOLID principles without losing your train of thought, ensuring you deliver a flawless, easily extensible design.