Goal: “Good code isn’t clever code — it’s code that’s easy to change.” — We’ve been designing systems at 50,000 feet. Now we zoom in. This week is about writing code that doesn’t turn into a tangled mess — SOLID principles, design patterns, and thinking in objects. If HLD was about what to build, LLD is about how to build it.
Topics
| Day | Track | Focus | Topics |
|---|---|---|---|
| Mon | A — DSA Practice | Hard Problems | Solve 2-3 problems. Focus on hard-tier challenges — DP on trees, advanced graph problems, and complex backtracking. Push past the comfort zone. |
| Tue | B — LLD | OOP Foundations & SOLID (Part 1) | What is LLD? · OOP Four Pillars · Composition vs Inheritance · Abstract Classes vs Interfaces · Single Responsibility Principle · Open-Closed Principle |
| Wed | A — DSA Practice | More Hard Problems | Solve 2-3 problems. Continue with hard-tier — try a DP problem we previously skipped, or a graph problem that uses multiple techniques. |
| Thu | B — LLD | SOLID (Part 2) & Design Foundations | Liskov Substitution Principle · Interface Segregation Principle · Dependency Inversion Principle · DRY, KISS, YAGNI · Coupling and Cohesion · UML Class Diagrams |
| Fri | B — LLD | Creational Patterns | Singleton Pattern · Factory Pattern · Builder Pattern · Prototype Pattern · Adapter Pattern |
Note: SOLID principles are asked in almost every LLD interview — sometimes directly (“explain the Open-Closed Principle”), sometimes indirectly (“look at this code, what would you refactor?”). Don’t just memorize the definitions. For each principle, think of a violation and how we’d fix it. That’s what interviewers are really testing.
Key Concepts
- SOLID is the backbone of OOP design. Single Responsibility = a class should have only one reason to change. Open-Closed = open for extension, closed for modification (use abstraction). Liskov = subtypes must be substitutable for their base types without breaking behavior. Interface Segregation = don’t force classes to implement methods they don’t use. Dependency Inversion = depend on abstractions, not concretions.
- “Favor composition over inheritance” — we’ll hear this everywhere. Inheritance creates tight coupling (the “fragile base class” problem). Composition lets us mix and match behaviors at runtime. Use inheritance for “is-a” relationships, composition for “has-a.”
- UML class diagrams are the visual language of LLD interviews. We don’t need to be UML experts, but we need to draw classes, show relationships (association, aggregation, composition, inheritance), and indicate visibility (+public, -private, #protected).
- Factory pattern delegates object creation to a method — great when the exact type depends on input. Builder pattern constructs complex objects step by step — think of creating a
Pizzawith optional toppings, crust, size, etc. Singleton ensures a class has exactly one instance — use it for database connections, loggers, configuration managers. - Coupling = how much one class depends on another (low is better). Cohesion = how focused a class’s responsibilities are (high is better). Low coupling + high cohesion = maintainable code.
Practice
- DSA: Solve 4-5 hard problems this week — at least one DP on trees and one complex backtracking problem
- LLD: Implement a thread-safe Singleton, a Factory for shape creation, and a Builder for a meal order — in your preferred language
- LLD: Draw a UML class diagram for a library management system (books, members, librarians, loans)
- LLD: Take any class we’ve written before and evaluate it against each SOLID principle — what’s good, what could be better?
~17 topics + DSA practice · ~2 hrs/day · SOLID + first design patterns