Top 20 Low Level Design Interview Questions [2026 Guide]
![Top 20 Low Level Design Interview Questions [2026 Guide]](/images/blog/low-level-design-interview-questions-thumbnail.png)
Top 20 Low Level Design Interview Questions [2026 Guide]
You’ve cleared the DSA round. Now the interviewer says: “Design a parking lot system. You have 60 minutes.”
No LeetCode tricks. No sorting algorithms. Just you, a blank editor, and the expectation that you’ll produce a clean, extensible, well-designed system from scratch.
This is the Low Level Design (LLD) interview—also called the machine coding round or Object-Oriented Design (OOD) interview. And it’s the round that catches the most people off guard.
What LLD Interviews Actually Test
LLD interviews don’t test whether you can write code. They test whether you can think in systems—identify the right classes, define clean interfaces, apply design patterns, and handle edge cases. The code is just how you demonstrate the thinking.
We’ve curated the 20 most commonly asked LLD problems across FAANG, startups, and top tech companies—organized by difficulty so you can build up gradually. For each problem, we include the key concepts tested, an approach hint, and which companies ask it.
Before You Start: The LLD Interview Framework
Every LLD problem follows the same structure. Nail this framework and you’ll have a consistent approach for any question:
Clarify Requirements (3-5 minutes)
Ask about scope, constraints, and edge cases. “Should the parking lot support multiple floors?” “Do we need real-time availability?” Never assume—interviewers want to see you ask smart questions.
Identify Core Entities (5 minutes)
List the nouns from requirements—these become your classes. Identify the verbs—these become your methods. Draw relationships between entities.
Design Class Structure (10-15 minutes)
Define classes, interfaces, enums. Apply SOLID principles. Choose appropriate design patterns. This is where most of your score comes from.
Implement Key Methods (15-25 minutes)
Write the core logic. Focus on the most important flows first. Don’t try to implement everything—prioritize what demonstrates your design thinking.
Discuss Trade-offs (5 minutes)
Talk about what you’d change for scale, concurrency, or different requirements. This shows senior-level thinking.
Easy Problems (Start Here)
These are the best problems to begin your LLD journey. They have well-defined scope, straightforward requirements, and let you practice core OOP concepts without overwhelming complexity.
Easy ≠ Simple
“Easy” means the requirements are clear and the scope is manageable. You still need clean class design, proper use of patterns, and solid SOLID principles. Many candidates fail easy problems because they skip the design step.
1. Parking Lot System
Beginner-Friendly The #1 LLD QuestionAsked at: Amazon, Google, Microsoft, Adobe, Uber, Grab, Gojek
What it tests:
- Class hierarchy for different vehicle and spot types
- Singleton pattern for the parking lot itself
- Factory pattern for ticket/spot creation
- Strategy pattern for pricing and spot allocation
Approach hint: Start with the core entities: ParkingLot, ParkingFloor, ParkingSpot, Vehicle, Ticket. Use an enum for spot types (Compact, Regular, Large). The key design decision is how to allocate spots—a strategy pattern lets you swap between nearest-to-entrance, first-available, or floor-based allocation.
Why it’s #1: It’s simple enough to complete in 45 minutes but rich enough to demonstrate every major design principle. If you can only practice one problem, make it this one.
2. LRU Cache
Easy Data Structure + DesignAsked at: Google, Amazon, Microsoft, Facebook, Adobe, Netflix
What it tests:
- HashMap + Doubly Linked List for O(1) operations
- Clean API design (
get,put,delete) - Capacity management and eviction logic
- Thread safety (bonus)
Approach hint: The core insight is combining two data structures: a hash map for O(1) key lookup and a doubly linked list for O(1) removal and insertion. Every get moves the node to the head. Every put adds to the head and evicts from the tail if at capacity.
Why it’s important: Tests your ability to choose the right data structure for performance requirements—a fundamental LLD skill.
3. Vending Machine
Easy State Pattern ClassicAsked at: Google, Amazon, Microsoft, Apple, Oracle
What it tests:
- State pattern (Idle, HasMoney, Dispensing, OutOfStock)
- Inventory management
- Change calculation algorithm
- Error handling for insufficient funds
Approach hint: The vending machine is a textbook state machine. Define states as classes implementing a common interface with methods like insertMoney(), selectProduct(), dispense(). Each state handles these methods differently. The machine delegates to its current state.
Why it’s important: The state pattern appears in at least 30% of LLD problems. Master it here and you’ll recognize it everywhere.
4. Chess Game
Easy Complex Entity ModelingAsked at: Amazon, Adobe, Facebook, Microsoft, Games24x7
What it tests:
- Class hierarchy for pieces (King, Queen, Rook, Bishop, Knight, Pawn)
- Move validation with polymorphism
- Board state management
- Game flow (turns, check, checkmate detection)
Approach hint: Create an abstract Piece class with a canMove(board, start, end) method. Each piece type overrides this with its specific movement rules. The Board holds an 8x8 grid of Piece references. The Game class manages turns and checks win conditions.
Why it’s important: Forces you to think about inheritance hierarchies, polymorphism, and complex validation logic—all in one problem.
5. Library Management System
Easy CRUD + Business RulesAsked at: Amazon, Adobe, Microsoft, Oracle, Wipro
What it tests:
- Entity modeling (Book, Member, Loan, Reservation)
- Business rule enforcement (max 5 books, overdue fines)
- Observer pattern for reservation notifications
- Search functionality with multiple criteria
Approach hint: Focus on the Loan lifecycle: borrow → due date → return (or overdue → fine). Use an observer to notify members when reserved books become available. The search can use a strategy pattern for different search criteria (by title, author, ISBN).
Why it’s important: Teaches you to model real-world business rules as clean class interactions—the essence of LLD.
6. Logging Framework
Easy Chain of ResponsibilityAsked at: Amazon, Google, Microsoft, Apple, Splunk
What it tests:
- Chain of Responsibility pattern for log level filtering
- Strategy pattern for different output formats (JSON, plain text)
- Decorator pattern for adding metadata (timestamps, thread info)
- Multiple output destinations (console, file, network)
Approach hint: The core design is a chain of handlers. Each handler checks if it should process the log message (based on level), processes it, then passes to the next handler. Use a strategy for formatting and a factory for creating pre-configured logger instances.
Why it’s important: One of the few problems that naturally uses three design patterns together. Great for demonstrating pattern composition.
7. Elevator System
Easy State + StrategyAsked at: Amazon, Microsoft, Uber, Google, Adobe, Lyft
What it tests:
- State management (Moving Up, Moving Down, Idle, Doors Open)
- Request dispatching strategy
- Observer pattern for floor display updates
- Queue management for pending requests
Approach hint: Model the elevator as a state machine. The key design decision is the dispatching strategy—how do you decide which elevator handles a request? Use the strategy pattern so you can swap between SCAN (nearest in direction), FCFS, or shortest-seek-time algorithms.
Why it’s important: Frequently asked with follow-ups: “Now add multiple elevators.” “Now optimize for energy efficiency.” The strategy pattern makes these extensions trivial.
Medium Problems (Interview Core)
These problems add complexity: concurrent access, multiple interacting components, and non-trivial algorithms. This is the difficulty level of most actual LLD interviews.
Time Management Is Critical
Medium problems are hard to finish in 45-60 minutes. Prioritize: get the class structure and key interactions right first. A well-designed incomplete solution beats a fully coded mess every time.
8. Rate Limiter
Medium Algorithm-HeavyAsked at: Stripe, Google, Amazon, Facebook, Twitter, Cloudflare
What it tests:
- Multiple rate limiting algorithms (Token Bucket, Sliding Window, Fixed Window)
- Strategy pattern for swapping algorithms
- Thread safety with concurrent requests
- Configuration management (different limits for different APIs)
Approach hint: Define a RateLimiter interface with an allowRequest(clientId) method. Implement Token Bucket (simple, bursty), Sliding Window Log (precise, memory-heavy), and Fixed Window Counter (efficient, boundary issues) as strategies. Use a factory to create the right limiter based on configuration.
Why it’s important: Bridges LLD and system design. Understanding rate limiting algorithms deeply is valuable for both interview types.
9. URL Shortener
Medium HLD-LLD CrossoverAsked at: Google, Microsoft, Amazon, Facebook, Twitter, LinkedIn
What it tests:
- ID generation strategies (Base62, hashing, counter-based)
- Repository pattern for data access
- Caching layer design
- API contract design
Approach hint: The core challenge is generating unique short codes. Use a strategy pattern for the ID generator: Base62IDGenerator (counter + base conversion), HashIDGenerator (MD5/SHA + truncation), UUIDGenerator. Separate the URL shortening service from storage using a repository interface.
Why it’s important: One of the most asked questions across all interview types. The LLD version focuses on the class design rather than distributed system concerns.
10. Meeting Room Reservation System
Medium Conflict DetectionAsked at: Microsoft, Google, Amazon, Meta
What it tests:
- Time-based conflict detection algorithms
- Recurring booking support
- Observer pattern for booking notifications
- State management for rooms (available, booked, maintenance)
Approach hint: The key method is isAvailable(room, startTime, endTime) which checks for overlapping bookings. Store bookings sorted by start time for efficient conflict checks. Use an observer to notify attendees of booking changes and a state pattern for room status.
Why it’s important: Time-based conflict detection is a common sub-problem that appears in many LLD questions (train platforms, hotel reservations, theater booking).
11. Restaurant Food Ordering System
Medium Real-World ComplexAsked at: Zomato, Swiggy, DoorDash, Uber Eats, Amazon
What it tests:
- Order state machine (Placed → Confirmed → Preparing → Ready → Delivered)
- Strategy pattern for delivery assignment
- Observer pattern for order status updates
- Multiple interacting entities (Restaurant, Menu, Order, DeliveryAgent, Customer)
Approach hint: Model the order lifecycle as a state machine. The delivery assignment is a strategy: nearest-agent, least-busy-agent, or zone-based. Use observers so customers get real-time status updates. The menu should support categories, pricing, and availability.
Why it’s important: If you’re interviewing at food-tech companies (Zomato, Swiggy, DoorDash), this is almost guaranteed. But it’s also excellent practice for any complex real-world modeling.
12. Order Matching Engine
Medium Finance DomainAsked at: Goldman Sachs, Morgan Stanley, Coinbase, Robinhood, Google
What it tests:
- Price-time priority matching algorithm
- Order book with sorted data structures
- Command pattern for order operations
- Partial fill handling and order lifecycle
Approach hint: The order book maintains buy orders sorted by price (descending) and sell orders sorted by price (ascending). When a new order arrives, try to match it against the opposite side. Use a priority queue (sorted by price, then timestamp) for each side.
Why it’s important: The go-to question for fintech interviews. The matching algorithm is genuinely interesting and tests your data structure skills.
13. Elevator System - Multiple Lifts
Medium Load BalancingAsked at: Amazon, Microsoft, Uber, Google, Adobe, Lyft
What it tests:
- Multi-elevator dispatching strategy
- Load balancing across elevators
- State management for multiple concurrent elevators
- Extension of the single elevator design
Approach hint: This builds on Problem #7. The new challenge is the Dispatcher that decides which elevator handles each request. Strategies include: nearest elevator, least loaded, zone-based (elevator 1 handles floors 1-10, elevator 2 handles 11-20). Each elevator runs independently with its own state machine.
Why it’s important: A common follow-up to the basic elevator problem. Tests your ability to extend a design without breaking existing code—the Open/Closed Principle in action.
14. Car Rental System
Medium Booking + PricingAsked at: Uber, Lyft, Airbnb, Booking.com
What it tests:
- Booking lifecycle (Reserve → Active → Returned)
- Strategy pattern for pricing (daily, hourly, weekend, insurance add-ons)
- Vehicle hierarchy (Sedan, SUV, Truck, Luxury)
- Inventory management and availability checks
Approach hint: The pricing strategy is the interesting design decision. Use a decorator pattern to layer pricing: base price + insurance + weekend surcharge + loyalty discount. The booking system needs conflict detection similar to the meeting room problem.
Why it’s important: Combines booking logic, pricing strategies, and inventory management—three patterns that appear across many interview problems.
Hard Problems (Senior Level)
These problems test advanced concepts: thread safety, distributed patterns, complex algorithms, and production-grade error handling. Expect these at senior engineer interviews or companies with high design bars.
Don't Start Here
If you’re new to LLD, start with Easy and Medium problems first. Hard problems assume you already have pattern recognition and can design clean class structures quickly. Jumping here too early will be frustrating and unproductive.
15. Parking Lot - Multi-Threaded
Hard ConcurrencyAsked at: Amazon, Google, Microsoft, Adobe, Uber, Grab
What it tests:
- Thread safety for concurrent entry/exit
- Deadlock prevention strategies
- Fair queuing for spot allocation
- Atomic operations for spot status updates
Approach hint: The single-threaded parking lot becomes tricky when multiple cars enter simultaneously. Use locks at the spot level (not the lot level) for fine-grained concurrency. A fair queue ensures cars are served in order. The key pitfall is deadlock when a car holds a floor lock and waits for a spot lock.
Why it’s important: Concurrency is the most common follow-up for any LLD problem. “Now make it thread-safe” turns an easy problem into a hard one.
16. Payment Processor
Hard Idempotency + StateAsked at: Stripe, PayPal, Square, Google, Amazon, Visa
What it tests:
- Idempotency for payment operations (no double charges)
- Transaction state machine (Initiated → Processing → Completed/Failed/Refunded)
- Retry logic with exponential backoff
- Multiple payment method support via strategy pattern
- Command pattern for reversible operations (refunds)
Approach hint: The idempotency key is critical—every payment request must have a unique key, and duplicate keys return the cached result instead of processing again. Model the transaction as a state machine. Use the command pattern so refunds can reverse the original payment operation.
Why it’s important: If you’re interviewing at any fintech or payments company, this is likely. The idempotency and retry patterns are valuable in many other contexts too.
17. Notification Service
Hard Multi-Channel DeliveryAsked at: Amazon, Uber, LinkedIn, Twitter, Flipkart
What it tests:
- Template method pattern for notification lifecycle
- Factory pattern for channel-specific senders (Email, SMS, Push)
- Strategy pattern for delivery prioritization
- Rate limiting per user/channel
- Retry logic with backoff for failed deliveries
Approach hint: Define a base NotificationSender with template methods: validate(), format(), send(), handleFailure(). Each channel (Email, SMS, Push) overrides the channel-specific parts. Use a factory to create the right sender based on notification type. Add a retry queue for failed deliveries with exponential backoff.
Why it’s important: Real-world notification systems are complex. This problem tests your ability to design for extensibility (new channels), reliability (retries), and user experience (rate limiting).
18. Task Scheduler
Hard DAG DependenciesAsked at: Google, Amazon, Microsoft, Facebook, Uber
What it tests:
- DAG (Directed Acyclic Graph) for task dependencies
- Topological sort for execution ordering
- Priority-based scheduling with a min-heap
- Retry logic with exponential backoff
- Concurrent task execution management
Approach hint: Model tasks as nodes in a DAG with dependency edges. Use topological sort to determine execution order—only schedule a task when all its dependencies are complete. A priority queue orders ready tasks by priority. Track task states (Pending, Running, Completed, Failed) with a state machine.
Why it’s important: Tests your algorithm skills (topological sort, priority queues) alongside your design skills. This combination is what makes it hard.
19. Cache Manager
Hard Eviction StrategiesAsked at: Google, Amazon, Microsoft, Facebook, Salesforce
What it tests:
- Multiple eviction strategies (LRU, LFU, TTL-based)
- Strategy pattern for swapping eviction policies
- Thread-safe operations
- TTL expiration with lazy and eager cleanup
- Cache statistics and monitoring
Approach hint: Build on the LRU Cache (#2) by adding: (1) a strategy interface for eviction (LRUEviction, LFUEviction, TTLEviction), (2) a TTL expiration mechanism using a separate cleanup thread or lazy deletion on access, (3) thread safety with read-write locks for concurrent access.
Why it’s important: This is the “hard mode” version of LRU Cache. It tests whether you can scale a simple design to handle multiple requirements without it becoming a mess.
20. Feed Generator
Hard Ranking + AggregationAsked at: Facebook, Instagram, Twitter, LinkedIn, Pinterest
What it tests:
- Content aggregation from multiple sources
- Ranking algorithm with strategy pattern
- Observer pattern for new content notifications
- Caching for pre-computed feeds
- Pagination and lazy loading
Approach hint: The feed generator pulls content from multiple sources (friends’ posts, followed pages, ads). A ranking strategy scores each item based on recency, engagement, user preferences, etc. The ranked items are cached per user. Use an observer so new high-priority content can invalidate the cache.
Why it’s important: If you’re interviewing at any social media company, this is a likely question. The ranking algorithm design is the differentiator—show you can think beyond simple chronological ordering.
Which Companies Ask Which Problems?
Different companies have different favorites. Here’s a pattern guide:
Favorites: Parking Lot, LRU Cache, Rate Limiter, Meeting Room, Elevator System, Task Scheduler
What they emphasize: Clean abstractions, SOLID principles, extensibility, edge case handling. Google especially cares about your ability to discuss trade-offs.
Difficulty range: Easy to Hard, depending on the level. L4 gets Easy/Medium, L5+ gets Medium/Hard.
Favorites: Payment Processor, Order Matching Engine, Rate Limiter, Cache Manager
What they emphasize: Correctness over everything. Idempotency, transaction safety, and financial accuracy. Concurrency handling is a must.
Difficulty range: Medium to Hard. These companies have a high design bar.
Favorites: Restaurant Ordering, Parking Lot, Notification Service, Elevator System, Car Rental
What they emphasize: Real-time state management, dispatch/matching algorithms, multi-entity interactions. These companies love the machine coding format.
Difficulty range: Easy to Medium with a focus on completing working code.
Favorites: Feed Generator, Chat Room, Notification Service, URL Shortener
What they emphasize: Scale thinking even in LLD, caching strategies, event-driven patterns. They want to see you think about what happens at millions of users.
Difficulty range: Medium to Hard. The problems are deceptively simple but have deep complexity.
Design Patterns Cheat Sheet
These are the patterns that appear most across all 20 problems:
| Pattern | Frequency | Key Problems |
|---|---|---|
| Strategy | 18/20 problems | Rate Limiter, Feed Generator, Elevator, Pricing |
| State | 12/20 problems | Vending Machine, Order lifecycle, Elevator, Payment |
| Observer | 10/20 problems | Notifications, Reservations, Feed updates |
| Factory | 9/20 problems | Parking spots, Notifications, Loggers |
| Command | 3/20 problems | Order Matching, Payment (refunds), Task Scheduler |
| Chain of Responsibility | 1/20 problems | Logging Framework |
| Decorator | 2/20 problems | Logging, Pricing layers |
| Template Method | 1/20 problems | Notification Service |
If you only learn four patterns, make them Strategy, State, Observer, and Factory. They cover 90% of LLD interviews.
Learn each pattern in depth: Strategy | State | Observer | Factory
Your Study Plan
If You Have 2 Weeks
- Week 1: Problems #1-7 (Easy) — one per day
- Week 2: Problems #8-14 (Medium) — one per day
- Skip Hard unless targeting senior roles
- Focus on getting class structure right every time
If You Have 1 Month
- Week 1-2: Problems #1-7 (Easy) — practice twice each
- Week 2-3: Problems #8-14 (Medium) — practice twice each
- Week 4: Problems #15-20 (Hard) — attempt each once
- Revisit any problem you struggled with
For a more structured approach, check our 15/30/90-day study plans or the guided learning path.
Key Takeaways
Remember These
- Start with the framework: Requirements → Entities → Class Structure → Implementation → Trade-offs
- Design before code: Spending 10 minutes on design saves 30 minutes of refactoring
- Know the top 4 patterns: Strategy, State, Observer, Factory cover 90% of problems
- Practice by difficulty: Easy → Medium → Hard, not random
- Understand the company: Different companies emphasize different things
- Time management matters: A well-designed partial solution beats a complete mess
- Practice with feedback: Use our LLD Playground where every problem has solutions in 6 languages and AI-powered code review
“Design is not just what it looks like and feels like. Design is how it works.” — Steve Jobs
Ready to start practicing? Pick Problem #1, set a 60-minute timer, and go. That’s how you build the muscle memory that makes LLD interviews feel natural.
Recommended reading:
- What is Low Level Design? — Understand the fundamentals
- HLD vs LLD — Know the difference for system design rounds
- SOLID Principles — The foundation of clean design