Interview guides · City National Bank

City National Bank Software Engineer Interview Guide

City National Bank Software Engineer interview guide: four reported rounds, OOP, SOLID, atomic transfers and SQL tuning, behavioral stories, 7-day plan.

The 60-second brief

City National Bank is a bank that candidates see described as offering banking, investment and trust services under the tagline "The Way Up". The Software Engineer role is described as building and maintaining the applications behind those services: client-facing portals, internal wealth management tools and core banking APIs. Candidates report that the work touches data integrity, real-time processing and regulatory compliance, which is why the reported questions keep returning to correctness (atomic transfers, exception handling, query performance) rather than to puzzle-style coding.

This guide is for candidates interviewing for a Software Engineer position at City National Bank. The requirements candidates describe name Java, C# or Python, SQL and relational design, RESTful APIs, OOP and data structures and algorithms, with microservices, Azure or AWS, and fintech experience listed as extras. The guide covers the four reported rounds, all fourteen reported questions (OOP, memory, design, SQL and behavioral), a seven-day plan, and a bank of behavioral prompts.

Candidates report four stages over about 3-5 weeks: a Recruiter Screen, Technical Assessments, Behavioral Assessments and a Final Round that runs as a long virtual session mixing technical discussion and team dynamics.

Focus areas

Object-Oriented Programming (OOP)
Software Design Fundamentals
Design Patterns

Overview

The reported questions are fundamentals, not trick puzzles. They ask for the four pillars of OOP with a real-world example each, polymorphism, SOLID, stack versus heap, exception handling, the first three steps of a project built from scratch, and what a computer can and cannot do. Candidates also report two applied questions with a banking flavour: designing a bank transfer that either happens completely or not at all, and walking through the optimization of a slow database query. The preparation consequence is depth over breadth. A one-line definition is not enough for any of these; each needs a concrete example in the language you will use, ideally drawn from accounts, payments or loans.

The evaluation areas candidates describe are object-oriented programming, software design fundamentals, design patterns (Singleton, Factory, Observer and Strategy are named), testing strategy, Git and CI/CD, and the end-to-end ability to program a project. Reported example scenarios include choosing between an abstract class and an interface in a banking application, using a pattern to handle different kinds of loan calculation, walking through the lifecycle of a project you led, and keeping code fast over large sets of financial transactions. Practise saying why you chose a structure, not just what it is.

The loop is long. Candidates report about 3-5 weeks across four rounds, and the final round is described as a 3-4 hour virtual experience covering technical discussion and team dynamics. That means you need technical answers that hold up under extended conversation and a behavioral story bank deep enough not to repeat itself. Candidates also advise a professional tone, the STAR structure for behavioral answers, and mentioning unit testing and documentation when you discuss code. Banking knowledge is reported as a plus rather than a requirement, so spend your time on engineering fundamentals first.

The City National Bank interview process

Candidates describe four stages spread over about 3-5 weeks. Treat the order and content as reported and confirm the details with your recruiter.

Recruiter Screen

Candidates describe this as an opening conversation with a recruiter to align on expectations and on your interest in the role. Use it to get the loop's practical details in writing (format of each later round, what the final virtual session involves) and to check location and hybrid expectations, which candidates say vary by team and office. Have a short, factual summary of your background mapped to the stack the role lists: Java, C# or Python, SQL, RESTful APIs.

What to demonstrate

Alignment between your expectations and the role
Interest in the position and in working at a bank
How clearly you summarise your experience against the listed stack

How to prepare

Write a short walkthrough of your background that names the language and database work most relevant to Java, C# or Python, SQL and REST APIs.
Prepare a specific answer to why you want to work for a financial institution like City National Bank, tied to correctness and reliability work you have actually done.
List questions for the recruiter: what each later round covers, the format of the final virtual session, and hybrid expectations for the office.

Technical Assessments

Candidates report a series of technical assessments covering fundamental engineering knowledge and problem-solving ability, rather than whiteboard riddles. The reported question types in this guide are OOP and SOLID, memory (stack versus heap), exception handling, designing an atomic bank transfer, optimizing a slow query, and the first steps of building a project from scratch. Approach it by giving definitions briefly and spending your time on concrete examples, trade-offs and what you would test.

What to demonstrate

Fundamental engineering knowledge, including OOP and design principles
Problem-solving: breaking a requirement into components and explaining the reasoning
Ability to explain technical ideas clearly and from first principles

How to prepare

Build a small account and loan-calculator example in your main language that shows encapsulation, inheritance, abstraction and polymorphism, and that you can extend live.
Write a SOLID before-and-after for each principle and one use case plus one drawback for Singleton, Factory, Observer and Strategy.
Practise the atomic transfer and slow query questions end to end with real SQL: a single transaction with ordered locks, then reading a query plan and fixing it.
Be able to explain stack frames, heap allocation and reference versus value in the language you chose.

Behavioral Assessments

Candidates describe behavioral interviews about collaboration, teamwork and cultural fit. Reported themes are working in a Scrum or Agile team, proceeding when requirements are ambiguous, and resolving technical disagreements. Reported sample prompts include working with a difficult team member to deliver on time and what you expect from a manager and a lead engineer. Candidates advise the STAR structure, so prepare stories in which you made the decision and can name the result.

What to demonstrate

Collaboration and teamwork in an Agile setting
Handling ambiguity and conflict
Cultural fit with a professional team environment

How to prepare

Write four STAR stories: learning a technology fast, pushing back on a flawed feature, resolving a disagreement with a peer, and working through unclear requirements.
Prepare the answers to the ideal team environment, staying current in the field and why a bank questions.
Rehearse each story aloud so the situation takes two sentences and the rest covers your decision, the trade-off and the measurable result.

Final Round

Candidates describe the final round as a 3-4 hour virtual experience focused on technical discussions and team dynamics, so expect it to blend the earlier technical and behavioral material over an extended session. Prepare as for both earlier stages together: technical topics you can discuss at depth (design of a transfer system, project setup, testing, CI/CD) and stories about collaboration. Candidates also suggest asking about technical debt and cloud adoption, and keeping a professional tone throughout.

What to demonstrate

Depth of technical discussion over a long session
Team dynamics and how you work with others
Consistency between your technical answers and your described experience

How to prepare

Run a mock block that alternates a technical walkthrough (atomic transfer design, a project from scratch) with behavioral questions, and note where your answers lose precision as it goes on.
Set up your environment beforehand: a quiet space, a stable connection, a working camera and microphone, and water and notes within reach.
Prepare two or three questions about how the team handles technical debt and how it is adopting cloud technologies.

Where candidates lose points

Reciting the four pillars of OOP as definitions with no example, or using only animal or shape examples.

Prepare one banking example per pillar: encapsulation with an Account whose balance changes only through methods that enforce rules, inheritance with savings and checking accounts (and say when you would prefer composition), abstraction with a payment method interface, polymorphism with interchangeable loan calculators.

Answering the atomic bank transfer question with "use a database transaction" and stopping there.

Cover the debit and credit in one transaction, ordering the account locks to avoid deadlock, an idempotency key so a retry does not move money twice, and what changes when the two accounts live in different systems (outbox or saga with compensation).

Optimizing a slow query by saying "add an index" before reading anything.

Start with the execution plan, compare estimated to actual rows, check for functions on indexed columns, SELECT *, missing join conditions and repeated queries from application code, then change one thing and re-measure.

Telling behavioral stories in the first person plural with no decision of yours and no result.

Pick a moment where you chose between options, say what you decided and why, and finish with an outcome you can measure. Prepare stories for learning fast, disagreeing with a flawed feature and working in a team.

Giving a generic answer to why you want to work at a bank, built on brand and stability.

Tie your reasons to correctness work you have done and to what candidates report about the bank's services and client segments, and say what you would need to learn about the financial domain.

Questions & practice

What is the difference between a Stack and a Heap in memory management?

Medium · Core CS & OOP Fundamentals

Approach

Stack: one per thread, a LIFO set of frames holding parameters, return addresses and local variables; allocation is a pointer move, and memory is released automatically when the function returns.
Heap: a shared region for data whose size or lifetime is not tied to one call; allocation is slower, and it is freed explicitly (C/C++ free/delete), by garbage collection (Java, C#) or by reference counting plus a cycle collector (CPython).
Tie it to your language: in Java, objects live on the heap and a local holds a reference on the stack (the JIT may avoid heap allocation via escape analysis); in C#, value-type locals sit on the stack unless boxed, captured or stored in a class field.
Give the failure modes: deep or unbounded recursion overflows the fixed-size stack (StackOverflowError in Java), while the heap suffers leaks, fragmentation, GC pauses and OutOfMemoryError.
Cover threads: stack data is private to its thread, heap objects are visible to every thread holding a reference, so shared mutable heap state is where synchronization matters.

Follow-up

Can a garbage-collected program still leak memory? Give an example.
Why does a deeply recursive function fail when the iterative version does not, and how would you convert it?
Where does a string or a boxed integer live in your main language, and why does that matter for performance?

What can a computer do, and what are its fundamental limitations?

Medium · Logic & Problem Solving

Approach

Answer from first principles: a computer executes a finite sequence of simple instructions (arithmetic, comparison, branching, memory reads and writes) very fast and deterministically; everything else is built from those.
Theoretical limit: some problems are undecidable, so no program can solve them for every input; the halting problem is the standard example, and Rice's theorem extends it to any non-trivial question about a program's behaviour.
Practical limit: tractability. Problems with no known polynomial-time algorithm (NP-hard ones such as the travelling salesman problem) become infeasible as input grows, so real systems use heuristics or approximations.
Physical limits: finite memory and finite precision. Binary floating point cannot represent 0.1 exactly, which is why money is stored as integer minor units or a decimal type; integers overflow at fixed width.
Finish with what a computer cannot supply: correct requirements and judgement. It does exactly what it was told, so a wrong specification produces a fast, consistent wrong answer.

Follow-up

Why should a balance never be stored as a double, and what would you use instead?
Explain the halting problem to a non-technical stakeholder in two sentences.
What does it mean for a problem to be NP-hard, and how do engineers handle one in practice?

If you were asked to program a project from scratch, what are the first three steps you would take?

Medium · Logic & Problem Solving

Approach

Step one, requirements: who the users are, the core use cases, acceptance criteria, and the non-functional constraints (security, audit trail, data retention, expected load) written down and confirmed with the product owner before any code.
Step two, design: sketch the domain model and data model, the API contracts between components, and the technology choices, with the reason for each; keep it small enough to change.
Step three, a walking skeleton: create the Git repository and branching convention, a CI pipeline that builds and runs unit tests on every push, and one thin feature deployed end to end so integration problems surface on day one.
State the trade-off: too much up-front design delays feedback, too little produces rework; a thin end-to-end slice validates the design cheaply.
Mention the edge cases you plan for early: authentication and authorization, error handling and logging conventions, configuration and secrets kept out of the repository.

Follow-up

The requirements are vague and the stakeholder is unavailable. What do you build first?
How would you decide between a monolith and microservices for this project?
What goes into your CI pipeline before the first feature ships?

Walk me through how you would optimize a slow-running database query.

Medium · Logic & Problem Solving

Approach

Measure before changing anything: get the actual plan with EXPLAIN ANALYZE (Postgres; SET STATISTICS IO or the actual execution plan in SQL Server) and find the node where time and rows concentrate.
Read the plan for the usual causes: a sequential scan on a large table behind a selective filter, estimated rows far from actual rows (stale statistics, fixed by ANALYZE or UPDATE STATISTICS), or a nested loop running over many outer rows.
Fix the access path: add or reorder a composite index with equality columns first and the range or sort column last, and make predicates sargable; WHERE YEAR(created_at) = 2025, a leading-wildcard LIKE '%abc' or an implicit type conversion each stop an ordinary index from being used.
Fix the query shape: select only needed columns (enabling a covering index), replace OFFSET pagination on deep pages with keyset pagination, and remove N+1 patterns from the ORM by batching or joining.
State the trade-offs and confirm the result: every index slows inserts and updates and uses storage, so re-run the plan with realistic data volumes and bind parameters to confirm the gain before shipping.

Follow-up

The query is fast in testing but slow in production. What would you compare first?
Your new index made the read fast but the nightly batch load slower. How do you decide?
Why might the optimizer ignore an index that exists on the filtered column?

Denormalise tenant onto revisions and backfill it live

Hard · denormalisation · online migration · backfill

resource_revision (revision_id, resource_id, version, actor_user_id, change_kind, patch, request_id, created_at) has 400M rows and no tenant column; tenant_id lives only on resource. Two reads need it: a tenant-scoped audit feed ordered by created_at DESC, and an offboarding purge. Both join back to resource today. Justify adding tenant_id to resource_revision against those two reads, name the anomaly the copy introduces and the constraint that prevents it, then give the ordered migration for a live table taking 1.2k writes/second — the lock each step takes, how the backfill is batched, and where each step stops being reversible. PostgreSQL 16.

Approach

Justify from the access path rather than from taste. Without the column, the audit feed either scans resource_revision by created_at and discards other tenants' rows, or resolves the tenant's resource_ids first and probes with them — both proportional to the tenant's whole history rather than to one page. With (tenant_id, created_at DESC, revision_id DESC) it is a seek that stops at 50 rows, and the purge becomes a ranged delete instead of a join.
Name the cost exactly: a second copy of a fact can disagree with the first. Make the disagreement unwritable rather than documented — add UNIQUE (resource_id, tenant_id) on resource so it can serve as a foreign-key target, then FOREIGN KEY (resource_id, tenant_id) REFERENCES resource (resource_id, tenant_id) on the revision table. A revision can then only ever carry its parent's tenant.
Step one, expand: ALTER TABLE resource_revision ADD COLUMN tenant_id BIGINT NULL, with no default, so it is a catalogue change and no rewrite. It still needs ACCESS EXCLUSIVE for an instant, and that instant queues behind the longest open transaction on the table while every later query queues behind it — set lock_timeout to 2s and retry rather than wait.
Step two, dual-write: deploy the writer that populates tenant_id on every new revision while reads still use the join. Reversible by redeploying the previous build, because nothing reads the column yet.

Follow-up

The backfill is half finished and a rollback is required. What state is the table in, and what does the previous build do with a half-populated column?
How do you verify the backfill actually finished, given rows are still being inserted while it runs?

What are the four pillars of OOP, and can you provide a real-world example of each?

Medium · Core CS & OOP Fundamentals

Approach

Define each pillar in one line before giving its example: encapsulation hides state behind methods, abstraction exposes what an object does rather than how, inheritance reuses and specialises a base type, polymorphism lets one call dispatch to different implementations.
Use one running domain so the examples connect: an Account class keeps balance private and changes it only through deposit() and withdraw(), which reject negative amounts or overdrafts (encapsulation).
Abstraction: a PaymentGateway interface with a charge() method lets callers stay unaware of which processor or protocol sits behind it. Inheritance: SavingsAccount extends Account and adds an interest rule.
Polymorphism: a list of Account references where calling monthlyFee() runs the SavingsAccount or CheckingAccount override, picked at runtime from the object's actual type.
Close with the trade-off: deep inheritance trees couple subclasses to base-class internals, so state that you often prefer composition (an Account holding a FeePolicy) once the hierarchy goes past one or two levels.

Follow-up

What is the difference between an abstract class and an interface, and which would you pick for the account types?
When would you choose composition over inheritance, and what does it cost you?
How is encapsulation different from abstraction, since both hide something?

Explain the concept of Polymorphism and how it improves code flexibility.

Medium · Core CS & OOP Fundamentals

Approach

Define it as one interface, many implementations: the caller codes against a type, and the concrete behaviour is chosen by the object it receives.
Separate the kinds: runtime (subtype) polymorphism through method overriding and dynamic dispatch, compile-time polymorphism through overloading, and parametric polymorphism through generics such as List<T>.
Show the flexibility with a before and after: a switch on loanType inside calculatePayment() becomes a LoanCalculator interface with one class per loan type, so adding a loan type means a new class instead of editing tested code (the open/closed principle).
Mention how dispatch works in Java or C#: overridden instance methods resolve through the object's runtime class (a vtable in most implementations); in C# a method must be marked virtual and overridden with override, otherwise 'new' only hides it.
Name the limits: static methods and fields are not overridden (they are hidden), and overload choice is made from the declared argument types at compile time, not the runtime types.

Follow-up

Is method overloading really polymorphism? How is it resolved compared with overriding?
What goes wrong if a base-class constructor calls a method that a subclass overrides?
How would you add a new loan type without modifying the existing calculators?

Describe the SOLID principles and why they are important for long-term projects.

Medium · Core CS & OOP Fundamentals

Approach

Single responsibility: a class has one reason to change. Example: a TransferService that validates, moves money and sends emails is split so notification changes do not touch transfer logic.
Open/closed: extend behaviour without editing tested code, for example a new loan type added as a new LoanCalculator implementation rather than another branch in a switch.
Liskov substitution: a subtype must work wherever its base type is expected; a FixedDepositAccount that throws on withdraw() breaks callers of Account, a sign the hierarchy is wrong.
Interface segregation and dependency inversion: keep interfaces small (a reader does not implement write methods), and have high-level code depend on abstractions such as an AccountRepository interface injected through the constructor, which also makes unit tests with fakes possible.
Explain the long-term payoff and the cost: changes stay local and testable over years, but applying every principle up front produces needless interfaces; introduce the abstraction when a second implementation or a test needs it.

Follow-up

Give an example of a Liskov violation you have seen or written, and how you fixed it.
How does dependency inversion differ from dependency injection?
When does following SOLID make a codebase worse?

How would you design a system to ensure that a bank transfer is "atomic" (either it happens completely or not

Medium · Logic & Problem Solving

How would you design a system to ensure that a bank transfer is "atomic" (either it happens completely or not at all)?

Approach

Inside one relational database, wrap both legs in a single transaction: BEGIN; debit with UPDATE accounts SET balance = balance - :amt WHERE id = :src AND balance >= :amt, check that exactly one row changed, credit the destination, write the ledger rows, COMMIT; any failure rolls everything back.
Prevent concurrency bugs: lock both rows with SELECT ... FOR UPDATE in a fixed order (lower account id first) so two opposite transfers cannot deadlock, or rely on the conditional UPDATE plus an adequate isolation level.
Record money as a double-entry ledger with integer minor units or DECIMAL, where each transfer writes a debit and a credit that sum to zero, so balances can be rebuilt and audited.
Make retries safe with an idempotency key stored under a unique constraint; a client that times out and resends the same request gets the original result instead of a second transfer.
When the accounts live in different services or databases, a local transaction is not enough: compare two-phase commit (atomic but blocks if the coordinator fails) with a saga using compensating actions plus a transactional outbox, which gives eventual consistency.

Follow-up

The database commits but the response to the client is lost. What happens when the client retries?
How would you handle a transfer between two banks or two services that cannot share a transaction?
Which isolation level do you need, and what anomaly could occur under read committed?

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

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?

Suggested practice checklist

The plan follows the reported loop: fundamentals and design first, then memory, exceptions and the applied transfer and SQL questions, then project setup, then behavioral stories and a long mock session for the final round.

Day 1 — Map the loop and choose your language

Write the four reported rounds (Recruiter Screen, Technical Assessments, Behavioral Assessments, Final Round) and mark the one you are least ready for.
Pick Java, C# or Python as your interview language and list how it expresses classes, interfaces, abstract classes, generics and exceptions.
Write a short summary of your background aimed at the recruiter screen and a list of questions about the later rounds and the final virtual session.

Deliverable: A one-page loop map, a language feature sheet, and a written recruiter-screen summary with your questions.

Day 2 — OOP pillars and polymorphism with banking examples

Code an Account hierarchy that demonstrates encapsulation, inheritance, abstraction and polymorphism, and explain each pillar aloud using it.
Implement a loan calculator interface with fixed, variable and interest-only strategies, then add a new type without editing the existing ones.
Write when you would choose an abstract class and when an interface for a banking application.

Deliverable: Runnable Account and loan calculator code plus a spoken answer for the four pillars and for polymorphism.

Day 3 — SOLID and design patterns

For each SOLID principle, write a short violation in your language, then refactor it and say what became easier to change.
Write one realistic use case and one drawback for Singleton, Factory, Observer and Strategy.
Explain how SOLID helps a long-lived system and how it helps unit tests.

Deliverable: Five before-and-after refactors and a four-pattern table with use case and drawback.

Day 4 — Memory, exceptions and first principles

Explain stack versus heap in your language: stack frames, heap objects, garbage collection or ownership, recursion depth and value versus reference types.
Write an exception policy for a transfer REST endpoint: what you catch, what you wrap, which status codes you return, what you log, and when you roll back.
Prepare a first-principles answer to what a computer can and cannot do, including finite memory, floating-point rounding for money and problems that cannot be decided.

Deliverable: A memory explanation, a written exception policy for the transfer endpoint, a first-principles answer, and a debugging notes page.

Day 5 — Atomic transfers and slow queries

Write a schema for accounts, ledger entries and idempotency keys, then SQL for a transfer in one transaction with locks taken in a consistent order.
Add a retry story: duplicate request, timeout after commit, and how the idempotency key makes it safe.
Take a slow query, read its execution plan, and fix it by changing the predicate, the join or the index, measuring before and after.

Deliverable: A transfer schema and SQL, a failure-mode table, a query-tuning log with before and after numbers, and notes on the backfill exercise.

Day 6 — Starting a project from scratch

Write the first three steps you would take on a new accounts REST service and justify the order (for example requirements, domain model, test setup).
Scaffold the project with a repository, a branching strategy, unit tests for one domain rule and a CI pipeline that runs them on every push.
Write a short design note describing class structure, API endpoints and testing approach, so you practise documentation as well as code.

Deliverable: A scaffolded service with passing unit tests, a CI configuration, and a one-page design note.

Day 7 — Behavioral story bank and a mock final round

Write STAR stories for learning a technology quickly, pushing back on a flawed feature and your usual team role, each ending with a measurable result.
Write your answers on why a financial institution and how you stay current, tied to specific examples.
Run a long mock session alternating a technical walkthrough (atomic transfer, project from scratch, SOLID) with behavioral questions, and list where you lost clarity.

Deliverable: Four STAR stories, written answers for the bank and staying-current questions, and a mock-session list of weak spots to fix.

Behavioral stories for a bank engineering loop

Candidates describe the behavioral stage as covering collaboration, teamwork and cultural fit, with Agile or Scrum experience, working through unclear requirements and resolving technical disagreements as reported themes. Prepare four or five stories in which you made the decision and can state the result, and use the STAR structure that candidates recommend. Keep the tone professional.

Describe a time you had to work with a difficult team member to deliver a project on time.

How do you handle exceptions in your code to ensure system stability?

Medium · Core CS & OOP Fundamentals

Approach

Answer with a policy first, then one real example. I catch an exception only where I can act on it: retry, fall back, translate it into a domain error, or clean up. Everywhere else it propagates to a boundary that deals with it.
Use the mechanics of the language you will interview in: try-with-resources in Java, using or try/finally in C#, context managers in Python. Catch the narrowest type, never leave an empty catch block, and keep the original cause when wrapping.
At a REST boundary, map failures to status codes (validation 400, missing resource 404, conflict 409, unexpected 500), return a stable error body with a correlation id, and log the stack trace once with that id, without account numbers or credentials.
For money movement, tie exceptions to transactions: any failure rolls back so no half-finished transfer survives. Retry only idempotent operations, with a cap and backoff, and separate transient failures such as timeouts from permanent ones such as validation errors.
Close with a short incident: a swallowed or over-broad catch that hid a failure, what you changed, and the alert or test that now catches it. A story with no change and no check sinks the answer.

Follow-up

What is the difference between checked and unchecked exceptions in Java, and when would you define a custom exception?
What happens if the cleanup code in a finally block throws as well?
How do you decide between retrying and failing fast when a call to another service times out?

Why are you interested in working for a financial institution like City National Bank?

Medium · Behavioral & Cultural Fit

Approach

Give two or three reasons that are about the work. Financial software carries hard correctness constraints (balances that must reconcile, transactions that must not be lost, access that must be controlled), and the role description candidates see names data integrity, real-time processing and compliance. Say which of those you find interesting and why.
Anchor each reason in something you have done: a reconciliation bug, a payment or booking flow, an audit trail, a permissions change. A reason you cannot back with an example reads as flattery.
Show you looked up the bank beyond its name. Candidates report that it serves many entertainment and professional services clients and offers banking, investment and trust services; say what that implies for the software (client portals, wealth tools, APIs) without claiming inside knowledge.
If you come from outside finance, say so, name the transferable habit (testing money-like logic, idempotent APIs, careful migrations) and describe how you would learn the domain in your first months.
End with what you want from the next role, such as long-lived systems where design quality matters, and connect it to the team you would join.

Follow-up

Why a bank rather than a fintech startup or a consumer product company?
What do you know about the bank's clients, and how would that change how you build a feature?
How would you get up to speed on regulatory requirements you have never worked with?

Tell me about a time you had to learn a new technology quickly to meet a project deadline.

Medium · Behavioral & Cultural Fit

Approach

Choose a story with a real deadline and a technology you had not used, and state the stakes in two sentences: the date, the feature and what depended on it.
Show how you learned efficiently. Identify the smallest slice of the technology the deadline required, read the official docs for that slice, build a throwaway spike, read existing code that already used it, and ask one person who knew it for a review rather than a tutorial.
Show risk control: tests around the new code, a scope cut or a feature flag, early review, and a check against the deadline partway through.
Give the result with a measure, such as shipped on the date, defect count after release, or response time, and one mistake you made while learning and how you corrected it.
Avoid claiming mastery after a few days. Say what you still did not know and what you did to close that gap after the deadline.

Follow-up

How did you decide what not to learn at that stage?
What did you get wrong the first time, and how did you find out?
If the technology were a cloud service such as Azure or AWS that you had never used, how would you start?

How do you handle a situation where you are asked to implement a feature you believe is technically flawed?

Medium · Behavioral & Cultural Fit

Approach

Start by checking that you understand the request. Ask what problem the feature solves and what constraints produced the design, because the flaw may be a misunderstanding on your side.
Make the concern concrete and measurable: the data it could corrupt, the security exposure, the performance cliff, the maintenance cost. Bring a short written comparison and an alternative, not just an objection.
Raise it with the person who owns the decision, privately first, offering a cheap way to settle it, such as a spike, a load test or a smaller first release.
If the decision stands, commit and build it well: put it behind a flag, add tests and monitoring for the risk you named, and record the concern and the decision in the ticket or design note.
Be clear about the boundary. If the flaw touches security, data integrity or compliance, escalate rather than quietly comply. A story where you simply routed around the instruction, or where everyone else was wrong, sinks the answer.

Follow-up

What if your manager insists and the issue is a security risk?
Tell me about a time you raised a concern and turned out to be wrong.
How do you document a disagreement without it reading as blame?

Describe your ideal team environment and the role you usually play within it.

Medium · Behavioral & Cultural Fit

Approach

Describe the environment through observable practices rather than adjectives: code review on every change, short Agile or Scrum ceremonies that surface blockers, automated tests and CI, written design notes, and a habit of discussing disagreements in the open.
Name the role you usually play and prove it with a specific example, such as the person who writes the design note, who reviews most carefully, who mentors newer engineers, or who owns incident follow-up.
Show range: describe one time the team needed a different role from you and how you shifted. Reported responsibilities for this job include code review, mentoring and documentation, so connect your role to those.
Mention receiving feedback as well as giving it: a review comment that changed your approach and what you did with it.
Avoid describing a team with no friction. A believable answer admits the trade-offs, such as more review time in exchange for fewer production defects.

Follow-up

What do you do when your usual role conflicts with what the team needs?
How would you handle joining a team whose practices differ from your ideal?
Tell me about a code review comment you disagreed with.

How do you stay updated with the latest trends and best practices in software engineering?

Medium · Behavioral & Cultural Fit

Approach

Name actual habits and sources, not a general claim: specific newsletters, release notes for the language or framework you use, security advisories, conference talks or a side project. Interviewers cannot check a vague list, and a long list of names invites follow-ups you cannot answer.
Give one recent item and what you did with it, such as a language feature that simplified a class design, a dependency advisory you patched, or a testing approach you introduced to your team.
Show judgment about adoption. For long-lived systems, say how you decide whether a trend deserves use: a proof of concept, support and maintenance cost, team familiarity, and a rollback path.
Mention that you share what you learn, through a short team demo, a review comment or documentation, so learning improves the team as well as you.
Tie it back to the role's listed stack by naming one thing you are tracking in Java, C#, Python, SQL, REST or cloud services.

Follow-up

Tell me about something you learned recently and how you applied it.
What trend did you decide not to adopt, and why?
How would you introduce a new library or framework into a long-lived banking system?