Steps in LLD Interview

Introduction: The LLD Interview Process

When faced with an LLD interview problem, it’s crucial to follow a systematic approach. Jumping straight to code is a common mistake that leads to poor designs. Instead, follow these proven steps to create clean, maintainable solutions.

The Golden Rule

Think before you code! A well-thought-out design saves time and leads to better solutions. Always follow the systematic approach.

The LLD Interview Flow

---

Step 1: Clarify Requirements

Before you start designing, make sure you understand the problem!

Why This Step Matters

Jumping to solutions without understanding requirements leads to:

• ❌ Missing important features
• ❌ Over-engineering
• ❌ Wrong assumptions
• ❌ Wasted time

What to Ask

Functional Requirements:

• What are the core features?
• What are the use cases?
• What are the constraints?

Non-Functional Requirements:

• Scale requirements?
• Performance expectations?
• Availability needs?

Edge Cases:

• What happens in error scenarios?
• What are the boundary conditions?

Example: Parking Lot System

Interviewer: “Design a Parking Lot System”

Good Questions to Ask:

1. “What types of vehicles are supported?” (Car, Motorcycle, Truck)
2. “How many spots are there?” (Fixed number or configurable?)
3. “Do we need to track parking duration?” (For billing)
4. “What happens when the lot is full?” (Reject or waitlist?)
5. “Do we need different pricing for different vehicle types?”
6. “Do we need to support multiple parking lots?”

Bad Approach:

• “I’ll assume cars only and 100 spots”
• “Let me start coding right away”

Interview Tip

Always ask clarifying questions! Interviewers want to see that you think before you code. It shows maturity and systematic thinking.

Visual: Clarification Process

---

Step 2: Identify Actors

Actors are the users or external systems that interact with your system.

What Are Actors?

Actors represent:

• Users - People who use the system
• External Systems - Other systems that interact with yours
• Administrators - People who manage the system

How to Identify Actors

Ask yourself:

• Who will use this system?
• What are their roles?
• What actions can they perform?

Example: Parking Lot System

Actors:

1. Driver - Parks and retrieves vehicles
2. Admin - Manages parking lot (add spots, view reports)
3. System - Automated processes (billing, notifications)

Visual: Actors in Parking Lot System

Actor Identification Tip

Think about who interacts with the system, not what the system does. Actors are external to your system!

Common Actors in Different Systems

System	Actors
Library Management	Librarian, Member, System
Restaurant	Customer, Waiter, Chef, Manager
ATM	Customer, Bank, System
Elevator	Passenger, Maintenance, System

---

Step 3: Identify Entities

Entities are the core objects/concepts in your system that have data and behavior.

What Are Entities?

Entities represent:

• Core Objects - Main concepts in your system
• Data Holders - Objects that store information
• Business Objects - Objects that represent business concepts

How to Identify Entities

Look for:

• Nouns in the problem statement
• Things that have properties
• Objects that need to be tracked
• Concepts that have state

Example: Parking Lot System

Entities:

1. ParkingLot - The parking lot itself
2. ParkingSpot - Individual parking spaces
3. Vehicle - Cars, motorcycles, trucks
4. Ticket - Parking ticket issued to driver
5. Payment - Payment transaction

Visual: Entities in Parking Lot System

Entity Identification Tip

Entities are usually nouns in your problem statement. They represent things that exist in your system and have properties/state.

Entity vs Actor

Key Difference:

• Actor = External user/system that interacts with your system
• Entity = Internal object/concept within your system

Example:

• Driver (Actor) uses ParkingLot (Entity)
• Admin (Actor) manages ParkingSpot (Entity)

---

Step 4: Assign Responsibilities

Each class should have a single, well-defined responsibility (Single Responsibility Principle).

Why This Step Matters

Proper responsibility assignment leads to:

• ✔ Maintainable code - Easy to understand and modify
• ✔ Testable code - Easy to write unit tests
• ✔ Reusable code - Classes can be reused
• ✔ SOLID principles - Follows best practices

How to Assign Responsibilities

For each entity, ask:

• What does this entity do?
• What data does it hold?
• What operations does it perform?

Example: Parking Lot System

ParkingLot Responsibilities:

• Manage parking spots
• Assign spots to vehicles
• Find available spots
• Release spots when vehicles leave

ParkingSpot Responsibilities:

• Track its own state (occupied/available)
• Know its type (car/motorcycle/truck)
• Know its location/ID

Ticket Responsibilities:

• Store entry time
• Store vehicle information
• Calculate parking duration

Payment Responsibilities:

• Process payment
• Calculate amount based on duration
• Store payment details

Visual: Responsibility Assignment

Common Mistake

Don’t put everything in one class! Each class should have a single, well-defined responsibility. This is the Single Responsibility Principle (SRP).

Responsibility Checklist

For each class, ensure:

• Single Responsibility - One reason to change
• Cohesive - Methods are related
• Focused - Not doing too much
• Clear Purpose - Easy to understand what it does

---

Step 5: Design Class Diagrams

Class diagrams show the structure of your system - classes, their attributes, methods, and relationships.

Why Class Diagrams Matter

Class diagrams help you:

• Visualize structure - See how classes relate
• Identify relationships - Inheritance, composition, association
• Plan implementation - Know what to code
• Communicate design - Share your design with interviewer

Key Elements of Class Diagrams

1. Classes - With attributes and methods
2. Relationships - Inheritance, composition, association
3. Interfaces - Abstract contracts
4. Access Modifiers - Public, private, protected

Example: Parking Lot System Class Diagram

Visual: Class Relationships

[Class Diagram](/interview-guide/05-class-diagrams/) Best Practices

• Use composition for “has-a” relationships (ParkingLot has ParkingSpots)
• Use inheritance for “is-a” relationships (Car is a Vehicle)
• Use association for “uses” relationships (Ticket references Vehicle)
• Keep relationships clear and meaningful

---

Step 6: Define Contracts & APIs

Contracts define how classes interact - method signatures, interfaces, and API contracts.

Why Contracts Matter

Well-defined contracts:

• Enable testing - Clear interfaces to mock
• Enable flexibility - Can swap implementations
• Document behavior - Clear what methods do
• Prevent errors - Compile-time checks

What to Define

1. Method Signatures - Parameters, return types, exceptions
2. Interfaces - Abstract contracts for classes
3. API Contracts - If designing APIs, define endpoints
4. Preconditions/Postconditions - What’s expected

Example: Parking Lot System Contracts

ParkingLot Interface:

Payment Interface:

Visual: API Contracts

Contract Design Tips

• Be explicit - Clear parameter types and return types
• Document exceptions - What can go wrong?
• Keep it simple - Don’t over-complicate
• Think about callers - What do they need?

---

Step 7: Handle Edge Cases

Edge cases are scenarios that might not be obvious but are important to handle.

Why Edge Cases Matter

Handling edge cases shows:

• Mature thinking - You consider all scenarios
• Production readiness - Real systems have edge cases
• Attention to detail - You think thoroughly
• Error handling - You plan for failures

Common Edge Cases

1. Null/Empty Inputs - What if input is null or empty?
2. Boundary Conditions - What if at limits?
3. Concurrent Access - What if multiple users?
4. Error Scenarios - What if something fails?
5. Invalid States - What if system is in wrong state?

Example: Parking Lot System Edge Cases

Edge Cases to Handle:

1. Parking lot is full

   • Return appropriate exception
   • Don’t crash

2. Invalid vehicle type

   • Validate vehicle type
   • Return clear error message

3. Invalid ticket

   • Validate ticket exists
   • Check ticket hasn’t been used

4. Concurrent parking

   • Handle race conditions
   • Use locks/synchronization

5. Payment failure

   • Handle payment errors
   • Don’t release spot if payment fails

Visual: Edge Case Handling

Edge Case Checklist

Always think about:

• What if input is null/empty?
• What if system is full?
• What if something fails?
• What if multiple users?
• What if invalid state?

---

Step 8: Code Implementation

Finally, implement your design in code (or pseudo-code).

Implementation Guidelines

1. Follow your design - Implement what you designed
2. Clean code - Readable, maintainable
3. SOLID principles - Apply what you learned
4. Design patterns - Use appropriate patterns
5. Error handling - Handle edge cases

Example: Parking Lot System Implementation

---

Complete Process Flow

Visual Summary of All Steps

Step-by-Step Checklist

Use this checklist for every LLD interview:

• Step 1: Clarify requirements - Ask questions
• Step 2: Identify actors - Who uses the system?
• Step 3: Identify entities - What are the core objects?
• Step 4: Assign responsibilities - What does each class do?
• Step 5: Design class diagrams - Show relationships
• Step 6: Define contracts & APIs - Method signatures
• Step 7: Handle edge cases - Error scenarios
• Step 8: Code implementation - Write clean code

Practice Makes Perfect

Practice this process with different problems! The more you practice, the more natural it becomes. Start with simple problems and gradually move to complex ones.

---

Next Steps: Deep Dive into Each Step

Now that you understand the high-level process, let’s dive deep into each step:

Next: Identifying Actors & Entities →

This next guide will teach you how to systematically identify actors and entities with detailed examples and visual diagrams!

---

Summary

Key Takeaways

✔ Follow a systematic approach - Don’t jump to code
✔ Clarify requirements first - Ask questions
✔ Identify actors - Who uses the system?
✔ Identify entities - What are the core objects?
✔ Assign responsibilities - Single Responsibility Principle
✔ Design class diagrams - Visualize structure
✔ Define contracts - Clear interfaces
✔ Handle edge cases - Think about errors
✔ Implement cleanly - Follow your design

Remember

LLD interviews are about demonstrating:

• Systematic thinking
• Clean design skills
• Communication ability
• Production-ready mindset

Master these steps, and you’ll excel in any LLD interview! 🚀