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.
The AI is deliberately fallible — it gives hints, not solutions, and sometimes proposes wrong code. It cannot touch your editor. Paste what you choose, then Run. Anything AI-derived stays UNVERIFIED until your tests go green.
Self-check
- ☐an inventory id with no financial row is MISSING_FINANCIAL (HIGH)
- ☐a financial id with no inventory row is MISSING_INVENTORY (MEDIUM)
- ☐a matched pair with differing amounts is AMOUNT_MISMATCH (HIGH)
- ☐a matched pair with equal amounts but differing status is STATUS_MISMATCH (MEDIUM)
- ☐amount mismatch takes precedence — never double-report the same id as both AMOUNT_MISMATCH and STATUS_MISMATCH
- ☐an id with more than one financial row is DUPLICATE (LOW)
- ☐a clean, fully-agreeing record produces no finding
- ☐countBySeverity rolls the result up by severity, and findings() returns the same set reconcile produced
- ☐you named the index-by-id approach (group both sides into maps) and why a nested scan would be O(n*m)
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
Pair partner (병신 모드 · 버그 잡기)
gpt-4o-miniAsk for a skeleton or a test plan — not the answer. Then implement the core yourself and come back for edge cases. Remember: the partner is fallible. Verify everything by running it.
The partner sees your editor but cannot change it. Copy any suggestion in by hand, then Run to verify.
AI랑 먼저 페어하고 눌러