Build a Simplified Venmo-Style Peer-to-Peer Payments App with AI Tools

In a coding round where any AI coding assistant was allowed, the task was, roughly, to build a simplified Venmo: a peer-to-peer payments app in which users hold a balance and send money to one another. The report gives no more detail than that, so agree on the scope before generating any code. Unless the interviewer says otherwise, assume this core: - create a user; - add funds to a user's balance (a simulated deposit from a bank account or card); - send a payment from one user to another, with an optional note, and reject a payment that would overdraw the sender; - show a user's balance and transaction history, newest first. ```text create_user("alice"); create_user("bob") deposit("alice", "50.00") pay("alice", "bob", "20.00", note="dinner") -> ok pay("bob", "alice", "30.00") -> rejected: insufficient funds balance("alice") -> 30.00 balance("bob") -> 20.00 history("bob") -> [received 20.00 from alice, note "dinner"] ``` ### Clarifying Questions - What should be delivered: a library with tests, a REST API, a user interface, or several of these? Is any language or framework acceptable? - Must data survive a restart, or is in-memory storage acceptable for the round? - Can a balance go negative, and is there a limit on a single payment? - Can a user pay someone who has no account yet, or only existing users? Is there a friends list? - Is the history private, or should there be a social feed of friends' payments with visibility settings? - Is there only one currency? ### Part 1 — Users, balances and payments Implement the core: users, deposits, payments with an overdraft check, balances, and each user's history, with tests. ```hint Money is not a float Pick a representation in which 0.10 + 0.20 is exactly 0.30, and decide which amounts are invalid before any balance changes. ``` #### What This Part Should Cover - An exact money representation, with validation of amounts and users - A payment that updates both balances and the history together or not at all - Tests for the overdraft rule, invalid input and the history order ### Part 2 — A payments service that is safe under retries and concurrency Expose the core as a small service, for example REST endpoints over a database, and make it safe when two payments from the same user arrive at the same moment and when a client retries a payment after a timeout. ```hint Two requests, one balance Picture two payments from the same sender racing through your code at once, and a client resending a request whose response it never received. Find the line where each case goes wrong, then decide what the storage layer must guarantee. ``` #### What This Part Should Cover - The endpoints, and where the sender's identity comes from - An atomic check-and-debit that cannot overdraw under concurrent requests - Idempotent retries that never apply a payment twice - A data model from which every balance can be audited ### What a Strong Answer Covers - Turns the one-word "Venmo" prompt into a small, agreed feature set before writing or generating code - Exact money handling and input validation - Atomic, idempotent payments with an auditable transaction record - Uses the AI assistant deliberately: reviews and can explain every generated line, catches its mistakes, and runs the tests often - A structure that separates domain logic from the transport and storage layers ### Follow-up Questions - Add payment requests: one user asks another for money, and the other accepts or declines. - Add a feed of friends' payments, with public, friends-only and private visibility per payment. - A payment went to the wrong person. How would you support reversing it without editing history? - Walk through one piece of code the assistant generated. How did you check that it was correct?