Skip to content

JP Morgan Interview Questions and Answers (2026)

JP Morgan’s technology hiring funnels through an OA, a HireVue video screen, and two technical interviews, with a parallel Code for Good hackathon track that can fast-track strong performers straight to an offer.

Round Duration What they test
Online Assessment 90-120 min Aptitude + coding problems (HackerRank)
HireVue Video Interview 3-5 questions Recorded behavioral answers, 2-3 min each
Technical Round 1 45-60 min DSA, OOPs, SQL, Java/C++
Technical Round 2 45-60 min Projects, domain topics (trade booking, low-latency)
HR / Managerial 20-30 min Motivation, location, background verification

A timed HackerRank test mixing 2-3 coding problems with mathematical and logical aptitude. Clean, fully-passing solutions are valued over partial cleverness - shortlist mail typically arrives within a few days of the test.

Common questions

  • Array/string coding problems at easy-medium difficulty
  • Quantitative and logical reasoning MCQs
  • Basic SQL query questions

A recorded, one-way interview with 3-5 pre-set questions - 30 seconds to prepare, then 2-3 minutes to record each answer, with exactly one re-record allowed per question. It screens for communication and motivation before any live technical round.

Common questions

  • Why do you want to work in banking technology?
  • Tell me about a time you solved a difficult problem
  • Describe a situation where you worked well in a team
  • Why JP Morgan specifically?

Focuses on core DSA and CS fundamentals with live coding, plus OOPs and SQL questions.

Common questions

  • Valid parentheses / balanced-expression checks (stack-based)
  • Find duplicates in a stream of data (hashing)
  • SQL + coding hybrid - nth-highest-salary style queries using window functions
  • OOPs concepts - inheritance, polymorphism, interfaces vs abstract classes

Goes deeper into your resume project and domain systems relevant to JP Morgan - trade booking, low-latency processing, and risk systems - at a fresher-appropriate depth.

Common questions

  • Explain trade booking in plain language - inputs, outputs, what breaks at scale
  • Discuss low-latency system design - bottlenecks and failure modes
  • Detailed project walkthrough - architecture, hardest bug, what you’d rebuild
  • API and data-model design questions for a simple risk or trading system

Full round-by-round narratives are on the JP Morgan interview experience page.

A closing conversation on motivation, location preference, and comfort with background-verification timelines. Concrete, situation-based answers land better than rehearsed slogans.

Common questions

  • Why banking technology, and why JP Morgan?
  • Tell me about a time you showed leadership while resolving a conflict in a team
  • Tell me about a time you received tough feedback - how did you respond?
  • Are you comfortable with the background-verification process and timelines?

Sample answer frameworks for each of these are on the JP Morgan HR interview questions page.

Code for Good: JP Morgan’s hackathon fast-track

Section titled “Code for Good: JP Morgan’s hackathon fast-track”

Unlike most bank recruiting funnels, JP Morgan runs Code for Good - a weekend hackathon where shortlisted students form teams and build real software for non-profit organizations, mentored directly by JP Morgan engineers. It runs alongside the standard interview process at many campuses rather than replacing it, and strong performers can be fast-tracked into summer analyst or full-time software engineering offers without completing the full standard technical-interview loop. If your campus runs a Code for Good drive, it’s worth treating as a parallel - and sometimes faster - path to an offer.

Common technical interview questions and answers

Section titled “Common technical interview questions and answers”
Q: Explain trade booking in plain language - what actually happens end to end?

Booking is the step where an agreed trade is recorded in the bank’s systems as an official position. An order is placed and routed to a venue; when it executes, the fill comes back with the economics - instrument, quantity, price, counterparty, trade date and settlement date. Booking writes that into the trade capture system, which then feeds three downstream consumers: risk, which needs the new position to recompute exposure; settlement, which arranges the exchange of cash and securities on the value date; and the general ledger for accounting. The parts that break at scale are duplicate bookings when a confirmation is replayed, which is why every trade carries a unique ID and the booking API must be idempotent, and amendments or cancellations after the fact, which is why bookings are usually stored as an append-only event history rather than an updatable row. Static data errors - a wrong counterparty or instrument reference - are the other common source of breaks.

Q: What makes a system low-latency, and where are the usual bottlenecks?

Low latency is about the tail, not the average - the number that matters is the 99th percentile, because in trading a slow one-in-a-hundred response is a real loss. The usual bottlenecks are garbage collection pauses in managed runtimes, which is why latency-sensitive Java code is written to allocate almost nothing in the hot path and to reuse object pools and primitive arrays; network hops and serialisation, addressed by co-locating services and using compact binary formats instead of JSON; disk and database access, moved off the critical path by keeping state in memory and writing to a log asynchronously; and lock contention, avoided with lock-free ring buffers and single-writer designs. Cache locality matters concretely too - an array of primitives traverses far faster than a linked structure of objects scattered across the heap. The framing interviewers reward is measuring first and naming the specific percentile you improved.

Q: Write a SQL query for a running total of trade notional per day.

Use a window function with an ordered frame: SELECT trade_date, notional, SUM(notional) OVER (ORDER BY trade_date ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS running_total FROM trades ORDER BY trade_date; If you need the running total restarted per book or desk, add PARTITION BY book_id before the ORDER BY. The reason a window function is right here rather than GROUP BY is that GROUP BY collapses the detail rows, whereas the requirement is to keep every trade row and attach a cumulative figure to it. The alternative self-join, joining trades to all trades with an earlier or equal date and aggregating, is O(n squared) and is exactly the answer interviewers are hoping you improve on.

Q: What is the difference between HashMap, Hashtable, and ConcurrentHashMap in Java?

HashMap is unsynchronised, allows one null key and null values, and is the right default for single-threaded or externally synchronised use; used concurrently it can corrupt its internal structure or lose updates. Hashtable is the legacy synchronised version, which locks the entire map on every operation, so throughput collapses under contention, and it forbids nulls. ConcurrentHashMap is the modern concurrent option: reads proceed without locking, and writes lock only the individual bin rather than the whole table, so many threads write in parallel. It also forbids nulls, deliberately, because a null return would be ambiguous between absent and present-with-null in a concurrent setting. It adds atomic compound operations such as putIfAbsent, computeIfAbsent, and merge, which are what you need to avoid the check-then-act race that a plain get followed by put would create.

Q: How would you evaluate a postfix expression?

Scan the tokens left to right with a single stack. Push every operand. On an operator, pop the top two values, apply the operator with the second-popped value as the left operand - order matters for subtraction and division - and push the result back. When the scan finishes, the single value left on the stack is the answer. This is O(n) time and O(n) space. Postfix, or reverse Polish notation, needs no parentheses and no precedence rules, which is precisely why compilers and calculators convert infix to postfix first, using the shunting-yard algorithm. The edge cases to raise unprompted are division by zero and a malformed expression, where either the stack underflows on an operator or more than one value remains at the end.

Q: Given a stream of incoming trades, how would you detect duplicate trade IDs?

Hold the trade IDs seen so far in a hash set and check membership before processing each incoming trade - O(1) average per trade, O(n) memory. Since a trade stream is unbounded, the realistic version bounds the memory: keep only the IDs from the current business day or a sliding time window, since duplicates from a replayed feed arrive close together, and let older IDs age out. Where memory is very tight, a Bloom filter gives a definite no or a probable yes in a few bits per element, so it acts as a cheap pre-filter and only probable hits are checked against the authoritative store. The important design point in a banking context is that the duplicate check has to be atomic with the insert - otherwise two consumers can both see the ID as absent - so in practice you enforce it with a unique constraint on the trade ID in the database as well.

Q: How would you design the data model for a simple trade and risk system?

At minimum you need a Trade table keyed by an immutable trade ID, holding instrument ID, counterparty ID, quantity, price, direction, trade timestamp, value date, book ID, and a status column. Instrument, Counterparty, and Book are separate reference tables joined by foreign key, so a name change does not rewrite history. Amendments and cancellations should not update the row in place - store a version or an append-only event table so you can reconstruct the position as it was known at any past time, which regulators and reconciliation both require. Positions are then a derived aggregate, grouped by book and instrument, either computed on demand or maintained incrementally and reconciled nightly. Index on trade date and on the book plus instrument pair, since those are the dominant query paths, and store money as a decimal type with an explicit currency column, never as a floating-point number.

Q: What does idempotency mean in an API, and why does it matter for trades and payments?

An idempotent operation produces the same end state whether it is applied once or many times. This matters because networks fail ambiguously: if a client sends a booking request and the connection drops before the response arrives, the client cannot tell whether the trade was recorded, and a blind retry risks booking it twice. The standard solution is a client-generated idempotency key sent with the request; the server stores that key with the result of the first execution and, on seeing it again, returns the stored result instead of re-executing. In HTTP terms, GET, PUT, and DELETE are idempotent by definition while POST is not, which is why payment and booking APIs built on POST need the key explicitly. The same principle covers message queues, since at-least-once delivery guarantees that some messages will be redelivered.

Frequently asked questions about JP Morgan interviews

Section titled “Frequently asked questions about JP Morgan interviews”
What is the JP Morgan interview process for freshers?

JP Morgan’s technology loop typically runs: 1. Application (on-campus via college placement cell, off-campus via the JP Morgan Careers portal, or through referrals). 2. Online Assessment (90-120 minutes) - 2-3 coding problems on HackerRank plus mathematical/logical aptitude. 3. A HireVue recorded video interview - 3-5 pre-set questions, 30 seconds to prepare and 2-3 minutes to record each, with one re-record allowed per question. 4. Two technical interviews (45-60 min each) covering DSA, OOPs, SQL, and domain topics like trade booking and low-latency systems. 5. A closing HR/managerial round (20-30 min) on motivation and background verification. Total duration: roughly 3-4 weeks from application to offer.

What questions are asked in JP Morgan interviews?

Technical rounds commonly ask stack-based problems like valid parentheses/expression checks, hashing problems like finding duplicates in a stream, and SQL-plus-coding hybrids (nth-highest-salary style queries, window functions). Expect domain conversation around trade booking, low-latency system design, and risk systems explained in plain language, plus a detailed walkthrough of your resume project - architecture, hardest bug, what you’d change. Behavioural rounds check ownership, teamwork, and why JP Morgan.

How many rounds are there in the JP Morgan interview?

JP Morgan typically runs 4-5 touchpoints: an Online Assessment (90-120 min), a HireVue video interview, two technical interviews (45-60 min each), and a closing HR round (20-30 min). Some drives skip the standalone HireVue or merge HR with the managerial round - check that cycle’s college placement email or offer communication.

What is JP Morgan’s Code for Good hackathon?

Code for Good is JP Morgan’s weekend hackathon where shortlisted candidates and students form teams to build software for non-profit organizations, mentored by JP Morgan engineers. It runs alongside the standard recruiting funnel at many campuses, and strong performers in the hackathon can get fast-tracked into summer analyst or full-time software engineering offers without going through the full standard interview loop.

How should I prepare for JP Morgan interviews?

Practise timed DSA on stacks, hashing, and graphs, revise OOPs and SQL (especially window functions and joins), and prepare one crisp, detailed project narrative you can defend under follow-up questions. Read up on trade booking and low-latency systems so you can explain them in plain language rather than buzzwords, and rehearse the HireVue format - short, structured answers recorded in a single take. Use STAR for behavioural answers.

Does JP Morgan interview differently for technology vs other analyst roles?

Yes. Technology Analyst / Software Engineer candidates are evaluated on coding, CS fundamentals, and domain systems knowledge (trade booking, low-latency, risk). Business/operations analyst tracks lean more on aptitude, case-style reasoning, and finance fundamentals with little to no coding. Confirm which track your req falls under before you start prepping - the technical bar and question style differ substantially.

Looking for placement papers, OA practice, or coding questions?

Section titled “Looking for placement papers, OA practice, or coding questions?”