Bank of America Coding Interview Questions: Digital Banking at Scale

Bank of America is one of the largest banks in the US, headquartered in Charlotte, North Carolina, and for many of its customers the bank is effectively an app: checking balances, depositing checks by phone, paying bills, sending money to friends, and asking Erica, the app's virtual assistant, about their spending. Behind that app sits a very large technology organisation, which also supports wealth management under the Merrill brand and investment banking and markets under BofA Securities.

That combination - a consumer product used at very large scale, and an engineering organisation big enough to run many different hiring pipelines - is what shapes the interview. Candidates generally describe a fundamentals-based coding bar, and the follow-ups worth preparing for are about what happens when a feature is used by a very large number of people at once, on patchy mobile connections, on app versions released long ago. This guide covers what that scale changes, how the process tends to run for experienced hires and for the early-career programs, and the problem types to prepare - patterns, not invented leaked prompts.

What consumer digital banking at scale changes

A banking app looks simple: a sign-in screen, a list of accounts, a list of transactions, and a few buttons that move money. The difficulty is in the numbers behind it - a very large customer base, predictable peaks around paydays and bill due dates, and older versions of the app that stay installed long after a new release ships. In an interview, that becomes a particular kind of follow-up: your solution works, so what breaks when it runs at that scale?

None of this means designing a global platform inside a coding round. It means noticing, unprompted, that your code has users - a lot of them, on imperfect networks and devices - and saying one or two precise sentences about it.

Payments in the app: the client side of money movement

Money movement is where mistakes are most visible to customers. Bank of America's app offers person-to-person payments through Zelle alongside transfers, bill pay, and scheduled payments, and interviews for consumer-facing teams can probe the path from a tap on a phone to a confirmed payment. The ledger side - idempotency keys, balance updates, and audit records - is worth knowing, and our Wells Fargo guide works through that pattern in code. On a consumer-digital team, the experience layer around it tends to get more of the attention:

• Pending versus confirmed. What the app shows between the tap and the final result, and how it avoids telling a customer a payment succeeded before it has.
• The double tap. A customer on a weak connection taps Send twice, or the app retries after a timeout. Each request needs an identifier the server can recognise as a repeat.
• Recipient lookup. Finding someone by email address or mobile number means normalising input, looking it up in a directory, and revealing no more about the recipient than the sender needs.
• Limits and velocity checks. Per-payment and daily limits, plus checks on how many payments were sent in a recent window - a sliding-window problem in disguise.
• Scheduled and recurring payments. Monthly on the 31st, weekends, holidays, and what happens when the funding account is short on the scheduled date.
• Step-up verification. When a payment looks unusual, asking for extra confirmation rather than blocking outright - a trade-off between fraud risk and customer friction.

One company, a very large technology organisation

Bank of America's technology workforce is very large, and it supports far more than the consumer app: payments infrastructure, cybersecurity, data platforms, the systems behind Merrill and BofA Securities, and the shared infrastructure everything runs on. Two consequences follow for candidates.

First, the same job title can lead to very different interviews. A software engineering opening might sit on a mobile team, an API platform team, or a data team, so the posting and your recruiter are the best guides to what will be tested. Second, hiring at this volume tends to rely on consistent screening early in the process, so your fundamentals need to be dependable before any team-specific depth matters. Role families commonly tilt the interview like this:

• Mobile (iOS and Android). Platform questions alongside coding: the app lifecycle, state and offline behaviour, secure storage on the device, accessibility, and the language the posting names - typically Swift or Kotlin for native apps.
• Web front end. JavaScript or TypeScript depth, rendering performance, accessibility, and calling APIs securely from the browser.
• Back end and APIs. Data structures and algorithms, API design, SQL, concurrency basics, and reliability between services.
• Data and analytics. SQL depth, data modelling, pipelines, and data quality checks.
• Infrastructure, reliability, and cybersecurity. Operating systems, networking, automation, and how you reason during an incident.

How the process tends to run

Reported processes differ between experienced hiring and the structured early-career programs, which are covered in the next section. For experienced roles, candidates commonly describe stages like these; the number and order of rounds vary by team, level, and location.

• Recruiter screen. Background, role fit, and logistics, sometimes with a few light technical questions.
• Technical screen or assessment. Live coding in a shared editor or a timed online assessment, depending on the pipeline.
• Team interviews. Coding, a design conversation scaled to your level, questions about your past work, and behavioral questions - sometimes spread across separate days, sometimes grouped together.
• Decision. Feedback is gathered and the recruiter follows up.

Early-career technology programs

Bank of America recruits students and recent graduates into structured technology programs, historically including a summer analyst internship and a full-time analyst program for graduates, listed under names such as Global Technology Summer Analyst and Global Technology Analyst. Names, locations, timelines, and stages change from year to year, so the live listing on the bank's campus careers site is the source of truth.

Candidates commonly describe one or more online steps early on - an assessment, and in some pipelines a recorded video interview - followed by a final round of short back-to-back interviews. The bigger difference from experienced hiring is the question the interviewers are trying to answer:

• You apply to a track, not a named team. Recent listings have been for broad tracks - software engineering, cybersecurity, and business analysis, for example - often across multiple locations, so interviewers tend to weigh general fundamentals and potential over any one team's stack.
• Consistency carries weight. Program hiring compares many candidates for similar roles, so dependable fundamentals, clear communication, and prepared behavioral stories matter a great deal.
• Your projects are your work history. Be ready to walk through one project end to end: what you built, a decision you would change, and how you tested it.
• Motivation should be specific. A genuine observation about a banking feature you actually use - how you think it works behind the scenes and what could go wrong - is far stronger than a general interest in technology.
• Apply early. Campus recruiting opens well ahead of the start date and has run on a rolling basis, with assessments often starting before the application deadline.

For broader early-career preparation - assessments, recorded interviews, and behavioral basics - see our new grad interview guide.

What to study for a Bank of America software engineer interview

• Arrays, strings, and hash maps. The highest-yield block: counting, grouping, deduplication, and lookups.
• Sorting and merging. Merging sorted streams - pending and posted transactions, or activity from several accounts - and ordering with tie-breakers.
• Heaps and scheduling. Next-due items, top-K spending categories, and anything ordered by time.
• Sliding windows. Velocity checks and rate limits are windowed counting problems.
• Tries, trees, and graphs. Prefix search for payees and merchants, plus basic traversal.
• SQL and data modelling. Joins, aggregation, window functions, and indexes that match the queries an app makes constantly.
• API design for mobile clients. Pagination, versioning, error responses the app can act on, and safe retries.
• Caching and consistency (experienced roles). What to cache, for how long, and what a customer sees when data is stale. Our system design reference covers the building blocks.
• Your primary language, properly. The one named in the posting, including its collections, error handling, and testing tools.

For structured algorithm coverage, our LeetCode patterns guide spans the easy-to-medium range candidates commonly report.

Representative problem types

Described as categories so you prepare the pattern rather than a single prompt:

• Paginated history. Return a customer's transactions newest first, one page at a time, with no repeats or gaps as new transactions arrive.
• Merging feeds. Combine several sorted lists - pending and posted transactions, or activity from multiple accounts - into one ordered view.
• Notification rules. Evaluate customer-configured rules, such as a purchase above a chosen amount, against a stream of transactions without sending the same notification twice.
• Rate limiting. Allow at most N sign-in attempts or payments per customer in a rolling window.
• Spending summaries. Group transactions by category and month, then report top merchants or categories.
• Recurring schedules. Compute the next run date for a monthly payment across short months, weekends, and holidays.
• Prefix search. Suggest payees or merchants as the customer types.
• Practical design. The transaction history API behind the app, a staged rollout for a feature used by millions of customers, or sign-in throttling that stops attackers without locking out real customers.

Here is the flavour of problem that fits a consumer-digital team - serving transaction history to the app one page at a time, in a way that stays correct while new transactions keep arriving.

def transaction_page(txns, limit, cursor=None):
    """txns: list of dicts with "posted_at" (UTC timestamp), "id", "amount_cents".
    Returns (page, next_cursor): up to `limit` items, newest first.
    The cursor is the sort key of the last item sent - not a page number."""
    if limit <= 0:
        raise ValueError("limit must be positive")
    key = lambda t: (t["posted_at"], t["id"])            # id breaks timestamp ties
    newest_first = sorted(txns, key=key, reverse=True)   # production: an index does this
    if cursor is not None:
        newest_first = [t for t in newest_first if key(t) < cursor]
    window = newest_first[:limit + 1]                    # one extra row: is there more?
    page = window[:limit]
    next_cursor = key(page[-1]) if len(window) > limit else None
    return page, next_cursor

The strong answer is the reasoning around the code. Offset pagination breaks the moment a new transaction lands at the top: everything shifts down one place, so the next page repeats an item the customer has already seen, and deep offsets get slower as the database skips rows. A cursor built from the sort key avoids both problems, the ID breaks ties when two transactions share a timestamp, and fetching one extra row tells the app whether another page exists without an empty final request. Then name what the in-memory version leaves out: in production a composite index on account, timestamp, and ID turns each page into a short range scan however far the customer scrolls; the cursor should be encoded as an opaque token so app versions never depend on its format; and pending transactions that post later with a new timestamp can move, which is a good reason to discuss showing pending items separately.

What interviewers actually score

• Fundamentals first. A correct, readable solution with stated complexity before any discussion of scale.
• Scale awareness without over-engineering. One or two well-chosen points about load, caching, or pagination - not a distributed system for a small problem.
• Client empathy. Patchy networks, retries, older app versions, and what the customer actually sees when something goes wrong.
• Security and privacy instincts. Masking account numbers in logs, least-privilege access, and never trusting input from the client.
• Safe delivery. Tests, feature flags, and how you would roll a change out gradually - and back.
• Collaboration. STAR stories about working across teams, since features in a large organisation usually cross several of them.

A note on integrity: prepare thoroughly and reason honestly in the room. Scale and failure follow-ups are where genuine understanding shows, and "I have not built that, but here is how I would reason about it" lands better than a confident guess.

Bank of America versus other big-bank interviews

Large US banks are easy to lump together, but the preparation differs. At JPMorgan Chase, the first question is which line of business and track you are interviewing for, which our JPMorgan guide covers in detail, while other banks lean toward markets technology or backend modernisation. The distinctive thing to prepare for at Bank of America is consumer digital scale: an app used by a very large customer base, payments that customers watch happen in real time, and a technology organisation large enough that structured programs and consistent screening shape how it hires.

A realistic two-week prep plan

1. Days 1-2: Confirm the role family - mobile, web, back end, data, or infrastructure - or the program you are interviewing for, and what each stage covers. Reread the posting for the language and domain.
2. Days 3-6: Core patterns - arrays, strings, hash maps, sorting, merging, heaps, and sliding windows - finishing each problem with its complexity and edge cases said out loud.
3. Days 7-8: SQL and API design for a mobile client: keyset pagination, versioning, error responses, and indexes that match the queries.
4. Days 9-11: Scale rehearsal - explain the transaction history API, a staged rollout plan, and sign-in rate limiting, each with what breaks first under load. Mobile candidates should add iOS or Android platform fundamentals.
5. Days 12-14: Behavioral STAR stories about cross-team work and careful delivery, a walkthrough of one project end to end, and a timed mock that ends every problem with "what changes when millions of people use this?"

FAQ

How hard are Bank of America coding interview questions?

Candidates generally describe a fundamentals-based bar, with most reported coding problems in the LeetCode easy-to-medium range. The harder part is often the follow-up: what happens to your solution when a very large number of customers use it at once, on unreliable mobile connections and older app versions. A clean solution with sensible scale and failure reasoning tends to matter more than a rare algorithm.

Does Bank of America have technology programs for students and graduates?

Yes. Bank of America recruits students and recent graduates into structured technology programs, historically including a summer analyst internship and a full-time analyst program. Candidates commonly describe one or more online steps, such as an assessment or a recorded video interview, followed by a final round of short back-to-back interviews. Names, timelines, and stages change each year, so check the current listing on the campus careers site and confirm with your recruiter.

What topics should I study for a Bank of America software engineer interview?

Start with core data structures and algorithms: arrays, strings, hash maps, sorting and merging, heaps, sliding windows, and basic trees and graphs. Then add SQL, API design for mobile clients including pagination and versioning, and the language named in the posting. Experienced candidates should also prepare caching, consistency, and safe rollout practices, and mobile candidates should review iOS or Android platform fundamentals.

How does consumer digital banking show up in Bank of America interviews?

Mostly through follow-up questions about scale and the customer experience. Once your solution works, be ready to discuss pagination that stays correct as new transactions arrive, rate limits on sign-in and payments, caching, older app versions that are still in use, and rolling changes out gradually. You do not need to design a global system, but noticing that your code has a very large number of users is a strong signal.

Are Bank of America mobile engineering interviews different?

They commonly add platform questions to the usual coding round. Depending on the team, that can include the app lifecycle, managing state and offline behaviour, secure storage on the device, accessibility, and the language named in the posting, typically Swift or Kotlin for native apps. Ask your recruiter whether your loop includes a platform-specific round so you can prepare the right depth.