Banking System with Accepted Transfers, Part 1: Accounts and Payments
Reported by candidates from Ramp's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
The Ramp OA reported in November 2023 looks like a warm-up: a banking system with CREATE_ACCOUNT, DEPOSIT and PAY. It's Part 1 of a four-part cumulative series, so sloppy design here costs you in Parts 2 through 4. The pattern is design with a hash map, and the trap is the empty-string return rules. If you've got an invite, expect this shape. And if you blank on the live assessment, StealthCoder can run invisibly as a safety net and hand you the clean version.
The problem
Implement a simplified banking system. The assessment is cumulative: after unlocking a new level, every operation from the current and previous levels remains available. Query and Output Rules Each query calls exactly one operation and includes a stringified millisecond timestamp. Timestamps are unique, lie between 1 and 10^9, and appear in strictly increasing order. Return one string result for every query, in input order. Return the empty string when an operation has no successful scalar result, exactly as specified below. Multipart Series Part 1: Accounts and Payments Part 2: Activity Ranking Part 3: Pending Transfer Acceptance Part 4: Account Merging and Balance History Level 1: Accounts and Payments The banking system should support creating new accounts, depositing money, and withdrawing or paying money from accounts. CREATE_ACCOUNT <timestamp> <accountId> creates a new account with the given accountId if it does not already exist. Return "true" if the account is created and "false" if it already exists. DEPOSIT <timestamp> <accountId> <amount> deposits amount into the account. Return the account balance after processing the query, or the empty string if the account does not exist. PAY <timestamp> <accountId> <amount> withdraws amount from the account. Return the account balance after processing the query. Return the empty string if the account does not exist or has insufficient funds. Function bankingAcceptedTransfersLevel1(queries: String[][]) → String[] Examples Example 1 queries = [["CREATE_ACCOUNT","1","account1"],["CREATE_ACCOUNT","2","account1"],["CREATE_ACCOUNT","3","account2"],["DEPOSIT","4","non-existing","2700"],["DEPOSIT","5","account1","2700"],["PAY","6","non-existing","2700"],["PAY","7","account1","2701"],["PAY","8","account1","200"]] return = ["true","false","true","","2700","","","2500"] The duplicate account creation fails. Missing-account operations and an overdraw return empty strings. The final payment succeeds and leaves account1 with 2500. Constraints 1 <= queries.length <= 500. Every timestamp is a unique integer from 1 through 10^9, and queries are supplied in strictly increasing timestamp order. Every query row is well formed and uses an operation available at this part. Amounts and n are positive base-10 integers. Every balance and transaction total fits in a signed 64-bit integer. Account identifiers are non-empty strings that do not contain commas or parentheses.
Reported by candidates. Source: FastPrep
Pattern and pitfall
The core is a hash map from accountId to balance. CREATE_ACCOUNT checks membership and returns "true" or "false". DEPOSIT adds and returns the new balance as a string, or "" if the account is missing. PAY is where naive solutions break: you must check that the account exists AND that the balance is at least the amount before subtracting. Example 1 shows it, since paying 2701 against 2700 returns "" and leaves the balance untouched. Don't mutate before validating. Return strings, not ints, and use 64-bit-safe types. The bigger pitfall is structure. Parts 2 to 4 add activity ranking, pending transfers and merging, so keep each operation in its own method and store accounts as objects, not bare ints. Timestamps are strictly increasing, so you never need to sort. If you freeze on the live OA, StealthCoder is the hedge that gives you the working skeleton.
Memorize the pattern. If you can't, run StealthCoder. The proctor sees the IDE. They don't see what's behind it.
You can drill Banking System with Accepted Transfers, Part 1: Accounts and Payments 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. Made by an engineer who treats the OA as theater. If yours is tonight, you don't have time to grind. You have time to hedge.
Get StealthCoderRelated leaked OAs
You've seen the question.
Make sure you actually pass Ramp's OA.
Ramp reuses patterns across OAs. Made by an engineer who treats the OA as theater. If yours is tonight, you don't have time to grind. You have time to hedge. Works on HackerRank, CodeSignal, CoderPad, and Karat.
Banking System with Accepted Transfers, Part 1: Accounts and Payments FAQ
How hard is the Ramp banking system OA really?+
Part 1 is easy. It's a hash map with three operations and string outputs. The difficulty comes later, because the assessment is cumulative and your Part 1 structure has to survive ranking, transfers and merging. Write it cleanly now.
What's the trick in Part 1?+
Validate before you mutate. PAY must fail with an empty string when the account is missing or funds are short, and the balance must stay unchanged. Also return every result as a string, including balances.
What does the output look like for failed operations?+
An empty string, in the same position as the query. Duplicate account creation is different: it returns "false", not empty. Mixing those two up is the most common wrong answer on the sample.
Is this design pattern still asked?+
Ramp reported it in November 2023, and multipart cumulative design questions like this keep showing up. Expect a simulation of a system with a query list, not a classic algorithm puzzle.
How do I prepare in 48 hours?+
Write this exact Part 1 from scratch using a map of accounts, then add a small class per account so extending it is easy. Practice parsing string arrays and returning string results. Don't grind unrelated problems.