15 · CHANGE ONE THING
A new requirement arrives mid‑design. Absorb it.
The moment every interviewer loves: “now what if we also need to support X?” Change One Thing gives you that moment — with blast‑radius scoring and OCP validation.
Svc
Svc
Svc
Layer
4 existing classes modified — 4 regression risks
Payment+NEW
Svc
Svc
Svc
Layer
0 existing classes modified — 0 regression risks
The Open-Closed Principle, made visual.
Open for extension, closed for modification — the principle that separates extensible designs from fragile ones.
Open for
Extension
Add new payment method → new class
Existing classes unchanged
Blast radius: 0
New requirement → new class
Closed for
Modification
Adding new payment method → modify PaymentService
Modify OrderService, UserService, Controller
Blast radius: 4
New requirement → edit existing classes
“Open for extension, closed for modification — the principle that separates extensible designs from fragile ones.”
Requirement change types you’ll practice.
Each scenario starts with a clean design and introduces a realistic extension challenge.
Payment System
Add a payment method
The payment pipeline already handles card and PayPal. A new cryptocurrency method arrives. Can your design absorb it without touching the existing payment processors?
Notification Pipeline
Add a notification channel
Notifications go out via email. The product team now wants SMS. Does adding a channel mean touching the notification dispatcher, or just adding a new sender implementation?
Export System
Add an export format
Reports can be exported as PDF. A request comes in for CSV export. Can the export engine accommodate a new format by addition only — or does it need surgery?
Pricing Engine
Add a discount type
The pricing engine applies a percentage discount. A new fixed-amount discount is required. The question: did the original design anticipate this, or does it need a rewrite?
How it works.
Four steps from existing design to blast-radius score.
Read the design
A complete, clean design for a known system. Understand the class structure and responsibilities before the change arrives.
Receive the change
A new requirement: “support a new payment method,” “add a notification channel.” Absorb it with minimal disruption.
Apply minimal change
Modify the design. New classes are always free — modifications to existing ones accumulate blast radius.
See the comparison
Your design vs. the ideal OCP-compliant solution. Blast radius, which classes you touched, and how the ideal differs.
Blast radius measurement
Your score includes a blast radius count — how many existing classes you modified. Lower is better. The ideal solution's blast radius is shown for comparison.
OCP validation
The validator checks whether your change is Open-Closed Principle compliant: open for extension (you added new classes), closed for modification (you did not change existing ones).
Extensibility scoring
Beyond OCP, your solution is scored on extensibility: would adding a third variant require another round of modifications, or is your design already prepared for it?
Real interview format
This is the exact format of the "what if requirements change" follow-up that interviewers use to probe whether your initial design was truly extensible or just locally tidy.
Mid-design surprise
The requirement arrives after you have studied the starting design — simulating the moment in an interview when the interviewer introduces a constraint you did not anticipate.
Comparison to ideal fix
The ideal solution is shown alongside yours after you submit. Every difference is explained — you learn not just that you could have done better, but exactly how.
Who it’s for.
If you know OCP exists but struggle to apply it under pressure, this is your practice ground.
Engineers who understand the Open-Closed Principle in theory but cannot apply it quickly under interview pressure.
Candidates who get follow-up questions like “what if we also need to support X?” and do not know where to start.
Anyone whose initial designs tend to require large-scale rework when requirements change — the hallmark of an OCP-unaware design.
Senior engineers who want to demonstrate design foresight and extensibility reasoning in principal/staff-level interviews.
FAQ
Questions people ask
→ Explore more