Banking System Coding Questions by Company and Level (2026)

As of 2026-10-19, TrueInterview's bank holds 46 questions matched as bank and ledger simulations at 20 big-tech companies, a few of them keyword matches, led by Stripe with 11 and Coinbase with 6. Candidates reported them in onsites 22 times, phone screens 18 times and OAs 9 times. Our view: every version shares a core of accounts, deposits, transfers and balances, and the company versions separate in the later levels. Build level one as timestamped events with a stable account identity, not a bare balance map, and rankings, deferred cashback, merges and historical balances become additions instead of rewrites.

Disclosure: TrueInterview is an interview-preparation product and publishes this article. Facts about other products come from their public pages on the dates listed under Sources.

Which companies report a banking or ledger simulation, and in which round?

Stripe, Coinbase, Lyft, Anthropic and Pinterest file the most, and the format follows the round. Of the 46 questions, 29 are coding (algorithm) versions and 17 use other formats, 15 of them object-oriented design. Onsites lean to the object version: 13 of the 15 other-format questions reported for the onsite are object-oriented design. If your schedule says phone screen, drill hash-map coding first; if it says onsite at Anthropic, drill the leveled class first.

Our take: the round predicts the version better than the company name does. Of the 18 questions reported for the phone screen, 15 are coding versions, and their tags spread across hashing, arrays and greedy, each on 3 of the 15. A phone screen therefore usually calls for fluent coding rather than a class hierarchy, with Snowflake's transactional store in the table as the exception. An onsite at Anthropic calls for the object-oriented, leveled version, practised to its final level. Coinbase's reports include both the merging class and an algorithm-style onsite question, so prepare both, and Robinhood's onsite example is an object-oriented design question. The family is also current: 41 of these questions were last reported within the 12 months before 2026-10-19, so these reports describe recent loops rather than old ones.

What do the public versions share, and where do they split?

The three public statements compared here, on PracHub, FastPrep and Hello Interview's page, all start from accounts, deposits and transfers, and they split on the failure result, the ranking rule and how far the later levels go. The table describes those sources' versions only, not TrueInterview's filed questions, whose prompts sit on their practice pages.

LeetCode 2043 is the core and nothing more, so treat it as a warm-up. The Capital One version adds one ranking and stops there. The Anthropic version is the one to prepare to its last level, because its later operations are where a weak data model breaks.

Our take: the later levels, not the banking domain, separate the company versions. A candidate who has only practised the LeetCode class has rehearsed the part every version shares and none of the part that differs. Before your loop, list the operations named in your company's reports, such as merges or cashback, and practise through the last one on that list.

How should you build level one so later levels need no rewrite?

Keep three structures from the first minute, even though level one uses none of them: an outgoing total on each account, a queue of pending timed events ordered by due time, and a map from any account id to its current canonical account. PracHub's simulation says earlier operations must keep working unchanged as levels are added, so every new level should be new operations on the same model.

• Outgoing totals. Store the total on the account record at creation and update it inside the same guarded write as the balance. The spender ranking then becomes one sort keyed on descending total and ascending id over all accounts, which covers the zero-outgoing rule without a special case.
• Pending events. PracHub's statement says "every operation should first apply all pending cashbacks" whose credit time has arrived. Keep a min-heap keyed on (due time, insertion order) and drain it at the top of every public method, before validation. Draining in one place gives you the deterministic event ordering that PracHub's ledger page lists among the challenge's centers.
• Canonical identity. Resolve every incoming id through the alias map before anything else, so earlier operations keep working unchanged after a merge. The merge operation itself still has to move the balance, outgoing total, pending events and history to the surviving account, and resolve aliases transitively, for example with union-find, so an id that pointed at the absorbed account now reaches the survivor.
• Append-only history. Record each balance change as a (timestamp, balance) pair per account. A historical-balance query becomes a binary search over that list, while a bare balance map would force a rewrite to recover the past.

What each level adds, in our reading

None of the public statements quoted here gives exact level boundaries; PracHub says only that the system is leveled and that each level adds operations. The order below is our reading of PracHub's operation list, with the shared core as the first stage; treat the split as our assumption, paired with the structure each stage needs.

Worked example: the merging title from the bank

Take Banking System with Payments and Account Merging, filed under Anthropic, Coinbase and Instacart and linked from 8 write-ups, 4 of them by senior-or-above candidates. The closest public statement is PracHub's Anthropic simulation, which PracHub says tests "handling of deferred effects like scheduled cashback credits." Under the model above, payments enter the heap with their cashback due time, the merge moves balances, totals, pending events and history to the survivor and repoints its aliases, and neither change touches the create, deposit or transfer code. Our take: say the three structures aloud in the first minutes and explain which later operation each one serves; it shows the interviewer a plan for requirements that have not been read out yet.

Where do candidates lose points on these simulations?

Mostly on the contract rather than the algorithm. The public statements warn about the wrong result for a missing account, duplicate creates, partial transfers and failed operations that still count toward a ranking. Each of these fails a hidden test while the main logic looks correct, so before calling a level done, call each operation once with a missing id and once with an amount above the balance.

• Sentinels differ by version. PracHub's hint says "DEPOSIT and GET_BALANCE on a missing account both return the empty string" rather than zero. FastPrep's Capital One version returns -1 for a deposit to a missing account instead. Write the result convention for each operation at the top of your file before coding, because, going by FastPrep's statement, an empty string where the tests expect -1 fails every invalid-input case.
• Duplicate creates. PracHub's hint says CREATE_ACCOUNT "must not overwrite an existing account" and should check membership first. An overwrite silently resets a balance, which no later level can repair.
• Partial transfers. Hello Interview's page lists "Deducting from source before validating destination" as a pitfall, and says a transfer is atomic, with both balances updated or neither.
• Failed operations in rankings. FastPrep's statement says failed transactions add nothing to an account's activity. Update the activity or outgoing total in the same step as the balance change, after every check has passed.
• Index and sign errors. Hello Interview's page lists off-by-one indexing on the 1-indexed class and negative balances slipping past the funds check.

Our take: write one guard and reuse it in every mutating method: resolve ids, settle due events, validate all conditions, then mutate balances, totals and history together, then return the version's result. The order is the part interviewers can see, and it is the same in deposit, transfer and pay.

Why do Stripe's reports look different from the account class?

Stripe has the most questions in this family, and the two Stripe titles with link counts in our data name verification and logs rather than accounts and levels. Business Account Data Verification is an OA coding question last reported in 2026-10, and it and Transaction Logs — Trigger / Resolve are each linked from 5 write-ups. Our guess from the titles, since no claim here describes their prompts: practise replaying a list of entries into per-account balances and listing the entries that fail to match.

Elsewhere in TrueInterview's catalog, Stripe also lists Payment Invoice Reconciliation and Processing Invoices and Payments as algorithm coding questions, and the home page lists Payment State Machine as an OA design question; these may sit outside the 46 counted here. TrueInterview's problem list tags the reconciliation title with payment, simulation, string and api-integration. For the ledger reasoning behind these titles, payment-engineering guidance is useful background, though not an interview requirement:

• Dodo Payments' guide describes a payment ledger as "an immutable, double-entry record rather than a mutable status field."
• The same guide says any balance at any point in time can be derived by replaying entries, and a wrong entry is corrected by posting a reversing entry and then the correct one.
• Stripe's API documentation says its idempotency support lets requests be retried safely without performing the same operation twice. The Dodo Payments guide treats a posting whose idempotency key was already seen as a no-op.

Our take: for a Stripe loop, we would prepare idempotency and ledger replay as likely follow-ups. The Stripe titles point at records and logs, though the reports here do not name these topics. Practise turning a log into balances by replay, matching two record sets and reporting the mismatches, and be ready to say why a derived balance is safer than an edited balance field: the history that explains the number survives.

Is a transactional key-value store the same skill under another name?

Close enough to practise together. Design Key-Value Store with Transactions is linked from 6 write-ups at Snowflake and Lyft, and Transactional Key-Value Store from 6 at Lyft. Both are object-oriented design questions, reported in a Snowflake phone screen in 2026-07 and a Lyft onsite in 2026-06. If either company is on your list, solve both titles in the same week as the merging banking title.

The shared skill is staged state. The technique to have ready for any transactional store is a stack of change layers: a write goes into the top layer, a read checks layers from the top down, rollback discards the top layer and commit merges it into the one below. A banking transfer is the one-layer case of the same idea, since you stage the change, validate it and then apply all of it or none. The nested form raises the bar: In-Memory Key-Value Store with Nested Transactions and Value Counts is linked from 2 write-ups, both by senior-or-above candidates.

Our take: at senior level, the interviewer is likely to push on what a commit costs when layers are deep, and on how a count of values stays correct across a rollback. Keep a per-layer delta for counts as well as for values, and say so before you code.

What changes at senior and staff level?

Both senior and junior candidates report these questions in similar numbers. Write-ups link the family 51 times from candidates who reported a senior, staff-plus or manager level and 51 times from junior, new-grad or intern candidates. Levels are self-reported on the write-ups, so read the split as who wrote reports rather than as a hiring rule.

That total includes the keyword matches left out of the tables: Pick Dasher / Round Robin Load Balancer alone carries 7 senior-or-above links and 1 junior link, so the even total overstates the senior share of the bank and ledger titles. Hello Interview's question page also shows Capital One senior-level reports in early August and early September 2026. The largest row in the table totals 8 links, so read these rows as proof that senior candidates meet the merging, store and log titles, not as a trend.

Our take: what changes with level is how your answer is read. A junior candidate who finishes the levels has done well; a senior candidate is expected to have chosen a data model that absorbed each new level, and to explain trade-offs such as deriving balances from immutable entries versus mutating a balance field. Ask the questions a senior engineer would ask before coding: whether timestamps are strictly ordered, what a merge does to pending cashback and outgoing totals, and whether a failed payment keeps a status record.

Down-leveling note (our view): a simulation round rarely sets your level alone, but it can lower it. The signal sits in the first minutes and the last level. A candidate who rewrites level one to fit a merge reads as mid-level even with a working final answer, while one who adds the merge as a new operation on an existing alias map reads as senior.

How we counted

Counts come from TrueInterview's question bank as of 2026-10-19. TrueInterview says questions are "Written up right after the interview and checked against other reports of the same round." These are candidate-reported questions reconstructed for practice, not any company's official question list, so a count shows what candidates wrote up rather than how often a company asks. Three titles that match by keyword but are not bank simulations stay in the totals and out of the tables: Pick Dasher / Round Robin Load Balancer, Compute Stock Profit with One or Unlimited Transactions, and DFS: Print Each Node's Level and Whether It Is Balanced.

FAQ

Is the banking system simulation the same as LeetCode 2043 Simple Bank System?

Only at its core. Hello Interview's page describes LeetCode 2043 as a class over 1-indexed balances with transfer, deposit and withdraw. That matches the first level of the leveled versions and stops there. The versions reported for onsites add a ranking, and the Anthropic version adds deferred cashback, merges and history on top, as the comparison table shows. Use LeetCode 2043 for a quick warm-up on validation, then move to a leveled version if your company's reports mention rankings, payments or merges.

Is the banking system question asked in the OA, the phone screen or the onsite?

All three, with onsites reporting it most, as the counts at the top show. Most phone-screen questions are coding versions: 15 of the 18 reported for the phone screen are coding questions, and Snowflake's transactional store is the named exception. The company table gives examples by title: Stripe's verification title is an OA question, Pinterest's balancing title a phone-screen question, and the Anthropic merging title an onsite question. For the onsite, expect the object-oriented version more often, and plan to finish its last level.

How are ties broken in top activity or top spenders?

FastPrep's Capital One version breaks activity ties by account id in ascending alphabetical order. PracHub's version ranks by outgoing amount and includes accounts that have sent nothing, as covered above. Implement the ranking as one sort over all accounts with a composite key, descending total then ascending id, and never rely on dictionary insertion order. If the prompt does not state a tie rule, ask whether ties go to the lower account id before you write the sort.

What happens to payments and history when two accounts are merged?

The public statements here do not spell out every merge rule, so confirm them with the interviewer. In our view, the safe model keeps payment records keyed by payment id with an owner id resolved through the alias map at query time, so a status lookup still works after the merge. Ask whether the surviving account inherits pending cashback and outgoing totals, and whether the absorbed account's history moves with it or stays readable under its old id.

Do senior candidates get this question, or only new grads?

Both, in similar numbers, as the senior section shows. What differs is what the interviewer expects you to explain about the data model. In our view, senior candidates should finish the levels with an unchanged level-one design, to name the trade-offs behind it, and to raise the ordering, merge and failure questions before the interviewer does. If you are interviewing at senior or staff level, rehearse a two-minute explanation of your alias map and event queue rather than adding more problem variety.

Your practice plan

A three-week plan for someone working full time, at about an hour on most weekdays. The target is narrow: one core model, then only the extra levels and neighbours your company's reports show.

1. Week one, first sessions. Write a level-one skeleton with an outgoing-totals field, a pending-events heap and an id-to-account map, then solve Banking System with Payments and Account Merging through its final level without editing your level-one methods.
2. Week one, later sessions. Solve Bank System with Transfer/Accept and Merge, with the result convention for each operation written at the top of the file before you start.
3. Week two, for Stripe. Solve Business Account Data Verification and Transaction Logs — Trigger / Resolve, then explain aloud why a balance is derived from entries and corrected with a reversing entry.
4. Week two, for Robinhood, Pinterest and Coinbase. Solve Friends Money Transfer Request Processor, Account Balancing and Maximize block fee with transaction selection, the last as a timed coding drill.
5. Week three, for Lyft and Snowflake. Solve Design Key-Value Store with Transactions, then Transactional Key-Value Store, then In-Memory Key-Value Store with Nested Transactions and Value Counts, keeping a delta per layer.
6. Week three, last sessions. Redo the two questions where you rewrote the most code, under a timer set to your round's length. TrueInterview says its coding questions are judged on hidden tests that show the failed case, so read each failed case against your guard order and result convention before changing any logic.

Sources

• TrueInterview question bank — bank and ledger simulation at big-tech companies — counted 2026-10-19
• Build a Progressive Banking Ledger | Anthropic — checked 2026-10-19
• Leetcode 2043. Simple Bank System | Hello Interview — checked 2026-10-19
• Banking System with Top Activity (Capital One Onsite Interview) - Coding Interview Problem | FastPrep — checked 2026-10-19
• Banking System Simulation | Anthropic Coding Question — checked 2026-10-19
• Coding Interview Questions by Company · TrueInterview — checked 2026-10-19
• Real FAANG Interview Questions by Company · TrueInterview — checked 2026-10-19
• Payment Ledger Design for Billing Systems | Dodo Payments — checked 2026-10-19
• Idempotent requests | Stripe API Reference — checked 2026-10-19
• Interview prep compared: your application, end to end · TrueInterview — checked 2026-10-19

Last reviewed: 2026-10-19.