Design expense splitting
Splitwise, essentially. The interesting part is settling debts, not recording them.
standard · 60 minutes · 8 classes
Requirements
- Users belong to groups; expenses are recorded against a group.
- An expense has a payer, an amount, and a split — equal, exact amounts, or percentages.
- Maintain who owes whom, netted rather than stored transaction by transaction.
- Show one user's balance overall and per group.
- Simplify debts so the group settles in as few transfers as possible.
Say these are out of scope
- Actually moving money.
- Multi-currency conversion — assume one currency.
- Notifications and activity feeds.
A shape that works
One reasonable decomposition, not the only one. What matters in the round is that you can defend the boundaries you drew.
What they'll push on
£10 split equally three ways.
333, 333, 334 in minor units — never 3.33 each, which loses a penny, and never floating point, which loses it non-deterministically. Work in integer minor units and assign the remainder by a stated rule, usually to the payer. Interviewers ask this exact question because it separates people who've handled money from people who haven't.
Store every pairwise debt, or net them?
Net them. Storing raw transactions means the balance between two people is a scan over history; netting keeps a single number per pair and makes 'who owes whom' O(1). Keep the expenses too — you need them for an audit trail — but don't derive balances from them on every read.
Minimising the number of settlement transfers.
Compute each person's net position, then repeatedly match the largest creditor against the largest debtor. It's greedy and it isn't provably minimal — the exact problem is NP-hard — so say that. Claiming optimality here is a bigger mistake than the extra transfer.