Money-Safe Financial Computation

What's being tested

These problems test money-safe stateful computation: applying ordered events, pricing rules, validation, and aggregation without floating-point surprises. Interviewers look for clean data modeling, deterministic edge-case handling, and fixed-point arithmetic that preserves cents, currencies, and balances.

Patterns & templates

• Fixed-point integer arithmetic — store money in minor units like cents; compute fee = amount * bps // 10000 with explicit rounding policy.

• Composite-key maps — use (account_id, currency), (country, payment_method), or (item_type, tier) as dictionary keys; expect O(1) lookup.

• Sort-then-apply event processing — sort by timestamp plus stable tie-breaker; update balances sequentially in O(n log n) time.

• Configuration-driven calculators — encode tiers, discounts, tax, and fee rules as data; keep calculation logic generic and testable.

• Boundary-safe tier loops — calculate units_in_tier = min(remaining, tier_limit - prev_limit); watch inclusive vs exclusive thresholds.

• Validation-first pipelines — reject missing currency, negative quantity, unknown rate, malformed account, or unsupported tier before mutating state.

• Deterministic output ordering — sort results by account, currency, item name, or timestamp as specified; never rely on dictionary iteration.

Common pitfalls

Pitfall: Using float for prices, tax, or fees; binary rounding errors can produce incorrect cents and flaky tests.

Pitfall: Aggregating before validation; invalid transactions must not partially update balances, totals, or platform overdraft coverage.

Pitfall: Treating all currencies as interchangeable; balances, fees, and totals usually aggregate per currency unless conversion rates are explicitly provided.

Practice these

The practice cards below cover the canonical variants — solve all of them and time yourself.