Lesson 1 · 20 min · 
School guide Single responsibility and open-closed, with one refactor
- SRP: one reason to change. An OrderService that also prints invoices and sends SMS has three.
- OCP: new behaviour arrives as a new class. Splitwise split types are the classic case.
- Start from the if-else ladder, end with a SplitStrategy interface and three implementations.
- Reviewers test OCP by asking for one more variant on the spot. Flipkart's 2026 BNPL review asked for a new strategy live.
SRPOCP
Lesson 2 · 20 min · School guide Liskov, interface segregation and dependency inversion
- LSP: a subclass must work everywhere the parent works. Square extends Rectangle breaks it; so does a Bird subclass that can't fly.
- ISP: small interfaces. A Printer interface that forces fax() on every printer is the smell.
- DIP: services depend on an OrderRepository interface, not on InMemoryOrderRepository. Pass it in through the constructor.
- Why DIP pays off in machine coding: when the reviewer asks 'what if this were a database', you point to one class.
LSPISPDIPdependency injection
Lesson 3 · 12 min · 
Recursion guide DRY, KISS, YAGNI and the over-engineering trap
- The opposite failure: fourteen interfaces for a 90 minute problem. Add a pattern only where the statement asks for extensibility.
- Two pieces of code that look alike but change for different reasons are not duplication.
- Tell, don't ask: put the behaviour next to the data it changes.
DRYKISSYAGNItell don't ask
Lesson 4 · 15 min · Recursion guide Code that reads well in review
- Names: verbs for methods, nouns for classes, no temp or data1.
- Short functions, guard clauses, constants instead of magic numbers.
- Parameterise instead of hardcoding (board size, number of dice, credit limit). The Flipkart criteria a candidate shared list it by name.
- A package layout reviewers expect: models, repositories, services, strategies, exceptions, and Main.
namingguard clausemagic numberpackage layout