TD Bank Interview Guide (2026)

1Snapshot, read this first#

The one thing to understand about TD. This is a bank first and a tech employer second.

• The money you touch belongs to real customers, and it moves through systems that regulators audit.
• They are not hiring the flashiest champion who solves a hard dynamic-programming problem in six minutes.
• They want someone who writes correct, maintainable, testable code and explains tradeoffs plainly.
• Picture the person who, before shipping, asks "what happens if this retries?" Be that person and you are most of the way there.

2Getting the call (the part most guides skip)#

The application-to-interview step is where most people quietly die.

• TD runs its postings through Workday, and a parser scores your resume against the posting before a human ever opens it.
• A generic resume gets filtered out at a rate most candidates never see, because they just get silence.

Three things move the needle.

Referrals, the single biggest lever (bigger than a perfect resume).

• TD runs a real internal referral program, and referred candidates get surfaced to the recruiter faster, often inside a few days instead of the general pile.
• Find TD engineers on LinkedIn, especially in your city (Toronto, Mount Laurel NJ, Hyderabad).
• Send a short, specific note: the exact job ID or title, one line on why TD, one line on what you built that matches.
• Do not ask them to vouch for your skills. They do not know you yet. Just ask them to submit the referral through the internal portal.
• Most will, because many TD teams pay a referral bonus and it costs them two minutes.

A resume bullet that actually says something. Compare these two.

• Weak: "Worked on backend services and improved performance."
• Strong: "Rebuilt the payments reconciliation job in Java/Spring Boot, cut nightly run time from 40 min to 6 min by batching DB writes and adding an index, covering 2M+ daily transactions."

What the strong one does:

• Names the tech, the mechanism (batching, an index), the before-and-after number, and the scale.
• Reads as reliability, throughput, correctness, or risk reduction, which is exactly what banks perk up at.
• A bullet about "cut duplicate charges to near zero" beats "added a cool feature" every time. Lead with the reliability ones.

ATS keywords, mirrored word for word where it is honest.

• If the posting says Java, Spring, REST, SQL, Angular/React, microservices, CI/CD, AWS/Azure, put the ones you actually know in a Skills section and prove each one in a bullet underneath.
• TD's stack leans Java and Spring on the backend, some .NET/C#, Python for data work, Angular and React on the front end, Oracle/SQL Server/Postgres for storage, and increasingly AWS and Azure as workloads move off the mainframe.
• Do not keyword-stuff a skill you cannot defend in round one. The recruiter screen will catch it in ninety seconds.

3The loop at a glance#

Not every candidate sees every round.

• Experienced hires often skip the OA and go straight to two technical rounds plus a values round.
• Grad and early-career candidates almost always get the OA and frequently a full superday.
• The superday is really the whole loop compressed into one long day with a rotating panel.

4The coding or technical rounds#

Set your expectations right so you prep for the right thing.

• TD's coding bar is reasonable, not brutal. Think LeetCode easy-to-medium, with the occasional medium that has a small twist.
• You will almost never get a hard graph problem with a clever trick that only clicks if you have seen it before.
• What they really test: whether you reason cleanly, handle the edge cases, and write code you can stand behind and explain.

Patterns that come up again and again:

• Arrays and strings: two pointers, sliding window, frequency maps, in-place edits. Think "longest substring without repeats" or "move zeroes."
• Hash maps: the workhorse of this loop. Two-sum style, grouping anagrams, counting, dedup, first unique character.
• Recursion and basic trees: traversals, depth, is-balanced, lowest common ancestor, simple BST insert/search.
• Sorting and searching: binary search on a sorted array and binary search on an answer, custom comparators for sorting objects.
• SQL, and this one matters more at a bank than people expect: inner vs left joins, GROUP BY, HAVING, window functions (ROW_NUMBER, RANK), finding duplicates, second-highest salary, running totals. Practice it until it is muscle memory. Strong coders who breezed through the array problem have frozen on a basic self-join, and it changed the hire decision.
• OOP design in code: model a small domain (a bank account with deposit/withdraw, a transaction ledger) with clean classes, clear responsibilities, and a few sensible methods.

The HackerRank OA, and how to score it.

• Usually 2-3 problems plus sometimes multiple-choice on CS basics or SQL, and occasionally a short aptitude or personality section.
• Watch the clock: 60-90 minutes goes fast.
• Partial credit is real: each passing test case scores, so get a brute-force solution passing some cases first, then optimize only if time is left.
• A partially correct answer on two problems beats one perfect answer and one blank.

How to actually win the live round, because this is where the offer is decided:

1. Clarify first. Restate the problem in your own words. Ask about input size, empty inputs, duplicates, negative numbers, whether the input is sorted. A candidate who asks "can the array be empty, and can values repeat?" before typing a line signals they think about edge cases the way they would in production, where an empty input is a Tuesday.
2. Think out loud. Say your plan before you code. "I will use a hash map to count characters, then one pass over the string to find the first count of one." Silence is the number-one reason people fail an otherwise solvable problem. Nobody can credit logic they never hear, or help you course-correct from a wrong turn they cannot see.
3. State complexity. Saying "O(n) time, O(n) space because of the map" signals you understand the cost of what you wrote. Adding "I could trade space for time here but it is not worth it" is better still.
4. Test your own code. Walk one real example through your solution line by line, then a tricky one (empty, single element, duplicate). Catch your own off-by-one before the interviewer has to. A candidate who finds and fixes their own bug scores higher than one who wrote it clean but never checked.
5. Write clean code. Descriptive names, small functions, early returns over deep nesting, no cleverness for its own sake. A bank values readable over slick every single time, because the person maintaining your payment code at 2am might be you.

5CS fundamentals and light system design#

What the "design" round really is.

• For early-career and most core SWE roles, it is a CS-fundamentals conversation plus a project deep-dive.
• They want to know you understand the machine under your code, not just how to glue libraries together.
• Senior candidates get a lighter, more real-world system design chat tied to what they would actually own.

Cover these cold:

• OS: process vs thread, concurrency, deadlock and its four conditions (mutual exclusion, hold and wait, no preemption, circular wait), what a mutex does and how it differs from a semaphore, stack vs heap. Banks run heavily concurrent systems, so threading questions are fair game and a vague answer hurts.
• DBMS: normalization and when to denormalize, indexing and why an index speeds reads but slows writes, ACID (this one matters a lot: they will ask, and they want you to tie it to why a debit and the matching credit must both commit or both roll back), transactions and isolation levels (and what a dirty read or phantom read is), SQL vs NoSQL tradeoffs and when you would pick each.
• Networking: TCP vs UDP and why a bank uses TCP for transactions, what happens end to end when you type a URL and hit enter, HTTP methods and status codes (know 200, 201, 400, 401, 403, 404, 429, 500), the basics of TLS and why the handshake matters. Security-adjacent questions show up because, well, bank.
• OOP: the four pillars (encapsulation, abstraction, inheritance, polymorphism), interface vs abstract class and when to reach for each, composition over inheritance with a concrete reason, SOLID in plain words with a one-line example per letter.

For the design discussion (more common at mid/senior), use a simple frame and say the steps out loud so the interviewer can follow:

1. Clarify requirements and scale. How many users, reads vs writes, latency target.
2. Define the API. The handful of endpoints and their inputs and outputs.
3. Sketch the data model. Tables or documents, keys, indexes.
4. Draw the high-level components. Client, service, database, cache, queue.
5. Talk bottlenecks, caching, failure, and (key at a bank) consistency, auditability, and security.

Classic prompts, and the instinct that wins them.

• Prompts seen or asked: design a URL shortener, a rate limiter, a simple transaction/ledger service, a notification system for payment alerts, an ATM.
• When it is a money-touching system, always raise consistency over availability (a customer would rather wait than see the wrong balance).
• Raise idempotency, so a retried request never double-charges.
• Raise an append-only audit log, so every movement of money is traceable for a regulator.
• Naming idempotency and the audit trail without being prompted is what separates a bank-ready engineer from a generic one, and it is the single easiest way to stand out in this round.

6Behavioral and culture fit#

TD's culture is a set of shared commitments, not a slogan to recite.

• The ones to internalize: think like a customer, act like an owner, execute with speed and impact, innovate with purpose, and develop our colleagues.
• Show them in your stories so the interviewer maps your example onto the value without you naming it.
• TD takes behavioral seriously, more than most pure-tech shops, because a regulated institution genuinely cares about integrity, risk awareness, and how you behave when something goes wrong. In their world "something went wrong" can mean a customer's money or a regulator's letter.

Prepare 6-8 STAR stories, each tight and under two minutes.

• A conflict with a teammate, a real failure you owned, a tight deadline.
• A time you caught a bug or a risk, a leadership moment, a time you simplified something over-built.

Here is one worked example, the "caught a risk" story, because it lands especially well at a bank.

Situation: During a release, I noticed our payment service retried failed API calls without an idempotency key. Task: I had to decide whether to flag it two days before launch or let it ship. Action: I raised it immediately, built a quick test that reproduced a double-charge under network retry, and paired with a senior dev to add an idempotency key keyed on transaction ID. I wrote the regression test so it couldn't come back. Result: We shipped one day late but prevented an estimated 1-2% of transactions from double-charging, which at our volume was roughly 3,000 duplicate charges a month avoided. My manager used it as the team's standard pattern afterward.

Notice the shape, and keep it for every story.

• A real risk, a decision under pressure, a concrete action with a test that pins the fix, and a result with a number.
• The failure story matters just as much: pick a real one, own your part cleanly without blaming teammates, and end on what you changed so it never repeated.
• At a regulated firm, "here is exactly what I did wrong and here is the guardrail I added" is a strength, not a confession.
• Have a clean, honest answer to "why TD and why banking." Something true beats something polished. A simple one works: "I like building systems where correctness is not optional."

7Your prep plan#

4-week plan

• Week 1: CS fundamentals refresh (OS, DBMS, networking, OOP). 15 easy LeetCode. 10 SQL problems.
• Week 2: 25 LeetCode mediums across arrays, hashing, strings, trees. Start writing STAR stories.
• Week 3: Mock interviews out loud. 20 more mediums. Light system design (2-3 classic prompts). Finish STAR stories.
• Week 4: Timed OA simulation. Behavioral rehearsal. Research TD's values and recent tech news. Re-solve your weak problems.

2-week plan

• Days 1-4: Fundamentals + 20 easy/medium LeetCode + 10 SQL.
• Days 5-9: 25 mediums, 3 mock interviews, write 6 STAR stories.
• Days 10-12: System design basics, timed coding, behavioral practice.
• Days 13-14: Review mistakes, rehearse "why TD," rest the night before.

2-day crash plan

• Day 1: 15 of the most common patterns (two pointers, sliding window, hash map, BST traversal, binary search), 8 SQL problems, read TD's values.
• Day 2: Write 4 STAR stories, 2 timed coding sessions out loud, prep your "why TD" and 3 questions to ask them. Sleep.

8Why people get rejected at TD Bank#

1. Coding in silence. They solved it but never narrated their thinking, so the interviewer could not tell whether it was their own reasoning or a memorized template. A clean solution you cannot explain reads as a copied one.
2. Weak SQL and DB fundamentals. At a bank this is not optional, and candidates underestimate it constantly, treating SQL as an afterthought to the algorithm. A frozen self-join has sunk otherwise-strong loops.
3. No testing instinct. They finished the code and said "done" without running a single example through it, so an off-by-one or a null case got left in. "Done" without a trace means not done.
4. Over-engineering. Reaching for a factory, a strategy pattern, and three interfaces on a 15-line problem. Banks reward boring, correct code and read unnecessary abstraction as a maintenance risk.
5. No risk or ownership mindset. When asked about a bug they shipped, they blamed QA or a teammate instead of owning it and naming the guardrail they added. That is a red flag at a regulated firm where ownership is the job.
6. Generic "why TD." Saying "I want to work at a big stable company" with zero connection to banking, customers, or correctness. It reads as "I applied everywhere and TD was one of forty," and it drops you below the candidate who had one real reason.

9The offer, comp and negotiation#

Rough 2026 ranges (base, plus a 10-15% target bonus for most roles; higher levels get more):

• US: New grad ~$80k-$110k. SWE II ~$105k-$135k. Senior ~$135k-$175k. Mount Laurel NJ and NYC-area roles pay toward the top of each band because of cost of living.
• Canada: New grad ~C$70k-$90k. Mid ~C$95k-$120k. Senior ~C$120k-$150k. Toronto is the hub and carries the most openings.
• UK: Dev ~£45k-£70k. Senior ~£70k-£95k. Smaller footprint, so fewer roles and less frequent hiring.
• India (capability center): SWE ~INR 10-22 LPA. Senior ~INR 24-40 LPA. Hyderabad-heavy, and a large and growing share of TD's engineering sits here.

The bands are real, but there is room inside them. People leave money on the table by assuming otherwise.

1. Negotiate the base against the band, not a fantasy. Banks hold firm on equity (there usually is not much, and it is not the lever here) but can flex base and sign-on. Ask the recruiter where your offer sits in the band, then push toward the top with a competing offer or a clear case on your scope and years. "Based on my experience I would expect to land in the upper half of the band" is a reasonable, grounded ask.
2. Get a sign-on bonus. This is often the easiest lever when base is capped at the top of the band, because it is a one-time cost that does not reset the band. Ask for it directly and name a number.
3. Clarify level. The single biggest comp difference is whether you are hired as SWE I vs II, or mid vs senior, since each level is a different band entirely. If your experience justifies the higher level, make that case before you argue dollars. Moving up a level beats squeezing a few thousand out of the current one, every time.

Two rules that protect you.

• Always get the offer in writing.
• Do not verbally accept on the call. "I'm excited, can I review the written details and come back tomorrow?" is a complete sentence, and no good recruiter will penalize you for it.

If you want, map these rounds onto your actual interview date and build a day-by-day plan backward from it, so nothing gets crammed into the last night.