Problem
Reconcile two sets of records keyed by id: inventory records (id, status, amount) and financial records (id, status, amount). Walk both sides and emit a Finding for every discrepancy. An id in inventory with no financial counterpart is MISSING_FINANCIAL (HIGH). A matched pair whose amounts differ is AMOUNT_MISMATCH (HIGH). A matched pair whose amounts agree but statuses differ is STATUS_MISMATCH (MEDIUM). An id in financials with no inventory counterpart is MISSING_INVENTORY (MEDIUM). An id appearing more than once on the financial side is DUPLICATE (LOW). Amount mismatch dominates status mismatch — a pair that differs on both is reported only as AMOUNT_MISMATCH. Implement class Reconciler with reconcile(inventory, financials) returning the list of findings, findings() returning the last result, and countBySeverity() returning a map of severity -> count over that result.
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 and a near-mirror of a real staging-table reconciler: two systems of record (an inventory/operations view and a financial ledger) that should agree key-for-key but drift. Your job is the classification layer. Restate it first — "So for every id I compare the inventory row to the financial row, and the shape of the disagreement — missing on one side, amount off, status off, or duplicated — decides the finding type and its severity?"
What this problem does not test (say so out loud): fuzzy/near-amount tolerance bands, multi-key joins (id + period), three-way reconciliation against a source feed, and streaming/incremental reconciliation are out of scope here — but a senior names that the naive nested-loop compare is O(n*m) and that indexing both sides by id makes it linear, and that the precedence rule (amount over status) is a deliberate policy choice, not an accident of iteration order.
Tests
- ○missing_financial
- ○amount_mismatch
- ○status_mismatch
- ○missing_inventory
- ○duplicate
- ○sev_high
- ○sev_medium
- ○sev_low
- + 3 hidden tests — revealed once the visible ones pass