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.
Online Assessment
reportedCandidates 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
reportedCandidates 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. PracHub's practice question on instances that keep growing in memory is a good drill for the debugging narrative.
- Make a one-page sheet for OS (process versus thread, deadlock), DBMS (ACID, indexes, isolation levels) and networks (TCP, HTTP, TLS).
Behavioral Interview
reportedCandidates 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.
PracHub editorial advice for the preparation topics above.
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.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Explain the difference between arrays and linked lists in terms of memory and performance.
Explain the difference between arrays and linked lists in terms of memory and performance.
Approach
- 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).
- 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.
- 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 holds references to boxed Integers, so the values themselves are not contiguous; only primitive arrays are.
- 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.
- 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?
How do you implement in-order, pre-order, and post-order traversals in binary trees?
Approach
- 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).
- 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.
- 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.
- 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.
- 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.
Write a program to solve a sliding window problem or a dynamic programming challenge.
Approach
- 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.
- 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.
- 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).
- 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.
- 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.
Explain the time and space complexity of sorting algorithms like merge sort.
Approach
- 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.
- 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.
- 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.
- 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.
- 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?
How would you handle edge cases when implementing binary search?
Approach
- 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.
- 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.
- 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.
- 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.
- 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.
Explain the differences between SQL and NoSQL databases and when to use each.
Approach
- 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.
- 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.
- 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.
- 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.
- 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?
Why do you want to join BNY specifically compared to other financial institutions?
Approach
- 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.
- 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.'
- 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.
- 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.
- 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?
How would you design a scalable system for processing high-volume financial transactions?
Approach
- 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.
- 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.
- 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.
- 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.
- 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?
What are the key considerations when migrating a legacy application to the cloud?
Approach
- 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.
- 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.
- 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.
- 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.
- 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?
How do you ensure API security in a distributed system?
Approach
- 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.
- 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.
- 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.
- 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.
- 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
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
- 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.
- 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.
- 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.
- 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?
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.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Map 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.
02Arrays, 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.
Practice prompt ↗Practice prompt ↗Practice prompt ↗03Trees 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.
Practice prompt ↗04Sliding 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.
Practice prompt ↗05System 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.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗06Project deep dive and fundamentals
- Narrate each resume project aloud, including a schema walk-through and the choice of stack over alternatives.
- Practise the hardest-bug story using PracHub's practice question on instances growing in memory to rehearse the debugging method.
- Review one sheet each for OS, DBMS and networking.
Deliverable: Two recorded project walkthroughs, a debugging narrative and a one-page fundamentals sheet.
Practice prompt ↗07Behavioral 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.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
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.
Tell me about a time you faced a disagreement within your team. How did you resolve it?
Tell me about a time you faced a disagreement within your team. How did you resolve it?
Approach
- 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.
- 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.
- 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.
- Close with the result and one concrete consequence, and say how the team decides such questions differently afterwards.
- 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.
Describe a project where you had to learn a new technology on the fly.
Approach
- 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.
- 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.
- 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.
- 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.
- 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?
How do you handle situations where you are under pressure to meet a tight deadline?
Approach
- Set up the situation briefly: what caused the deadline pressure and what was fixed (date, scope, people). Keep it to two sentences.
- 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.
- 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.
- 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.
- 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.
- 01
Tell me about a time you faced a disagreement within your team. How did you resolve it?
- 02
Describe a project where you had to learn a new technology on the fly.
- 03
How do you handle situations where you are under pressure to meet a tight deadline?
- 04
Why do you want to join BNY specifically compared to other financial institutions?
- 05
What was the most difficult bug you encountered in this project and how did you debug it?
- 06
Walk me through the database schema you designed for your final project.
How many rounds are there and how long does the process take?
Candidates report three stages over roughly 3-5 weeks: an Online Assessment, two to three technical interviews, and a final behavioral or managerial round. Teams and regions differ, and the timeline can stretch, so follow up politely and keep preparing.
PracHub Software Engineer practice ↗What should I practise for the online assessment?
The reported format is a technical filter without further detail. Candidates who prepared for it recommend graph, dynamic programming, array and string problems. Practise those in Java or your strongest language, under a timer, with your own edge-case tests.
PracHub Software Engineer practice ↗Which languages and technologies matter?
Candidates describe Java or another object-oriented language, data structures and algorithms, and SQL with relational databases as the core. Cloud platforms (AWS or Azure), Angular or a modern front-end framework, and system design exposure are described as additional strengths.
PracHub Software Engineer practice ↗How much of the interview is about my own projects?
Candidates report project deep dives, and some teams focus on them heavily. Prepare each resume project's architecture, schema, the reason for the stack, one hard bug and one measurable result, and drop anything you cannot explain.
PracHub Software Engineer practice ↗Do OS, DBMS and networking questions come up?
Candidates say they do. Review process versus thread and deadlock, ACID, indexes and isolation levels, and the basics of TCP, HTTP and TLS, and connect them to your projects where you can.
PracHub Software Engineer practice ↗Do I need finance experience?
Candidates describe it as not strictly required, but a baseline understanding of how financial institutions use technology helps in the behavioral round. Learn payment flows, settlement and reconciliation in plain words, and link them to a design answer on financial transactions.
PracHub Software Engineer practice ↗What if the call runs informally or something fails technically?
Candidates say some interviewers join late or run an informal session. Stay professional, and check your IDE, compiler and screen sharing beforehand so a technical glitch is a minor interruption.
PracHub Software Engineer practice ↗Sources & methodology 3 sources ↗
No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.
- 01BNY Software Engineer candidate reports ↗
Company-reported rounds, questions and FAQ.
Candidate reports · Accessed 2026-09-22 - 02PracHub Software Engineer practice ↗
PracHub practice material, not company-reported.
PracHub page · Accessed 2026-09-22 - 03PracHub preparation framework ↗
PracHub preparation guidance.
PracHub page · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
Vercel Software Engineer Interview Guide
Debugging practice for Vercel software engineer prep built on a reproduction you trust, narrowing to the smallest failing input, and changing one variable per run so the result stays attributable.
CoreWeave Software Engineer Interview Guide
Failure-handling practice for CoreWeave software engineer candidates: requests whose outcome a timeout leaves unknown, where a retry is safe, and deduplicating at the receiver instead of assuming exactly-once delivery.
Confluent Software Engineer Interview Guide
Concurrency exercises for Confluent candidates: check-then-act races, deadlock from inconsistent lock ordering, and why two individually atomic operations do not compose into an atomic update.
Capital One Software Engineer Interview Guide
Code-reading and review practice for Capital One candidates: tracing unfamiliar control flow, finding the invariant a function quietly depends on, and separating a correctness defect from a matter of taste.