Problem
Build a PricingEngine that prices a Home as final = base + renovation + riskAdjustment + marketAdjustment. Each component is produced by its own rule and recorded in a breakdown() map keyed by component name; the recorded components must always sum to the returned price. price(Home) returns the final int price. setOverride(int) sets a manual override that wins over the computed total — when an override is active, price() returns the override and the breakdown still sums to it. Model the rules as a list of strategy objects so each one contributes one labeled part.
Restate the problem in one sentence and list the edge cases — before writing any code.
Then keep talking — restate the problem + the edge cases in your own words.
“Let me make sure I understand the problem, then I'll walk through my approach.”
checking microphone…
Self-check
Hints / what this doesn't test
This is an Opendoor-flavored applied problem: a small rule engine that prices a home and stays auditable — every dollar in the final price must trace back to a labeled component. Restate it before coding — "So the price is a sum of named parts, the breakdown has to add up to what I return, and a manual override replaces the total — but I still owe a breakdown that sums to it?"
What this problem does not test (say so out loud): rule ordering/priority,
percentage-based (multiplicative) adjustments, per-rule enable/disable flags,
floating-point money (everything is int cents-or-dollars here), and persistence are
out of scope — but a senior names that the easy-to-miss bug is letting setOverride
break the breakdown-sums-to-price invariant, which is exactly what makes the engine
auditable in the first place.
Tests
- ○sums_components
- ○breakdown_has_each_part
- ○override_wins