What a Splitwise-Style Interview Question Actually Asks For

Most people hear "design Splitwise" and start listing screens. An add-expense form, a group page, a settle-up button.

That is not what the interview is testing.

A machine coding round wants you to turn a fuzzy app into a short, precise list of things the system must do, then build exactly that. No more, no less. Splitwise itself has dozens of features. Your job is to find the handful that actually test object design and skip the rest, on purpose.

The App in One Sentence

Splitwise tracks shared expenses across a group of people and works out who owes who.

James, Denver, and Neal split a dinner bill. James pays the ₹1,500 tab. Denver and Neal each owe James ₹500. Splitwise remembers that, even after everyone forgets the exact bill.

That is the whole product. Everything below is really just: how do you record a debt, and how do you clear it later.

The Four Requirements That Actually Matter

Four features carry almost all of the design difficulty in this problem. If your solution nails these four, you have answered the question the interviewer is actually asking.

1. Add an expense. One person pays, one or more people owe a share of it back.
2. Edit an expense. The amount or the split was wrong, and it needs correcting.
3. Settle an expense. Someone pays back what they owed.
4. Group expenses. Expenses can belong to a group, and a group can settle all its expenses at once.

Settling is not the same as editing, and mixing the two up is the first mistake worth avoiding.

Editing changes the record. Settling adds a new fact on top of it.

If Denver owes James ₹500 and pays it back, the old expense does not disappear or get rewritten. It gets marked settled. The history stays intact, the same way a bank statement never deletes a transaction just because the balance changed later.

Groups Make One Requirement Non-Optional

A single expense between two people is easy to settle: one person just pays the other. Groups make it messy.

Picture a five-day trip where James, Denver, and Neal are logging expenses the whole time. Hotel, food, a cab fare, split three different ways depending on who was actually there. By the end of the trip, you might have ten separate expense records tangled between the same three people.

Settling all ten one by one, in the order they were created, technically works. It is also a terrible experience, because a handful of those payments cancel each other out and never needed to happen at all.

That is where the fourth feature earns its keep: simplifying the debts before anyone pays anything.

Simplify vs. Settle the Long Way

Splitwise actually gives you two ways to clear a group's debts.

The transitive way settles every expense exactly as it was recorded, one payment per expense, even if that means money changes hands more times than it needs to. It is always correct. It is just not efficient.

The simplified way collapses the whole tangle down to the fewest payments that produce the same final balances. Fewer transfers, same outcome, nobody pays more or less than they actually owe.

Here is the chain that makes the idea concrete.

ExpandTwo owes-chains before and after simplification, one collapsing a straight chain and one collapsing a loop

James owes Denver ₹10. Denver owes Neal ₹20. Nobody has paid anyone yet.

Followed literally, that is two payments in disguise: James pays Denver, then Denver pays Neal. But James's ₹10 is going to end up with Neal anyway, just one hop later. So skip the hop. James pays Neal ₹10 directly, and Denver only needs to pay Neal the remaining ₹10. Same money, same final balances, one less transfer sitting in the middle.

Now add a third debt to the same group: Neal owes James ₹10.

Follow the money all the way through and something more interesting happens. James is owed ₹10 by Neal, and owes that exact same ₹10 to Denver. Those two cancel out completely, and James drops out of the picture entirely. Neal's ₹10 to James can just be redirected straight to Denver instead, since Denver was owed that ₹10 by James anyway. That redirected ₹10 partly covers what Denver already owed Neal, so it just shrinks Denver's original ₹20 debt down to ₹10.

What is left is one clean fact: Denver owes Neal ₹10. Three recorded expenses, one real debt.

That second example is the one worth sitting with, because it is not just shortening a chain. A person can fully cancel out of a group's debts and never pay or receive a single rupee, if what they owe and what they're owed happen to match. Simplifying has to catch that case too, not just the straight-line chain.

The Features That Don't Move the Needle

Splitwise has a couple of features that show up in the real app but barely touch the actual design problem.

Comments. If someone disagrees with an expense, an amount, or a split, they can leave a comment on it instead of editing it outright. It is a transparency feature, not a data-modeling one.

Activity log. Every add, edit, and settle action gets recorded somewhere visible to the people involved. This is closer to a notification system: think of it as a list of subscribers who get told whenever something relevant to them changes. It is a real feature, and a genuinely interesting one to build, but it is not what decides whether your class design is any good.

Both are worth mentioning to an interviewer as things you're aware of and deliberately leaving out of scope, rather than pretending Splitwise doesn't have them.

What This Post Didn't Do

There is no class diagram here on purpose. Before any object gets designed, the requirements have to be nailed down first, the same order a real interview follows: scope the problem, then model it.

The next post in this chapter takes these four requirements and turns them into the actual object model, the classes for a user, an expense, a group, and the split logic that decides who owes what. For a refresher on how to open a design interview before any of this, the BookMyShow requirements post covers the same first-principles approach this one builds on. If any of the class-diagram vocabulary used going forward feels unfamiliar, the LLD terms glossary covers it in plain language first.