How the interviewer opens it
“Design a personal finance app that combines transactions from a user's bank accounts. Users review spending categories and track budgets as their bank data changes.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Users and read volume
- Transaction volume and read:write mix
- Bank import contract
- Duplicate transactions
- Spending and budget rules
- Category behavior
- Latency and freshness
- Consistency and availability
- Retention and durability
- Security and exclusions
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Import transactions from connected bank accounts
- Assign spending categories and let users change them
- Track monthly spending against category budgets
- Keep totals correct after corrections, duplicate decisions, and category changes
Usually out of scope
- Move money or pay bills
- Build bank connectors
- Track investments or calculate taxes
- Convert currencies
- Merge transactions across accounts or bank data providers
What interviewers ask about
- Transaction identity and import progress
- Banks repeat records and change transaction IDs. A failed import can repeat old changes or leave the service unsure about its progress.
- Duplicate decisions and user choices
- Two existing records can hold different user choices. Concurrent duplicate decisions must leave one counted transaction without losing choices or history.
- Spending totals after transaction changes
- A correction can move spending between months or categories. Totals must match canonical transactions during edits, repairs, and failures.
- Category choices during other changes
- Bank updates, automatic category results, and user choices arrive independently. A late result must not replace a user choice or classify old source data.
Common mistakes
- The service treats each import response as a new transaction.
- The service merges transactions solely because their amount, date, and merchant match.
- The service calculates money with floating-point values.
- The design changes totals without accounting for each transaction's previous contribution.
- A duplicate merge discards user choices or leaves no counted copy.
- Bank updates or late automatic results replace a user's category choice.
The bar by level
- Senior (L5/E5)
- Defines source identity, import progress, and category precedence. Keeps canonical changes, totals, and history atomic. Handles retries, stale edits, duplicate merges, and total repair. Specifies durable commit rules.
- Staff (L6+/E6+)
- Defines invariants across overlapping merges, expired import workers, and repairs. Preserves user choices through multi-record merges. Explains safe failover after an availability-zone loss. Plans retention, user-based shards, and safe history changes.