Design accounts, deposits, transfers, and activity rankings with clear invariants, exact amounts, explicit ranking rules, and a string-input test harness.
Design a Banking Component with Transfers and Activity Rankings
Company: Capital One
Role: Software Engineer
Category: Software Engineering Fundamentals
Difficulty: medium
Interview Round: Onsite
Design an object-oriented in-memory banking component that develops through three stages. Inputs for testing arrive as arrays of strings, so include a separate test harness that interprets the operations and compares results with supplied expectations.
### Part 1 — Accounts and deposits
Support `createAccount` and `deposit`. Explain account identity, balance representation, validation, and duplicate or missing-account behavior.
#### What This Part Should Cover
- A clear account model and exact monetary representation.
- Well-defined success and failure results without unintended state changes.
### Part 2 — Transfers
Support transferring value between two accounts. Describe the checks and state changes needed to keep a failed transfer from partially modifying balances.
#### What This Part Should Cover
- Validation of both accounts, the amount, and available funds.
- Atomic changes to source and destination, with an explicit policy for self-transfers.
### Part 3 — Most active accounts and input handling
Return the top `N` accounts by activity. Clarify whether activity counts successful operations or sums transferred/deposited amounts, which accounts a transfer credits with activity, and how ties are ordered.
#### What This Part Should Cover
- A declared activity definition applied consistently to successful operations.
- Ranking complexity and behavior when fewer than `N` accounts exist.
- Parsing string inputs outside the account logic, checking argument types, and comparing structured results with expected results.
### What a Strong Answer Covers
- Consistent invariants across balances, transfers, and activity scores.
- Separation of parsing, domain operations, and the test harness.
- Explicit treatment of unspecified rules rather than claiming one hidden activity metric or tie order is correct.
### Follow-up Questions
- How would you ensure a rejected transfer does not change either account's activity score?
- What test would distinguish operation-count activity from amount-based activity?
Overview: Design accounts, deposits, transfers, and activity rankings with clear invariants, exact amounts, explicit ranking rules, and a string-input test harness.
Design an object-oriented in-memory banking component that develops through three stages. Inputs for testing arrive as arrays of strings, so include a separate test harness that interprets the operations and compares results with supplied expectations.
Part 1 — Accounts and deposits
Support createAccount and deposit. Explain account identity, balance representation, validation, and duplicate or missing-account behavior.
What This Part Should Cover Guidance
A clear account model and exact monetary representation.
Well-defined success and failure results without unintended state changes.
Part 2 — Transfers
Support transferring value between two accounts. Describe the checks and state changes needed to keep a failed transfer from partially modifying balances.
What This Part Should Cover Guidance
Validation of both accounts, the amount, and available funds.
Atomic changes to source and destination, with an explicit policy for self-transfers.
Part 3 — Most active accounts and input handling
Return the top N accounts by activity. Clarify whether activity counts successful operations or sums transferred/deposited amounts, which accounts a transfer credits with activity, and how ties are ordered.
What This Part Should Cover Guidance
A declared activity definition applied consistently to successful operations.
Ranking complexity and behavior when fewer than
N
accounts exist.
Parsing string inputs outside the account logic, checking argument types, and comparing structured results with expected results.
What a Strong Answer Covers Guidance
Consistent invariants across balances, transfers, and activity scores.
Separation of parsing, domain operations, and the test harness.
Explicit treatment of unspecified rules rather than claiming one hidden activity metric or tie order is correct.
Follow-up Questions Guidance
How would you ensure a rejected transfer does not change either account's activity score?
What test would distinguish operation-count activity from amount-based activity?