Concept questionMedium~7 min

Interview question

A pricing service has a growing switch for customer type, country, and promotion. How would you decide whether to introduce strategies under the open-closed principle?

Open-closed principle with strategies instead of growing flags

Uses stable extension points for genuinely variable behavior while avoiding speculative abstractions and configuration-driven branching.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would look for one stable axis of behavior that changes independently. If several pricing policies implement the same decision with different rules, a strategy interface can make each policy explicit and let a selector choose one. I would not combine country, customer type, and promotion into arbitrary classes if those dimensions interact; first I would model the actual business rule and its precedence.

Full answer below

Practice focus

Variation axes, strategy selection, stable contracts, composition, feature rules, and the cost of premature abstraction.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
The open-closed principle is about making common extensions local and safe. It does not mean existing code can never be edited or that every conditional needs an interface.
I would look for one stable axis of behavior that changes independently. If several pricing policies implement the same decision with different rules, a strategy interface can make each policy explicit and let a selector choose one. I would not combine country, customer type, and promotion into arbitrary classes if those dimensions interact; first I would model the actual business rule and its precedence.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
The calling service should depend on a small contract such as calculating an adjustment from a pricing context. Concrete strategies own their rules, while registration or a factory owns selection. Shared validation and money semantics stay outside duplicated strategy code. A simple switch can remain the clearest design when there are only two stable cases. I introduce the extension point when additions repeatedly modify risky central logic or teams need independently testable policies.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would make selection deterministic and observable. Unknown policy keys fail clearly rather than silently using a default, and configuration changes are validated before serving traffic. If policies are composed, I define ordering, whether adjustments accumulate, and which rule can stop evaluation. Contract tests protect rounding, currency, and invariants across every strategy. I would also keep a removal path because obsolete strategies and feature flags otherwise become permanent architecture. The goal is to localize meaningful variation, not to hide a large conditional behind reflection or dependency injection.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Creating an interface for every conditional.
Encoding several interacting dimensions in class names.
Letting strategy order change the result accidentally.
Using a silent default for unknown policy configuration.

Red flagsCandidateSigns the design is fragileSignals that an interviewer may treat as risky.Open details

Details

Adding one rule requires edits across every strategy.
Selection depends on hidden registration order.
Strategies duplicate core money and validation rules.
Runtime configuration can select an unregistered policy.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

When is a switch better than a strategy?
Where should strategy selection live?
How would you test composed pricing rules?

Continue practice

No explicit flow link is set yet, so these are nearby drills from the same path or taxonomy.

Abstraction vs encapsulationConcept question / Easy / ~5 minContinue Access modifiersConcept question / Easy / ~5 minContinue ActionResult vs Typed ResultsComparison question / Medium / ~7 minContinue

Opening drill

Concept questionMedium~7 min

Interview question

A pricing service has a growing switch for customer type, country, and promotion. How would you decide whether to introduce strategies under the open-closed principle?

Open-closed principle with strategies instead of growing flags

Uses stable extension points for genuinely variable behavior while avoiding speculative abstractions and configuration-driven branching.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Variation axes, strategy selection, stable contracts, composition, feature rules, and the cost of premature abstraction.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
The open-closed principle is about making common extensions local and safe. It does not mean existing code can never be edited or that every conditional needs an interface.
I would look for one stable axis of behavior that changes independently. If several pricing policies implement the same decision with different rules, a strategy interface can make each policy explicit and let a selector choose one. I would not combine country, customer type, and promotion into arbitrary classes if those dimensions interact; first I would model the actual business rule and its precedence.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
The calling service should depend on a small contract such as calculating an adjustment from a pricing context. Concrete strategies own their rules, while registration or a factory owns selection. Shared validation and money semantics stay outside duplicated strategy code. A simple switch can remain the clearest design when there are only two stable cases. I introduce the extension point when additions repeatedly modify risky central logic or teams need independently testable policies.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would make selection deterministic and observable. Unknown policy keys fail clearly rather than silently using a default, and configuration changes are validated before serving traffic. If policies are composed, I define ordering, whether adjustments accumulate, and which rule can stop evaluation. Contract tests protect rounding, currency, and invariants across every strategy. I would also keep a removal path because obsolete strategies and feature flags otherwise become permanent architecture. The goal is to localize meaningful variation, not to hide a large conditional behind reflection or dependency injection.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Creating an interface for every conditional.
Encoding several interacting dimensions in class names.
Letting strategy order change the result accidentally.
Using a silent default for unknown policy configuration.

Red flagsCandidateSigns the design is fragileSignals that an interviewer may treat as risky.Open details

Details

Adding one rule requires edits across every strategy.
Selection depends on hidden registration order.
Strategies duplicate core money and validation rules.
Runtime configuration can select an unregistered policy.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

When is a switch better than a strategy?
Where should strategy selection live?
How would you test composed pricing rules?

Continue practice

No explicit flow link is set yet, so these are nearby drills from the same path or taxonomy.

A pricing service has a growing switch for customer type, country, and promotion. How would you decide whether to introduce strategies under the open-closed principle?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

A pricing service has a growing switch for customer type, country, and promotion. How would you decide whether to introduce strategies under the open-closed principle?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice