How the interviewer opens it
“Design a platform that connects to financial institutions and exposes account and transaction data in a common format. Users must control access to their data, and the platform must keep that data current.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Institutions and access
- Scale
- Read and write traffic
- Freshness and sync cost
- Bank API differences
- Latency
- Consistency, availability, and durability
- Consent revocation
- Retention and deletion
- Scope limits
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Connect a bank with the user's consent
- Expose accounts, balances, and transactions in a common format
- Keep data current through incremental sync
- Revoke access and delete the associated data
Usually out of scope
- Move money or initiate payments
- Collect bank passwords or extract data from bank websites
- Categorize transactions or assess credit risk
- Provide active service across multiple regions
What interviewers ask about
- The meaning of bank data
- Banks represent the same financial event in different ways. Incorrect normalization can duplicate expenses or misstate balances.
- Progress through transaction changes
- A sync must survive page retries, corrections, and cursor resets without losing changes or creating duplicate records.
- Access after consent ends
- Revocation must stop access across reads, queued work, late bank responses, and retained copies.
- Freshness during bank failures
- Bank quotas and outages control data freshness. One large bank can create enough delayed work to affect every other bank.
Common mistakes
- Assumes all bank APIs provide stable IDs and complete delta feeds.
- Treats transaction sync as an append-only import.
- Uses the newest transaction date as the only sync checkpoint.
- Treats consent revocation as token deletion alone.
- Makes client reads depend on live bank requests.
- Adds workers without accounting for bank quotas or delayed work.
The bar by level
- Senior (L5/E5)
- Defines atomic sync progress, correction scans, and pending transaction rules. Handles quota limits, stale workers, token rotation, and late results after revocation.
- Staff (L6+/E6+)
- States guarantees when bank APIs lack stable identity or sufficient quotas. Defines revocation across restores, consent generations, and every access path. Quantifies freshness limits and isolates institutional failures.