Plaid builds APIs that let apps connect to users’ bank accounts and move financial data, and candidates say its coding interviews reflect that: practical problems about transactions, accounts and data cleanup rather than pure puzzles. As of October 2026 Plaid does not publish its process, and third-party reports disagree on details, so the outline below is a pattern, not a guarantee. Confirm the format of each round with your recruiter.<\/p>\n
The take-home challenge mentioned in many older articles does not show up consistently in recent reports. Ask whether your loop has one rather than assuming.<\/p>\n
A “practical” problem usually gives you a messy data set and a business rule. The skill being tested is turning vague requirements into correct code: clarifying, choosing a data structure, handling bad data, and extending the solution when a new requirement arrives. Expect several steps of the same problem, so write code that is easy to modify. Use clear names, small functions, and avoid cleverness you will have to undo.<\/p>\n
The underlying algorithms are still the usual ones: hash maps, sorting, two pointers, sliding windows, intervals, and simple graphs. Money is a special area, so keep these habits:<\/p>\n
0.1 + 0.2<\/code> is not 0.3<\/code> in floating point.<\/li>\n- Decide what happens with negative amounts, zero, missing fields and unknown accounts, and say so.<\/li>\n
- Make operations that change several balances all-or-nothing: validate everything first, then change state.<\/li>\n<\/ul>\n
Practice problem 1: find duplicate transactions<\/h2>\n
A transaction is a possible duplicate if the same account, amount and merchant appear again within 60 seconds. Return pairs of (earlier id, later id). Sort by time, remember the last transaction for each (account, amount, merchant) key, and compare timestamps.<\/p>\n
def find_duplicates(txns, window=60):\n \"\"\"txns: (id, timestamp_sec, account, amount_cents, merchant), any order.\"\"\"\n last_seen = {}\n dupes = []\n for tid, ts, acct, amt, merchant in sorted(txns, key=lambda t: t[1]):\n key = (acct, amt, merchant)\n if key in last_seen and ts - last_seen[key][1] <= window:\n dupes.append((last_seen[key][0], tid))\n last_seen[key] = (tid, ts)\n return dupes\n\ntxns = [\n (\"t1\", 100, \"A\", 450, \"coffee\"),\n (\"t2\", 130, \"A\", 450, \"coffee\"),\n (\"t3\", 140, \"A\", 999, \"books\"),\n (\"t4\", 400, \"A\", 450, \"coffee\"),\n]\nprint(find_duplicates(txns))\n# [('t1', 't2')]<\/code><\/pre>\nTime is O(n log n) for the sort and O(k) extra space for k distinct keys. Questions the interviewer may ask next: what if a third identical charge arrives 40 seconds after the second (here it is paired with the second, not the first; is that what the business wants?), what if timestamps are not exact, and how would this work on a stream where you cannot sort first (keep only entries newer than the window and evict old ones). That last version is a sliding window over time, the same idea as in our sliding window guide<\/a>.<\/p>\nPractice problem 2: an in-memory ledger<\/h2>\n
A frequent take-home or live-coding shape is a small banking API with create, deposit, withdraw, balance and transfer. The logic matters more than the web framework. Write the core as a class you can test without a server, then put thin HTTP routes (for example with Express) on top.<\/p>\n
class Ledger {\n constructor() { this.balances = new Map(); }\n create(id, cents = 0) {\n if (this.balances.has(id)) throw new Error(\"account exists\");\n this.balances.set(id, cents);\n }\n deposit(id, cents) {\n this.#check(id, cents);\n this.balances.set(id, this.balances.get(id) + cents);\n }\n withdraw(id, cents) {\n this.#check(id, cents);\n if (this.balances.get(id) < cents) throw new Error(\"insufficient funds\");\n this.balances.set(id, this.balances.get(id) - cents);\n }\n transfer(from, to, cents) {\n this.#check(to, cents); \/\/ validate both sides before changing anything\n this.withdraw(from, cents);\n this.deposit(to, cents);\n }\n #check(id, cents) {\n if (!this.balances.has(id)) throw new Error(\"no such account\");\n if (!Number.isInteger(cents) || cents <= 0) throw new Error(\"amount must be a positive integer\");\n }\n}\n\nconst l = new Ledger();\nl.create(\"a\", 1000); l.create(\"b\");\nl.transfer(\"a\", \"b\", 250);\nconsole.log(l.balances.get(\"a\"), l.balances.get(\"b\")); \/\/ 750 250\ntry { l.transfer(\"a\", \"zzz\", 10); } catch (e) { console.log(e.message, l.balances.get(\"a\")); }\n\/\/ no such account 750\ntry { l.withdraw(\"b\", 999); } catch (e) { console.log(e.message); }\n\/\/ insufficient funds<\/code><\/pre>\nNotice that a failed transfer to an unknown account leaves the sender’s balance at 750. That is the all-or-nothing property. In a single-threaded Node process this simple version is safe because nothing runs between the withdraw and the deposit. If the interviewer asks about concurrency, say that this stops being true with several processes or a database, and that you would use a transaction (or row-level locks) and an idempotency key so a retried request does not move money twice. Also mention that transfers between the same account should be rejected or defined explicitly, and that a real system records every change in an append-only list of entries rather than only updating balances.<\/p>\n
System design<\/h2>\n
Plaid’s domain suggests prompts like “design a system that ingests millions of transactions a day and offers near-real-time analytics”, or a webhook delivery service, or a service that syncs data from many banks that have different APIs and outages. A workable outline:<\/p>\n
\n- Requirements.<\/strong> Volume, freshness, correctness (money data cannot silently lose or duplicate records), and who reads the data.<\/li>\n
- Ingestion.<\/strong> API or pull-based connectors feeding a durable queue, so a slow downstream does not lose data.<\/li>\n
- Processing.<\/strong> Idempotent workers that deduplicate by a stable transaction key, normalize formats and categorize.<\/li>\n
- Storage.<\/strong> A relational database or ledger-style store for the source of truth, with an analytics store for aggregates.<\/li>\n
- Delivery.<\/strong> Webhooks with retries, exponential backoff and signing; a pull API with pagination and cursors.<\/li>\n
- Failure handling.<\/strong> Upstream bank outages, rate limits, partial syncs, reprocessing after bugs, monitoring and alerting.<\/li>\n<\/ol>\n
For general practice, these clarifying questions<\/a> work for any design prompt.<\/p>\nBehavioral and project deep dive<\/h2>\n
Plaid reportedly asks about ownership, ambiguity and working across teams, and a project deep dive lets the interviewer probe your own work. Choose one project you know in detail: why it was built, the alternatives you rejected, what broke, what you would change. Be able to draw its architecture and say which parts you personally wrote.<\/p>\n
Preparation checklist<\/h2>\n\n- Solve 30 to 50 medium problems across hash maps, sorting, intervals, sliding window and graphs. Our hash map lesson<\/a> is a good starting point if you are rusty.<\/li>\n
- Practice “extend the solution” drills: solve a problem, then have a friend add a new requirement and adapt.<\/li>\n
- Build the ledger above in your language of choice, with tests, in under an hour.<\/li>\n
- Read about APIs, pagination, idempotency, retries and webhooks.<\/li>\n
- Prepare your project deep dive and four or five behavioral stories.<\/li>\n<\/ul>\n