Why this matters: Splitwise looks like a CRUD app and is actually a money problem wearing one as a disguise. The candidates who lose this round lose it in the first ten minutes — they never ask how money is represented, never ask what happens when a split doesn't divide evenly, and then spend the implementation act discovering both. The requirements conversation here isn't warm-up; it's where the traps are laid or defused.

The prompt, as given

Here is the whole thing:

Design the core of an expense-splitting app.

People share expenses — a dinner, rent, a trip — and the app keeps track of who owes whom. Someone pays, the cost is split across the group, and everyone can see where they stand. Eventually, people settle up.

No split rules, no group semantics, no word on what a balance actually is, and — most tellingly — nothing about money itself. Every one of those silences is a question the interviewer is waiting for.

The questions, and why each one matters

"How can an expense be split?" Equal shares is the obvious case, but real apps support exact amounts ("I had the steak, I'll pay 600") and percentages ("I earn more, put me down for 60%"). Whether there's one split rule or three decides whether splitting is a formula or an abstraction — a family of rules, each with its own idea of a valid input. Ask this first; it shapes the center of the model.

"What makes a split invalid, and what happens then?" If exact amounts don't sum to the total, or percentages don't reach 100, something must give. The answer you want pinned: does a bad split reject the whole expense, or partially apply? (Any sane interviewer says reject — but you asking is what shows you know partial application would corrupt balances.)

"How do amounts arrive, and how should I represent money?" Amounts come in as decimals — 100.50 — and the representation is usually left as your call, with a raised eyebrow. This is the most important question in the round, because the wrong answer (floating point) plants a bug in every calculation that follows. Lesson 02 makes the case properly; here it's enough to know that asking about money representation is itself a scored signal.

"When a split doesn't divide evenly, where does the leftover go?" Split ₹100.00 three ways and someone gets an extra paisa. It sounds like trivia; it's actually an invariant — the shares must still sum to exactly the total, every time, deterministically. Interviewers care because sloppy rounding is how real ledgers drift.

"Are there groups, or just people?" Both, typically: named groups (the flat, the Goa trip) and ad-hoc expenses between any two users. The design-shaping follow-up is what a group is — and the useful answer is that a group is a scope for viewing expenses, not a wallet that holds money.

"Does settling up move real money?" No — "A paid B ₹200" is a recorded fact, not a payment integration. That one answer removes an entire class of scope (payments, failures, refunds) and tells you settlement is a ledger entry, which turns out to matter structurally.

"Can expenses be edited or deleted?" Commonly deferred — but a strong interviewer will say something like "out of scope, but design as if edits will come." That sentence is a gift: it tells you to keep a seam ready, and lesson 04 shows what that pressure does to the design.

The requirement set this chapter builds against

Splits        equal, exact amounts, percentages — all three
Validation    exact amounts must sum to the total; percentages
              must sum to 100; an invalid split rejects the
              whole expense, atomically
Money         decimal strings in (e.g. "100.50"), single
              currency (INR); representation is yours to defend
Rounding      an equal 3-way split of 100.00 must still sum to
              exactly 100.00 — deterministically
Groups        named groups AND ad-hoc expenses; a group is a
              scope, not a wallet
Settlement    "A paid B 200" is a recorded entry; no money moves
Out of scope  payment processing, auth, notifications,
              persistence, expense editing (but leave a seam)

As with every chapter in this course: a live interviewer's answers may differ. Maybe their app supports shares-by-weight, or multi-currency from day one, or itemized receipts. The skill is the conversation — asking the questions whose answers change the code, in an order that shows you know why. A different answer sheet produces a different design by the same method.