BNY Software Engineer Interview Guide

The 60-second brief

BNY is a financial institution, and candidates describe the engineering work as supporting treasury services, cash processing and other financial platforms. The project areas they list include cloud infrastructure, API-driven services, moving legacy mainframe systems onto newer platforms, Java-based full-stack applications and database automation. In this role you translate business requirements into technical specifications, write and test code, tune databases, refactor older components and integrate cloud services, working with product managers and operations colleagues while following compliance and security protocols.

This guide is for Software Engineer candidates preparing for BNY. It covers the three reported stages, the thirteen questions candidates report (data structures and algorithms, system design and architecture, behavioral and motivation), the project deep dive candidates describe, and the fundamentals (OS, DBMS, networks) they say come up. The stack candidates mention is Java or another object-oriented language, SQL and relational databases, cloud platforms (AWS or Azure) and Angular or a similar front-end framework.

Candidates report three stages over roughly 3-5 weeks: an Online Assessment, two to three Technical Interviews that mix coding, system design and project discussion, and a final Behavioral Interview that is sometimes managerial. The exact shape varies by team and region.

Focus areas

• DSA (Data Structures & Algorithms) Coding
• Data Structures
• Algorithms

Overview

The loop is short but uneven. After the Online Assessment come two to three technical rounds, and candidates say the weight differs by team: some lean on data structures and algorithms, others spend most of the time on your past projects. Because you cannot tell in advance which kind of team you will meet, prepare both halves: timed coding in Java (or your strongest object-oriented language), and a rehearsed, detailed account of everything on your resume.

The algorithm material candidates list is arrays and strings, trees and graphs (traversal, cycle detection, shortest paths), dynamic programming with memoization, and stating Big-O for time and space. Reported example problems are the longest palindromic substring and cycle detection in a directed graph. The reported questions add array versus linked-list trade-offs, the three binary-tree traversals, sliding window or dynamic programming, merge sort complexity and binary search edge cases. Candidates also say operating systems, database and networking basics come up, so keep a short review sheet for those.

The architecture side is built around money-moving systems and older estates: processing high-volume financial transactions, choosing between SQL and NoSQL, migrating a legacy application to the cloud, and securing APIs across a distributed system. For the transaction question, a throughput number alone is not an answer; plan to talk about duplicate submissions, ordering, durable records, reconciliation and audit trails. Candidates also describe project deep dives such as walking through a database schema you designed or the hardest bug you debugged, so have specifics ready.

The last stage is described as behavioral or managerial, with attention to stability and an understanding of the financial domain. Prepare three structured stories (a team disagreement, learning a technology quickly, working to a tight deadline) and a specific answer to why you want BNY rather than another financial institution.

The BNY interview process

Candidates describe three stages, summarised below with what each one involves and how to prepare. Treat the order and the number of technical rounds as typical rather than fixed, since teams and regions differ.

Online Assessment

Candidates report that the process opens with an online assessment that works as a technical filter. The reported material does not spell out its format or contents, so prepare for timed, unaided coding in general. Candidates who prepared for it point to graph, dynamic programming, array and string problems. Pick one language, practise in a plain editor, and get into the habit of reading the constraints first, writing a few edge-case tests of your own and stating complexity in one sentence before you submit.

What to demonstrate

• Correct, working code in an online, timed format
• Choosing an algorithm that fits the constraints and stating its time and space cost
• Handling edge cases such as empty input, single elements and duplicates

How to prepare

• Solve graph, dynamic programming, array and string problems against a timer in Java or your strongest language, since those are the areas candidates say to drill.
• Work the two reported example problems end to end: longest palindromic substring (expand around each centre in O(n^2), or a DP table) and cycle detection in a directed graph (three-colour DFS or Kahn's algorithm).
• Write your own edge-case tests before submitting: empty input, one element, all-equal values, the largest allowed size.
• After every solution, say the time and space complexity aloud in a single sentence.

Technical Interviews

Candidates report two to three technical interviews combining coding, system design and project discussion. A coding stage is where the reported coding questions are practised: array versus linked-list trade-offs, in-order, pre-order and post-order traversal, sliding window or dynamic programming, merge sort complexity and binary search edge cases. The design questions to rehearse cover high-volume financial transactions, SQL versus NoSQL, cloud migration of a legacy application and API security. Candidates also describe a deep dive into projects on your resume, including the trade-offs you made, and say OS, DBMS and networking fundamentals come up. Start coding answers from a brute-force version, then improve it while narrating your reasoning.

What to demonstrate

• Working code for the coding questions, with complexity stated
• Reasoning about scalability, data stores and security in a design discussion
• Explaining your own project decisions, schema and hardest bug
• Computer science fundamentals: OS, DBMS and networks

How to prepare

• Write recursive and iterative versions of all three tree traversals, one fixed-size and one variable-size sliding window, one DP problem both top-down and bottom-up, and binary search with careful bounds.
• Outline a design for a high-volume transaction pipeline: a durable log or queue, idempotency keys, partitioning, a relational store for the ledger, reconciliation and audit records. Practise the SQL versus NoSQL choice as a table of workloads and trade-offs.
• Prepare two resume projects with architecture, schema, one trade-off, one hard bug and one measurable result each.
• Make a one-page sheet for OS (process versus thread, deadlock), DBMS (ACID, indexes, isolation levels) and networks (TCP, HTTP, TLS).

Behavioral Interview

Candidates describe the final stage as a behavioral or managerial round that focuses on stability and on understanding the financial domain. The reported questions are a disagreement within a team, learning a technology on the fly, handling a tight deadline and why you want BNY compared to other financial institutions. Candidates say behavioral answers carry real weight even though the process is mostly technical. Prepare concrete stories with your own decisions and results, plus a motivation answer that is specific rather than generic.

What to demonstrate

• How you describe decisions, trade-offs and collaboration through real examples
• Stability and reliability, as reported for this stage
• Basic understanding of how financial institutions use technology
• How you handle pressure and disagreement

How to prepare

• Write three structured stories (situation, your action, result) for the disagreement, new-technology and tight-deadline prompts, each with a number or a concrete outcome.
• Write a specific answer to why BNY: connect the work candidates describe (treasury services, cash processing, cloud and API work, legacy modernisation) to something you have built or want to learn.
• Read up on basic financial-technology ideas such as payment flows, settlement and reconciliation, so you can discuss the domain in plain words.
• Prepare questions about the team's stack and balance between algorithms and project work, since teams differ.

Where candidates lose points

Listing a technology or project on the resume that you cannot explain in depth

Candidates report deep dives into projects, schemas and hardest bugs. For each resume entry, prepare its architecture, one trade-off, one bug and one measurable result, and remove anything you cannot defend.

Jumping to the optimized solution, or coding silently, on the sliding window, dynamic programming or graph problems

State the brute-force version and its cost first, then name the inefficiency you are removing. Say what the window, state or visited set represents before writing the loop, and give the final complexity.

Off-by-one and boundary errors in binary search, tree traversal or window shrinking

Fix a loop invariant before coding (for example, the answer lies in [lo, hi]). Compute the midpoint as lo + (hi - lo) / 2, and trace empty, single-element, absent-key, duplicate and null-child cases on paper before you declare the solution done.

Answering the financial-transactions design question with throughput alone

Add the correctness pieces for money-moving systems: idempotency keys for retries, ordering per account, a durable log, reconciliation and audit records. Then discuss partitioning and failure of a downstream dependency.

Giving a generic answer to the behavioral prompts and to why BNY

Use real stories with your decision, a trade-off and an outcome. For the motivation question, tie the treasury, cash-processing, cloud and legacy-modernisation work candidates describe to something specific in your own experience, and skip lines that would suit any bank.

Questions & practice

Explain the difference between arrays and linked lists in terms of memory and performance.

Medium · Technical & DSA

Approach

1. Start with layout: an array is one contiguous block, so element i sits at base + i * elementSize and index access is O(1). A linked list is separate heap nodes joined by references, so reaching position i means walking i nodes, which is O(n).
2. Compare the mutations. Inserting or deleting in the middle of an array shifts the tail, O(n). A linked list splices in O(1) once you hold the node (singly linked: the node before it), but finding that node is still O(n). A dynamic array such as Java's ArrayList appends in amortized O(1) and copies everything, O(n), when it resizes.
3. Cover memory overhead. Each list node carries one or two references plus, in Java, an object header, so it costs several times more per element than an int[] slot. Note that an ArrayList<Integer> holds references to boxed Integers, so the values themselves are not contiguous; only primitive arrays are.
4. Explain the cache effect: sequential array scans use spatial locality and hardware prefetching, while a list traversal chases pointers and misses cache. That is why arrays often beat lists in practice even for workloads with some middle inserts.
5. Say when a list is the right call: O(1) removal through a node handle, as in an LRU cache built from a hash map plus a doubly linked list, or O(1) work at both ends (Java's LinkedList implements Deque, though ArrayDeque is usually faster).

Follow-up

• How would you build an LRU cache with O(1) get and put, and why does it need a doubly linked list?
• Why is ArrayList.add amortized O(1) when some appends copy the whole array?
• Reverse a singly linked list in place, then do it recursively. What does each version cost in space?

How do you implement in-order, pre-order, and post-order traversals in binary trees?

Medium · Technical & DSA

Approach

1. Give the three orders exactly. In-order visits left, node, right. Pre-order visits node, left, right. Post-order visits left, right, node. Write the recursive version first: O(n) time and O(h) stack space, where h is the tree height (O(log n) when balanced, O(n) when skewed).
2. Write in-order iteratively with an explicit stack: push the whole left chain, pop and visit, then move to the popped node's right child and repeat. This avoids StackOverflowError on a deep, skewed tree in Java.
3. Write pre-order iteratively: push the root; pop, visit, then push the right child before the left so the left comes off first. For post-order, either run node-right-left with one stack and reverse the output, or use one stack with a last-visited pointer so a node is visited only after its right subtree.
4. Mention Morris traversal for O(1) extra space. It temporarily threads each in-order predecessor's right pointer back to the current node and restores it afterwards, still in O(n) time.
5. Link each order to its use: in-order on a BST yields sorted keys (BST validation, kth smallest), pre-order serializes or copies a tree, and post-order computes heights or frees children before parents. Test on an empty tree, a single node and a fully left-skewed tree.

Follow-up

• Validate a binary search tree using an in-order traversal. What do you compare, and how do you handle duplicate keys?
• Rebuild a tree from its pre-order and in-order sequences. Why does that need unique values?
• Return the level-order traversal instead. Which data structure replaces the stack?

Write a program to solve a sliding window problem or a dynamic programming challenge.

Medium · Technical & DSA

Approach

1. Decide which pattern fits before writing code. A sliding window fits a question about a contiguous subarray or substring where growing or shrinking the window moves the condition in one direction. DP fits when the answer is built from overlapping subproblems with optimal substructure.
2. For a variable window, use two pointers: extend the right end, and while the window breaks the condition, advance the left end and update the state (a running sum, a HashMap of character counts or last-seen indices). Each index enters and leaves at most once, so the work is O(n). Longest substring without repeating characters is the standard example.
3. State the precondition. Shrinking a window to reach a target sum only works when all values are non-negative. With negatives, switch to prefix sums with a HashMap of prefix-sum counts (subarray sum equals k), which is still O(n).
4. For DP, define the state, the recurrence, the base cases and the fill order. For example, coin change is dp[a] = min over coins c of dp[a - c] + 1, which is O(amount * coins). Write top-down memoization first, then convert it to bottom-up and keep only the rows the recurrence reads.
5. Check edge cases aloud: empty input, a window larger than the array, every element identical, no valid answer (return -1 or 0 as agreed), and int overflow in running sums (use long).

Follow-up

• Why does the shrinking-window approach fail when the array contains negative numbers, and what replaces it?
• Find the longest palindromic substring. Compare expanding around centres with a DP table on time and space.
• Return the actual subarray or the coins used, not just the length or count. What extra state do you keep?

Explain the time and space complexity of sorting algorithms like merge sort.

Medium · Technical & DSA

Approach

1. Merge sort splits the array in half, sorts each half recursively and merges them in linear time. The recurrence T(n) = 2T(n/2) + O(n) gives O(n log n) in the best, average and worst case.
2. Space is O(n) auxiliary for the merge buffer on arrays, plus O(log n) recursion depth. On a linked list the merge relinks nodes, so a bottom-up version needs only O(1) extra space. Merge sort is stable when ties are taken from the left half first.
3. Compare the alternatives. Quicksort averages O(n log n), but its worst case is O(n^2) with bad pivots (first-element pivot on sorted input); it sorts in place with O(log n) expected stack and is not stable. Heapsort guarantees O(n log n) with O(1) extra space but is unstable and less cache friendly. Insertion sort is O(n^2) in the worst case but O(n) on nearly sorted input, so hybrids use it for small subarrays.
4. Tie it to Java: Arrays.sort on primitives uses Dual-Pivot Quicksort, where stability does not matter. Arrays.sort on objects and Collections.sort use TimSort, which is stable, O(n log n) in the worst case and close to O(n) on input that is already mostly sorted.
5. Mention the limits. Comparison sorts need Omega(n log n) comparisons in the worst case. Counting sort (O(n + k)) or radix sort beats that for bounded integer keys. Data that does not fit in memory needs an external merge sort: sort chunks to disk, then do a k-way merge with a min-heap.

Follow-up

• Why does stability matter if you sort transactions by amount after sorting them by date?
• How would you sort a file of records far larger than available memory?
• Count the inversions in an array by modifying merge sort. What is the complexity?

How would you handle edge cases when implementing binary search?

Medium · Technical & DSA

Approach

1. Pick one interval convention and keep it. For a closed range [lo, hi], loop while lo <= hi and set hi = mid - 1. For a half-open range [lo, hi), loop while lo < hi and set hi = mid. Most off-by-one bugs and infinite loops come from mixing the two.
2. Compute the midpoint without overflow: mid = lo + (hi - lo) / 2, or (lo + hi) >>> 1 in Java. (lo + hi) / 2 overflows int when both are large.
3. Handle duplicates by writing lower bound (first index with a[i] >= target) and upper bound (first index with a[i] > target). First and last occurrence, counts and insertion points all follow from these. Note that Java's Arrays.binarySearch returns -(insertionPoint) - 1 when the key is missing and does not say which duplicate it finds.
4. Walk the edge inputs: an empty array, one element, a target below the minimum or above the maximum, and two elements. With two elements, a rounded-down mid plus lo = mid never moves, so make sure each branch shrinks the range.
5. Generalize to binary search on the answer. When a predicate is monotone over a range (minimum ship capacity for D days, integer square root), search for the first value where it becomes true, in O(log range) times the cost of checking the predicate.

Follow-up

• Search a rotated sorted array. What changes when it contains duplicates, and what is the worst case then?
• Compute the integer square root of a large int without overflow.
• Find the first bad version when each check is an expensive API call. How many calls do you make?

Explain the differences between SQL and NoSQL databases and when to use each.

Medium · System Design & Architecture

Approach

1. Relational databases enforce a schema and constraints (primary keys, foreign keys, unique) and offer joins and multi-row ACID transactions in SQL. They usually scale with bigger machines and read replicas, and sharding them is application work. They suit ledgers, orders and any data whose integrity rules matter.
2. Name the NoSQL families instead of treating them as one: key-value stores (Redis, DynamoDB) for lookups by key, document stores (MongoDB) for nested records read as a whole, wide-column stores (Cassandra) for high write volume with partitions designed around queries, and graph databases for traversing relationships.
3. State the real trade-off. Most NoSQL stores partition by key and scale horizontally, but you design tables around known access patterns and denormalize instead of joining. Many offer tunable or eventual consistency, though some now support transactions (MongoDB multi-document transactions, DynamoDB TransactWriteItems), so 'NoSQL means no ACID' is wrong.
4. Base the decision on access patterns, consistency requirements, data shape and scale, and say that many systems use both: a relational system of record with a cache, search index or document store beside it.
5. Back it with one concrete case. For a transactions table queried by account and date range, a composite index on (account_id, created_at) serves the query in a relational store. In a wide-column store the same query means account_id as the partition key and created_at as the clustering column.

Follow-up

• How would you model a customer and their many orders in a document store, and when would you embed rather than reference?
• What does CAP force you to choose during a network partition, and which side would you take for account balances?
• When would you denormalize inside a relational database, and what does it cost on writes?

Why do you want to join BNY specifically compared to other financial institutions?

Medium · Behavioral & Leadership

Approach

1. This is a motivation question filed with the technical ones, so answer it in three parts: the work that draws you, the experience of yours that fits it, and why this role over a similar one elsewhere.
2. Tie the answer to work candidates describe for this role: treasury services, cash processing and other financial platforms, API-driven services, cloud infrastructure, modernizing legacy mainframe systems, and Java full-stack work. Pick the one closest to what you have done and say so in the first person, for example: 'I have spent two years on Java services that replaced a batch system, and the legacy modernization work here is where I want to go deeper.'
3. Handle the comparison through the work and your own goals, not by ranking or criticising other institutions. Reciting size or stability fits any large bank and tells the listener nothing about you.
4. Have one specific point ready on why correctness and reliability in money-moving systems interest you, backed by an example such as a reconciliation bug, an idempotency fix or an audit requirement you met.
5. The answer fails when it is generic, centres on pay or prestige, or claims facts about the firm you cannot back up. Check every company detail you mention against public sources before the interview.

Follow-up

• What do you know about the team or platform you are interviewing for?
• Where else are you interviewing, and how would you choose between offers?
• What would you want to have shipped after your first year in this role?

How would you design a scalable system for processing high-volume financial transactions?

Medium · System Design & Architecture

Approach

1. Set the requirements first: what a transaction is (payment, transfer, posting), peak and average throughput, latency targets, and the hard rule that a retry must never move money twice. Ask for the volume instead of assuming one, and say the design keeps a full audit trail.
2. Write path: an API gateway in front of a transaction service that requires an idempotency key. Store the key under a unique constraint in the same database transaction as the posting, so a retry returns the original result. Hand accepted requests to a durable log such as Kafka, partitioned by account id so each account's events stay in order.
3. Model the ledger as append-only double-entry rows (every debit has a matching credit) in a relational database with ACID transactions. Update balances with row locks or optimistic version checks in the same transaction. Store amounts as integer minor units or BigDecimal, never as floating point.
4. For flows that cross services, avoid two-phase commit. Use a transactional outbox to publish events reliably, a saga with compensating entries for multi-step flows, and idempotent consumers that dedupe by event id because delivery is at least once.
5. Cover scale and failure: shard by account id and plan for hot accounts, replicate synchronously for durability, send poison messages to a dead-letter queue, alert on consumer lag, and run a reconciliation job that compares ledger totals with external statements.

Follow-up

• How do you move money between two accounts that live on different shards?
• A consumer writes to the database and then crashes before committing its offset. What happens, and how does the design stay correct?
• One merchant account receives a large share of all writes. How do you keep it from becoming the bottleneck?

What are the key considerations when migrating a legacy application to the cloud?

Medium · System Design & Architecture

Approach

1. Choose a strategy per component: rehost (lift and shift), replatform, refactor or re-architect, repurchase, retire or retain. Base the choice on business value, how tightly coupled the component is and how much risk is acceptable, not one rule for the whole estate.
2. Start with discovery: list every dependency, including databases, batch jobs, file transfers, hard-coded hosts and IPs, shared filesystems and in-memory session state. Record the non-functional requirements: latency to systems that stay on-premises, data residency, encryption and compliance controls.
3. Migrate incrementally with the strangler fig pattern. A facade or proxy routes each feature to the old or new implementation, an anti-corruption layer keeps the legacy model from leaking into new services, and running both in parallel lets you compare their outputs before cutover.
4. Plan the data move: an initial bulk load, then change data capture to keep the target in sync, reconciliation by row counts and checksums, and a cutover runbook with a tested rollback path.
5. Set up operations before go-live: IAM with least privilege, private connectivity back to on-premises, secrets in a managed vault, infrastructure as code, logs, metrics and traces, and a stateless app tier so autoscaling works. Track cost, because a lift and shift often costs more until the app is right-sized.

Follow-up

• How do you migrate a large relational database with minimal downtime?
• How do you prove the migrated system produces the same results as the legacy one?
• Which components would you leave on-premises, and how do they talk to the cloud side securely?

How do you ensure API security in a distributed system?

Medium · System Design & Architecture

Approach

1. Authenticate every call. Users come in through OAuth 2.0 / OpenID Connect with short-lived JWT access tokens, and each service checks the signature, issuer, audience and expiry. Services authenticate each other with mTLS or the OAuth client-credentials grant, and nothing is trusted just because it is on the internal network.
2. Authorize at the object level on every request: check that the caller may act on this specific account or record, not just that they hold a valid token. Broken object-level authorization is the first item in the OWASP API Security Top 10. Use narrow scopes and least privilege per service.
3. Protect data and inputs: TLS everywhere, encryption at rest, secrets in a vault with rotation rather than in code or config, strict schema validation, bind parameters in SQL to block injection, and responses limited to the fields the client needs.
4. Limit abuse: rate limiting at the gateway (token bucket per client), HMAC request signing with a timestamp and nonce to reject replays, idempotency keys on money-moving endpoints, and audit logs with correlation ids that never contain tokens or account numbers.
5. Name the trade-off. Stateless JWT validation is fast but hard to revoke, so pair short expiry with refresh tokens, or use token introspection or a deny-list for high-risk operations.

Follow-up

• How do you revoke a JWT before it expires?
• How do you rotate a token-signing key without breaking clients that are mid-session?
• An internal service is compromised. What limits how far the attacker can reach?

Edge instances grow 400 MB per hour until the nightly restart

Hard · memory leak · heap analysis · metric cardinality

Edge API instances start at 700 MB resident and grow about 400 MB/hour; a nightly rolling restart has hidden it for weeks. Growth continues unchanged when request rate halves overnight, p99 degrades in the last hours before an instance is recycled, and heap used immediately after a forced full GC rises monotonically. The service holds no product state. Name the discriminating measurement that separates the plausible causes, give the most likely cause, and give the fix and how you would verify it.

Approach

1. Separate resident memory from live heap first, because they fail differently. Resident size can grow from fragmentation, native buffers or thread stacks while the heap is flat; heap used after a full GC rising monotonically is the measurement that says objects are reachable and not being released. You already have it, so this is retention, not fragmentation, and that closes off half the candidate list.
2. Use the rate's independence from traffic as the discriminator. Growth that continues at half the request rate rules out per-request objects that are merely slow to collect and points at a structure that grows with distinct values observed rather than with call volume. Write the candidates that have that property: a metrics registry keyed on a high-cardinality label, an unevicted cache, an interner, a per-key lock map.
3. Take two heap snapshots an hour apart and diff by retained size, reading the dominator tree, not by allocation count or instance count. Expect one root holding a map with millions of entries, then follow the reference chain to the code that inserts and never removes. Allocation profilers point at churn, which is the wrong signal here.
4. The candidate that fits this service is an observability label carrying an identifier, such as a request path recorded before templating so that /v1/resources/48213 becomes its own metric series. That grows with distinct ids seen, is independent of rate, and explains the late p99 degradation, since GC cost rises with the size of the live set.

Follow-up

• Post-GC heap is now flat but resident size still creeps. What are you looking at, and does it matter?
• How would you have detected this before an OOM, given the nightly restart masked the trend?

Suggested practice checklist

The plan follows the reported loop: algorithm fundamentals first, then trees, graphs and DP, then design and projects, and the behavioral round last. Each day has a concrete output so you can see what is left.

Day 1 — Map the loop and audit your resume

• Write the three reported stages and the team variance (algorithm-heavy versus project-heavy) on one page, and mark where you are weakest.
• For each project on your resume, write its architecture, schema, one trade-off, one hard bug and one measurable result; delete anything you cannot defend.

Deliverable: A one-page loop map and a fact sheet for your two strongest projects.

Day 2 — Arrays, lists, sorting and binary search

• Write a comparison of arrays and linked lists covering memory layout, cache behaviour, insertion and lookup cost, and Java's ArrayList versus LinkedList.
• Implement merge sort in Java and write its time and space complexity, stability and why it is O(n log n).
• Implement binary search plus first-occurrence and insertion-point variants, and test empty, single, absent, duplicate and large-index cases.

Deliverable: A one-page array versus linked-list comparison, a merge sort file and a binary search file with a table of edge-case tests.

Day 3 — Trees and graphs

• Write pre-order, in-order and post-order traversals recursively and iteratively with a stack, plus level order.
• Implement directed-graph cycle detection two ways (three-colour DFS and Kahn's algorithm), then BFS and Dijkstra shortest paths.

Deliverable: A Java file with the traversals and graph routines, each with a test and a complexity comment.

Day 4 — Sliding window and dynamic programming

• Solve two sliding-window problems, one fixed-size and one variable-size, and say what the window invariant is.
• Solve the longest palindromic substring problem with expand-around-centre and with a DP table.
• Rewrite one DP solution top-down with memoization and bottom-up, and state time and space for each.

Deliverable: Four timed solutions, each with its invariant or recurrence and its complexity written beside it.

Day 5 — System design and the data layer

• Outline a high-volume transaction pipeline with idempotency, a durable log, partitioning, a ledger store and reconciliation.
• Build a SQL versus NoSQL table of workloads, consistency needs and query shapes with a pick for each.
• Write a migration plan for a legacy application going to the cloud (inventory, dependencies, data move, cutover, rollback), and an API security checklist (authentication, authorization, rate limits, transport encryption, input validation, secrets).

Deliverable: A design outline, a data-store comparison table, a migration plan and a security checklist.

Day 6 — Project deep dive and fundamentals

• Narrate each resume project aloud, including a schema walk-through and the choice of stack over alternatives.
• Review one sheet each for OS, DBMS and networking.

Deliverable: Two recorded project walkthroughs, a debugging narrative and a one-page fundamentals sheet.

Day 7 — Behavioral stories and a mixed rehearsal

• Write structured outlines for the disagreement, new-technology and tight-deadline stories, and a paragraph answering why BNY compared to other financial institutions.
• Run a mixed rehearsal: one coding problem, one design question and one story back to back.
• Check your IDE, compiler and screen sharing, and prepare questions about the team's focus.

Deliverable: Three story outlines, a why-BNY paragraph and notes from the mixed rehearsal.

Behavioural preparation

Candidates describe the final stage as a behavioral or managerial round with attention to stability and an understanding of the financial domain, and they say project discussion carries into it. For a software role, your stories should show a decision you owned, the trade-off you weighed and the result.

1. Why do you want to join BNY specifically compared to other financial institutions?
2. What was the most difficult bug you encountered in this project and how did you debug it?
3. Walk me through the database schema you designed for your final project.

Tell me about a time you faced a disagreement within your team. How did you resolve it?

Medium · Behavioral & Leadership

Approach

1. Choose a disagreement with real technical stakes, such as an API shape, a schema, a rollout plan or a library choice, where you owned part of the outcome. State both positions fairly, including the strongest argument for the other side.
2. Spend most of the answer on how it was resolved: the evidence you gathered (a benchmark, a prototype, production data, a review of failure cases), who made the final call and how you kept working with that person.
3. Show your own movement: say what you conceded or changed, or what you would concede in hindsight. A story in which you were simply right reads as one-sided.
4. Close with the result and one concrete consequence, and say how the team decides such questions differently afterwards.
5. The mistake that sinks it is making escalation to a manager the resolution, or casting the colleague as the problem.

Follow-up

• What would you have done if the other person still disagreed after seeing the evidence?
• Would you make the same call today, and what would change your mind?
• How did your working relationship with that colleague change afterwards?

Describe a project where you had to learn a new technology on the fly.

Medium · Behavioral & Leadership

Approach

1. Pick a technology that is on your resume or close to the stack candidates describe (a Java framework, a SQL feature, a cloud service, Angular). Name it, say what the project needed from it, and describe the time pressure in a sentence or two.
2. Describe your learning loop concretely: what you read first, the small throwaway spike you built to test assumptions, who you asked, and how you compared your first version with the existing system.
3. Include a mistake you made while learning and how you caught it (code review, a failing test, staging). It shows how you contain the cost of learning on the job.
4. State what you shipped and the level you reached, and be honest about what you still did not know, because the project may be deep-dived next.
5. The mistake that sinks it is saying you are a fast learner without naming the technology, the method or the result.

Follow-up

• How did you decide what to learn first and what to skip?
• How did you know your first working version was correct?
• How would you teach that technology to a new teammate today?

How do you handle situations where you are under pressure to meet a tight deadline?

Medium · Behavioral & Leadership

Approach

1. Set up the situation briefly: what caused the deadline pressure and what was fixed (date, scope, people). Keep it to two sentences.
2. Show triage: list the work, separate must-ship from deferrable, and put the options in front of the stakeholder (a product manager or operations colleague) early instead of absorbing the problem quietly.
3. Name the checks you refused to drop, such as tests on the data-correctness path, code review and a rollback plan, and what you cut instead. This matters for systems where precision and reliability are expected.
4. Report the result honestly: what shipped on time, what moved, the follow-up tickets for deferred work, and what you changed to avoid a repeat.
5. The mistake that sinks it is making late-night heroics the whole story, or hiding shortcuts you took.

Follow-up

• What would you have cut next if the date had moved up again?
• How did you tell stakeholders the scope was reduced, and how did they react?
• Tell me about a deadline you missed, and what you did next.