JPMorgan Chase Software Engineer Interview Questions
A software engineer at a large bank for people and businesses works across card approvals, cash machines, account systems that have run for a very long time, and the rules that come with handling money. Prepare to talk about changing old systems safely, deciding in a moment whether a card payment goes through, testing fee and interest logic, and keeping personal data out of places it should not be. What to show here: careful change to systems people trust with money. Each question below has what the interviewer is checking, an answer frame and a sample spoken answer to adapt.
How JPMorgan Chase hires, in its own words, and its questions for every job →
1. Tell me about a time you had to add a feature on top of a very old system that could not be switched off, the way a bank's account system cannot.
- Describe the old system and why it could not stop.
- Explain how you learned its behaviour.
- Describe how you added the feature around it.
- Share how you released and what you learned.
“In my last job, billing ran on an old program that processed files every night and had no test suite. We needed a new discount type. Rewriting it was not an option because the business depended on it daily. I collected a month of real input and output files and used them as a safety net: any change had to produce the same output for old cases. I added the new logic in a separate module that the old program called at one point. We ran old and new side by side for a while and compared results. Then we switched, and your result.”
Weak answers call the old system bad and propose replacing all of it, with no plan for the business that runs on it.
2. Describe a time a risk or compliance review slowed your release. How did you work with the reviewers instead of around them?
- Describe the change and the review it needed.
- Explain what the reviewers were worried about.
- Show what you did to answer it.
- Share how you changed your process afterwards.
“We were adding a feature that stored a customer's date of birth, and the privacy review came back with many questions a week before release. My first feeling was frustration. Then I asked the reviewer for a short call and learned the real concern: who could read that field and how long we kept it. I limited access to one service, added a retention rule and documented both. The release moved by a few days. After that I started sending a one-page summary of data changes to the reviewers at design time, so questions came early. The next review your result.”
Weak answers describe reviewers as blockers, or boast about finding a way to skip the review.
3. Design the decision that approves or declines a card payment while the customer is standing at the till. What do you check, and what happens if the fraud check is slow to reply?
- Set the time budget for the whole decision.
- Order the checks: card status, available balance, limits, fraud score.
- Give each dependency a timeout and a fallback rule.
- Record the decision and its reasons for later review.
“The whole decision has a short time budget, so I would run the cheap checks first: is the card active, is there enough available balance, is the amount within the customer's limits. The fraud score is requested in parallel with a strict timeout. If it does not reply in time, I would not simply approve or decline everything. I would apply a simple local rule: approve small amounts at shops the customer has used before, and decline or ask for extra confirmation on unusual ones. Every decision is stored with its inputs, so a complaint or a review can be answered later.”
Weak answers wait for every check however long it takes, or approve everything when the fraud service is down.
4. A cash machine loses its connection to the bank for a few minutes. What should the software on the machine allow, and how does it make things right when the link returns?
- Decide which actions are unsafe without the bank and refuse them clearly.
- Handle a withdrawal that was in progress when the link dropped.
- Keep a local journal that cannot be altered.
- Reconcile with the bank when the link returns.
“Without the link, the machine cannot know the balance, so I would refuse new withdrawals with a clear message instead of guessing. The hard case is a withdrawal in progress. The machine must write each step to a local journal before doing it: request sent, approval received, cash counted, cash taken. If the link drops after approval but before cash is given, the machine cancels and records that. When the link returns, it sends its journal, and the bank compares it with its own records. If the bank debited an account but no cash left the machine, the debit is reversed.”
Weak answers let the machine hand out cash offline with no limit, or forget the withdrawal caught in the middle.
5. How would you test a function that works out monthly interest or a late fee, so that you trust it on the unusual days of the calendar?
- Get worked examples from the people who own the rule.
- Test boundaries: month end, leap day, account opened or closed mid-period.
- Test rounding and very small or very large balances.
- Add generated cases that check general truths.
“I would start by asking the business owner for worked examples, because my own reading of the rule might be wrong. Those become the first tests. Then I add boundary cases: the last day of a short month, a leap day, an account opened in the middle of the period, a balance of zero, a balance that changes every day. I test rounding on amounts that fall exactly halfway. I also generate many random cases and check simple truths, for example that interest is never negative on a positive balance. I pass the date in as an input, so tests never depend on today.”
Weak answers test one normal case, or let the function read the system clock so results change from day to day.
6. You need good logs to debug a card service, but full card numbers and personal details must never appear in them. How do you get both?
- List the fields that must never be logged.
- Log safe references such as a request id or a token.
- Mask at one shared layer, not in each call.
- Test and scan so a mistake is caught before release.
“I would decide first what is forbidden: full card numbers, security codes, passwords and similar details. For tracing, each request gets an id that passes through every service, and I log a token that stands for the card, not the number itself. Masking lives in one shared logging layer, so no developer has to remember it in each line. Objects that hold sensitive fields print a masked form by default. I add a test that sends a known fake card number through the service and fails if it appears in any log output, and a scanner that checks logs for number patterns.”
Weak answers log whole request bodies for convenience, or trust each developer to mask by hand.
7. Support tells you several customers see the same shop charge twice on their card statements, and the card service belongs to your team. What do you do first, and next?
- Confirm with examples whether money was taken twice or only shown twice.
- Find the common factor and stop the cause.
- Repair affected accounts with recorded entries.
- Give support plain words for customers, then review.
“First I take two or three examples and check the ledger: is it one debit shown twice, or two real debits? That changes everything. If they are real, I look for what the cases share, such as one shop, one time window or one release, and I stop the cause, maybe by pausing a retry job. Then I find every affected account with a query, and reverse the extra debit with a new entry that refers to it. I give support a short, plain explanation and a time for the correction. Afterwards we review why our duplicate check did not catch it.”
Weak answers start changing code before looking at a real example, or fix the accounts without telling support.
8. What makes you want to be an engineer at a bank like JPMorgan Chase, where change is slower and more controlled than at a young product company?
- Be honest about the trade.
- Say why the controlled side appeals to you.
- Connect it to accounts, cards and payments at large scale.
- Say what you want to learn or improve.
“I know a bank releases with more checks than a small product team, and I see the reason. When software holds people's money, a fast mistake costs more than a slow release. I find that kind of engineering satisfying: thinking about failure before it happens, and leaving a record anyone can follow. JPMorgan Chase runs accounts, cards and payments for a huge number of people and businesses, so even a small improvement reaches many. I would like to learn how old and new systems are made to work together, and help make safe changes quicker without making them less safe.”
Weak answers complain about slow process in advance, or show no idea why a bank is careful.
No figures on this page: pay depends on the level, the city and the offer in front of you. When the offer comes, the free salary negotiation script helps with that part.
The questions above are the prep. On the real call, ClapAssist helps with the ones you did not practice.
ClapAssist is an AI interview assistant for Mac and Windows. It listens to the interview on your computer and shows you what to say, in short lines you can read while you talk. Your live interview audio and screen are never stored. Your resume and notes are saved to your account so the app fills them in on any computer. It is hidden from screen share on every plan, including Free; only you can see it.