Find recurring transactions in a stream of (company, amount, day) records. A minimum of 3 transactions with the same company, same amount, and the same number of days apart counts as recurring; return the companies with recurring transactions. Part 2: allow a ~20% tolerance on both the amount and the day-interval (fuzzy recurrence).

Group transactions by company, sort by day, then scan for runs of >=3 with consistent deltas (a hash map of company -> sorted timestamps, then diff adjacent). For part 2, replace exact-equality with a tolerance window (bucket by approximate amount, allow interval drift) and define the matching predicate explicitly. Call out edge cases: fewer than 3 records, irregular gaps, duplicate same-day entries. Clean data modeling, handling the multi-milestone escalation gracefully (your part-1 structure should extend to part-2 without a rewrite), and reasoning about fuzzy-matching tradeoffs rather than chasing optimal big-O.

Given end-of-day net balances between banks (transfer strings like 'AB5' meaning Bank A sends 5 to Bank B), compute the minimum number of transfers needed to settle, routing through a central bank: banks with a positive net pay the central bank, banks with a negative net receive from it.

Aggregate signed net balance per bank from the transfer log, then settle each non-zero bank against the central node so the transfer count is one per bank with a non-zero balance (debtors pay in, creditors get paid out). Verify conservation (nets sum to zero) and discuss why central-bank routing bounds the count vs. unconstrained pairwise netting. Translating a money-movement word problem into a netting model, correct sign handling, and an invariant argument for the central-bank bound; this is a domain-flavored problem, not a memorized template.

Build a transaction-deduplication function: first dedupe on exact transaction IDs, then extend it to collapse records that look equivalent but have slightly different fields (e.g., amount rounding, date offset by a day, merchant-name variants).

Start with a set/map keyed on the exact ID for the O(n) base case, then layer a normalization + canonical-key step (round amount, bucket date, normalize merchant) and a near-duplicate pass. Make the matching rules pluggable and discuss false-positive/false-negative tradeoffs and why upstream bank data is messy. Whether you treat unreliable/duplicate upstream data as a first-class concern, incremental extensibility of the design, and edge-case discipline (empty input, all-duplicates, ambiguous matches) over cleverness.

Design a highly available webhook notification/delivery service that informs Plaid's customers when new transaction or account data is available.

Persist events to a durable queue, deliver with at-least-once semantics + consumer-side idempotency keys, exponential backoff with a dead-letter queue, signed payloads, and per-customer rate limiting/fan-out. Discuss ordering guarantees, replay/redelivery, and monitoring of delivery lag. Reliable async delivery design: idempotency, retries/backoff, DLQ, security of outbound calls, and how you reason about at-least-once vs exactly-once at a fintech.

Design the pipeline that pulls and aggregates transaction data from thousands of banks/financial institutions with widely varying reliability and rate limits.

Per-institution adapters behind a uniform interface, a scheduler/work queue with per-bank concurrency and rate limits, circuit breakers for flaky banks, incremental sync with cursors, and a normalization layer into a canonical transaction schema. Address backfill vs incremental, dedup, and partial-failure isolation so one bank's outage doesn't stall others. Handling unreliable upstreams as the core problem: rate limiting, circuit breakers, isolation/bulkheads, idempotent ingestion, and schema normalization across messy sources.

Design a system to detect duplicate (or fraudulent) financial transactions in real time.

Streaming ingestion (Kafka-style), a windowed/stateful dedup keyed on a canonical transaction fingerprint, a fast store (e.g., Redis/sorted-set or KV) for recent-transaction lookups, and tunable matching for near-duplicates. For fraud, layer rules/ML scoring with a feedback loop. Discuss latency vs accuracy and false-positive cost. Stream-processing design, stateful windowing, the exact-vs-fuzzy matching tradeoff, and pragmatic latency/accuracy reasoning for money data.

Why Plaid? Why do you want to work on financial infrastructure / this role specifically?

Tie a genuine interest in fintech/APIs to a concrete Plaid product surface and a specific thing in your background; avoid generic 'mission' answers. Show you understand what Plaid does (bank connectivity, data, payments) and where you'd contribute. Authentic motivation and product understanding, not rehearsed mission-speak; signal that you've actually looked at what Plaid builds and engage with the financial-inclusion angle.

Tell me about a time you had to push back on a product requirement (or a stakeholder) because of a technical constraint.

STAR: name the constraint, the data you brought, how you proposed an alternative, and the outcome. Emphasize influencing a decision outside your immediate control and that you optimized for the user/business, not ego. Ownership, sound technical judgment, and cross-functional influence; ability to disagree constructively and land an outcome.

Describe a situation where a system you built failed in production (or a significant incident you owned). What happened and what did you do?

STAR with honesty: blast radius, your detection/mitigation, root cause, and the durable fix/prevention. Take real ownership rather than blaming others, and show what changed afterward (tests, monitoring, process). Accountability under failure, incident-response instincts, and a learning/prevention mindset suited to high-stakes financial systems.

Design a real-time fraud-detection (or transaction-risk-scoring) system for financial transactions.

Cover features (velocity, device, network/graph signals), a low-latency scoring service, the training-vs-serving split, handling class imbalance (e.g., resampling/SMOTE, cost-sensitive loss), a feedback/labeling loop, and the precision/recall tradeoff given the cost of false positives on payments. Mention model monitoring and drift. End-to-end ML system thinking under latency and imbalance constraints, plus judgment about false-positive cost in a financial setting.

Plaid Interview Questions

Plaid's SWE loop is recruiter screen → (sometimes) a ~90-min online assessment → a technical phone screen → a 4-5 round virtual onsite (practical coding, system design, behavioral/values, project deep-dive, plus a coffee chat). The signature is applied, multi-milestone coding on real fintech themes (parsing/deduping/reconciling bank transactions) done in a local IDE rather than abstract LeetCode, where interviewers layer on requirements and probe edge cases hard, judging clean, working, resilient code over big-O optimality.

18 real questions across 4 rounds

Reported via Technical phone screen problems quoted from the LeetCode 'Plaid Phone Interview' discuss write-up (leetcode.com/discuss/interview-question/1367137) — the recurring-transactions and bank-netting problems both appear there. Difficulty/themes and the dedup/retry/Sudoku problems corroborated by Coditioning ('Plaid SWE Final Coding Rounds'), techinterview.org, and Blind/aggregator guides (dataford, prepfully). The LeetCode company-tag list and difficulty split are confirmed against the Plaid company-tag aggregator. These are the most credibly Plaid-tied coding problems; multi-part/layered-follow-up format is consistent across sources.

Run a Plaid mock with the AI interviewer. It asks questions like these, follows up on your answers, and tells you exactly what to fix. The only score that means anything is the one on your real answers.

Continue with Google

Keep prepping

All company interviews