Rebalance Bank Accounts to a Minimum Balance
Reported by candidates from Stripe's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
Input size won't save you or sink you here, since 500 accounts means even a sloppy quadratic pass runs instantly. That's the Stripe OA from November 2023: rebalance accounts so everyone hits a minimum balance, and print the transfers in a fixed order. The trap isn't speed. It's the deterministic output rules, because one wrong ordering fails every test. The pattern is a greedy two-pointer walk over receivers and donors. If you blank on the bookkeeping live, StealthCoder is the safety net running invisibly on your screen. But the logic is short enough to own.
The problem
Stripe tracks money across bank accounts and sometimes moves funds so that every account stays at or above a required minimum balance. Each input row is accountName,balance. Return a working sequence of transfers in the form from,to,amount that leaves every account with at least threshold. An optimal number of transfers is not required. For deterministic output, process underfunded accounts in input order and take funds from overfunded accounts in input order. Move as much as possible in each transfer without taking a donor below the threshold or raising the current receiver above it. Function rebalanceAccounts(accounts: String[], threshold: long) → String[] Examples Example 1 accounts = ["AU,80","US,140","MX,110","SG,120","FR,70"] threshold = 100 return = ["US,AU,20","US,FR,20","MX,FR,10"] US first fills AU, then contributes its remaining surplus to FR. MX supplies FR's final ten. Example 2 accounts = ["a,50","b,50","c,200"] threshold = 100 return = ["c,a,50","c,b,50"] The only donor funds both receivers in their input order. Constraints 1 <= accounts.length <= 500. Account names are unique and contain no commas. 0 <= balance, threshold <= 10^12. The total balance is at least accounts.length * threshold. All arithmetic fits in signed 64-bit integers.
Reported by candidates. Source: FastPrep
Pattern and pitfall
Split the input into two lists in input order: underfunded accounts (balance below threshold) and overfunded ones (balance above it). Keep a pointer on each. For the current receiver, compute need = threshold - balance. For the current donor, compute surplus = balance - threshold. Transfer min(need, surplus), record from,to,amount, then update both. Advance whichever pointer hits zero, or both if they tie. Because the total balance is at least n * threshold, donors never run out before receivers are filled. Common pitfalls: using int instead of long when balances reach 10^12, emitting zero-amount transfers, and re-sorting the accounts, which breaks the required order. Skip accounts exactly at threshold. If the live OA has you fumbling pointer advancement, StealthCoder can hand you a clean version as a hedge, but trace Example 1 by hand first.
StealthCoder is the hedge for the one pattern you didn't drill. It runs invisibly during the screen share.
You can drill Rebalance Bank Accounts to a Minimum Balance cold, or you can hedge it. StealthCoder runs invisibly during screen share and surfaces a working solution in under 2 seconds. The proctor sees the IDE. They don't see what's behind it. If you're reading this with an OA window open, you're who this was built for.
Get StealthCoderRelated leaked OAs
You've seen the question.
Make sure you actually pass Stripe's OA.
Stripe reuses patterns across OAs. If you're reading this with an OA window open, you're who this was built for. Works on HackerRank, CodeSignal, CoderPad, and Karat.
Rebalance Bank Accounts to a Minimum Balance FAQ
What's the trick in the Stripe rebalance accounts problem?+
It's a greedy two-pointer merge. Keep underfunded accounts and overfunded accounts in separate lists, both in input order. Each step, transfer min(need, surplus), then advance whichever side is satisfied. No sorting, no optimization of transfer count. The statement explicitly says optimal isn't required.
How hard is this one really?+
Easy to medium. The algorithm is a simple greedy loop. The difficulty is following the deterministic rules exactly and handling 64-bit values. Most failed attempts come from wrong ordering or overflow, not from a wrong idea.
Do I need to worry about performance with 500 accounts?+
No. The two-pointer pass is linear, and even a quadratic approach would be fine at 500 accounts. Spend your effort on correctness of ordering and on using long types, since balances go up to 10^12.
What edge cases should I test before submitting?+
Test accounts already exactly at threshold, which should produce no transfers. Test everyone already above threshold, which should return an empty list. Test one donor funding many receivers, like Example 2. Test a receiver needing several donors, like FR in Example 1. Also check threshold 0.
How do I prepare for this in 48 hours?+
Write this solution from scratch twice, then trace Example 1 by hand to confirm your output matches exactly. Then practice the general pattern of splitting data into two ordered lists and merging them with two pointers. That covers most of what this question tests.