11 · DEBUG LAB
Annotate what’s broken before the interviewer does.
Authored UML diagrams with real violations. Annotate what you see — God Class, SRP breach, wrong inheritance — then compare your critique to the expected breakdown.
– db: DatabaseConn
– emailSvc: EmailService
– payment: PayPal
– logger: Logger
– cache: Redis
+ book()
+ cancel()
+ notify()
+ pay()
+ log()
+ cache()
– gateway: Gateway
– config: Config
+ charge(amount)
+ refund(txId)
– smtp: SMTPClient
– templates: Map
– log: FileLogger
+ send(to, body)
+ renderTemplate(id)
+ logSent(id)
– host: String
– pool: ConnPool
+ query(sql)
+ execute(sql)
Your annotations
BookingService — God Class
EmailService — SRP Breach
Direct DB dependency — tight coupling
Violation catalogue
The violations you’ll learn to spot.
GOD CLASS
BookingService · 247 lines · 9 responsibilitiesSingle class handling DB access, payment, email, logging, and caching — the most common and most damaging violation.
SRP BREACH
EmailService · sends, renders templates, logsA class responsible for multiple unrelated concerns — the principle most often cited in post-interview feedback.
WRONG INHERITANCE
StorageService extends BaseHandler · not an IS-AInheritance used for code reuse rather than a true IS-A relationship — syntactically valid but semantically broken.
TIGHT COUPLING
OrderController → PaymentGatewayImpl · concrete depClasses that depend directly on concrete implementations — making every change expensive and testing impossible.
How it works
Three steps from broken diagram to sharp diagnosis.
Study the broken diagram
An authored UML diagram of a real system — booking engine, auth module, payment flow — deliberately designed with violations. No hints, no labels.
Annotate the violations
Mark what is wrong and explain your reasoning. No checklist guides you — you decide what to flag, just as a senior reviewer would in a real design critique.
Compare with expected
Your annotations sit side-by-side with the authoritative breakdown. Every violation explained: what it is, why it matters, what the correct structure looks like.
Your annotation vs. the expected breakdown.
See exactly what you caught, what you missed, and what the authoritative diagnosis says.
Your annotations
Expected breakdown
BookingService — handles too many things (God Class)
BookingService — God Class: DB access, payment, email, logging, caching all in one class. Extract into focused services.
EmailService — sends emails AND renders templates AND logs. SRP breach.
EmailService — SRP Breach: template rendering is a separate concern. Split into EmailSender + TemplateRenderer.
Not annotated
Direct DatabaseConn dependency — tight coupling to a concrete class. Should depend on a Repository interface.
Who it’s for
Built for engineers who need a sharper critical eye.
The interview candidate
Engineers who can design a system from scratch but struggle to critique an existing design when asked in interviews.
The senior aspirant
SDE-2 and senior candidates facing design review rounds where critiquing a peer's design is part of the evaluation.
The SOLID theorist
Anyone who knows the SOLID principles in theory but has never practised applying them as a lens to critique real designs.
The vocabulary seeker
Candidates who want to build the language to explain design problems clearly, not just feel like something is wrong.
FAQ
Questions people ask
→ Explore more