Design a Banking Component with Transfers and Activity Rankings

Read the full interview experience this question came from →

Quick Overview

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.

Read the full Capital One Software Engineer interview experience this question came from

|Home/Software Engineering Fundamentals/Capital One
Capital One logo
Capital One
Aug 23, 2026
mediumSoftware EngineerOnsiteSoftware Engineering Fundamentals
1
0

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?
Loading comments...