Original practice scenario inspired by Mitsubishi UFJ Financial Group, Inc.'s public business context; this is not a reported interview question or a description of its internal systems. A fictional financial group has signed ledger entries in several currencies and a daily exchange-rate table. Explain how to report native-currency balances and a separately labeled converted total without multiplying entries or silently using missing rates.
Read model answer +
Preserve currency as part of the balance grain. Native amounts in different currencies cannot be added meaningfully, and conversion requires a specific rate date, direction, and rounding convention.
Work through it
Aggregate ledger entries by account and currency first. Validate that rate data has one row per required currency pair and valuation date.
Join the aggregate to that unique rate set and expose missing rates as an exception or incomplete valuation, rather than substituting zero.
Compute the converted measure with fixed-decimal or integer minor-unit handling, applying the documented rounding stage. Reconcile native totals before checking the converted report.
Tradeoffs to discuss
Converting each transaction and converting a final balance can differ because of valuation timing and rounding. The report must state which interpretation it implements.
Common pitfalls
Duplicate rate rows multiply balances.
A bare SUM(amount) across currencies produces a number without a coherent unit.
Original practice scenario inspired by Mitsubishi UFJ Financial Group, Inc.'s public business context; this is not a reported interview question or a description of its internal systems. A synthetic banking workflow processes submissions in several countries. Local holidays and daylight-saving changes affect business-day cutoffs. Design a scheduler and audit record that remains reproducible when calendars are updated.
Read model answer +
Treat a business calendar as versioned data rather than embedding fixed UTC offsets in code. Every processing decision should identify the timezone, calendar version, and cutoff rule that produced it.
Work through it
Represent submission instants in UTC and derive local business dates using a timezone database. Define ambiguous local-time handling explicitly.
Resolve the next eligible processing window against the selected holiday calendar. Persist that decision and an idempotent job key before dispatching work.
Test daylight-saving transitions, an exceptional holiday, a calendar correction, and delayed delivery across midnight. Decide whether pending work is recomputed after a calendar revision.
Tradeoffs to discuss
Precomputed windows simplify scheduling, while dynamic rules adapt more readily to calendar updates. Either approach needs versioned decisions and reconciliation.
Common pitfalls
Adding twenty-four hours does not always mean the next local business day.
Replaying with today's calendar can change historical processing decisions.
