JPMorgan Chase Interview Guide (2026): Software Engineers and Strats

JPMorgan Chase runs one of the largest engineering organizations anywhere: roughly 60,000 technologists, more people writing code than work at most of the firms that call themselves tech companies. If you’re interviewing for a software engineering or strats role there in 2026, the pipeline itself is more standardized than that headcount suggests — a HackerRank online assessment, one or two live technical screens, and a final round the firm calls a Superday.

The bar is real but not exotic. This isn’t a place that asks you to invent a novel algorithm under pressure. It’s a place that wants to know you write correct code, reason about a system auditors will read, and stay calm when a trade breaks at 4pm on a Friday. Here’s how each stage works and what gets tested at each one.

First cut: the HackerRank OA, then HireVue for students

For most software roles, the opening gate is a HackerRank test: two problems at LeetCode easy-to-medium difficulty, inside a 60 to 90 minute window, sometimes preceded by a block of aptitude questions on logic and pattern recognition depending on the track. Think arrays, strings, hash maps, a stack question, maybe one tree or graph traversal. Passing the hidden test cases matters more than a clever one-liner — write the brute force, get it green, then tighten it if time allows.

Students and new grads see extra steps layered on. JPMorgan’s Software Engineer Program runs candidates through the HackerRank OA, then a recorded HireVue video interview with behavioral prompts, and — for shortlisted applicants — Code for Good, the firm’s weekend hackathon where teams build software for nonprofits. It’s a real recruiting funnel, not a PR exercise: strong performers get fast-tracked straight into summer analyst and full-time software offers.

The technical screen: CoderPad, one resume deep-dive, Java internals

Clear the OA and you land a live screen with an engineer, usually in a shared editor like CoderPad or HackerRank’s collaborative mode. Expect one or two medium problems and a real conversation about a project on your resume. If you say you built something, be ready to explain the design decisions and what you’d change now.

Java questions show up constantly here, since Java and Spring run most of the consumer and payments org. A few that recur:

• What’s the difference between HashMap and ConcurrentHashMap, and when do you reach for the second one? They want you to name that HashMap isn’t thread-safe and can corrupt or spin under concurrent writes, while ConcurrentHashMap locks at the bucket level so reads stay fast and writes stay safe without wrapping the whole map in one lock.
• Explain == versus .equals() and how hashCode() ties in. Say that == compares references while .equals() compares value, and that the contract is any two objects equal by .equals() must return the same hashCode(), which is exactly why breaking it silently breaks map lookups.
• How does the JVM decide what to garbage collect? Talk about reachability from GC roots rather than reference counting, and mention the generational split between a young and old generation that lets short-lived objects get collected cheaply.
• What problem does Spring dependency injection actually solve for you? The point is decoupling: a class declares what it needs instead of constructing it, so you can swap implementations and inject mocks in tests without rewiring the code.

Superday: PR review, a design round, and a behavioral bar

The final stage packs three or four 45-to-60-minute interviews into one day, historically onsite at a tech center, still frequently run virtually depending on the location and team. Candidates who’ve been through it recently describe the coding slot itself split into two pieces: roughly ten minutes reviewing an actual pull request for bugs and style problems, then a LeetCode-medium problem to solve live. Beyond that there’s a design round for anything above entry level, and at least one behavioral conversation.

Take the behavioral round seriously. At a regulated bank, your interviewer genuinely cares whether you’ll follow change controls, own a production incident, and work with a team of thirty rather than three. “Tell me about a time you shipped something that broke in production” is a real question, and “I’ve never broken anything” is the wrong answer. Coding prompts on the day look like this:

• Given an array of integers, return the indices of the two numbers that sum to a target. The clean answer is one pass with a hash map storing value-to-index, checking for target minus the current value as you go, which is O(n) instead of the O(n²) double loop.
• Find the length of the longest substring without repeating characters. This is a sliding window: expand the right edge, and when you hit a repeat, move the left edge past the previous occurrence, tracking the max window length in a single pass.
• Count the number of islands in a grid of 0s and 1s. Run a DFS or BFS flood fill from each unvisited 1 and mark every connected cell so you don’t count it twice; the number of times you launch a fill is the island count.
• Design and implement an LRU cache with O(1) get and put. The standard answer pairs a hash map for lookup with a doubly linked list for ordering, moving a node to the front on access and evicting from the back when full.

Strats, quant devs, and the Athena stack you inherit

Strats at JPMorgan are quantitative developers who sit close to the trading desk in the markets and Quantitative Research businesses. The role is heavy Python, and it lives on a platform called Athena: a firm-wide, cross-asset system for pricing and risk built around a live dependency graph, conceptually similar to Goldman’s SecDB. The scale is real — Athena runs on something like 35 million lines of Python spread across more than 150,000 modules, built up by well over a thousand developers over the platform’s life, with C++ doing the speed-critical work underneath and Python providing the flexibility. You won’t be tested on Athena itself since you learn it on the job — new strats and QR hires spend their first months getting fluent in it — but the interview signals whether you can think the way it demands: clean Python, comfort with data, and probability you can reason through out loud.

Probability and expected-value questions are standard for strats and QR:

• You’re hashing keys uniformly at random into a table with 1,024 buckets. About how many insertions do you expect before you hit the first collision? This is the birthday problem wearing a hashing costume: the expected number of insertions before a collision lands around the square root of pi times m over 2, which for m = 1,024 works out to roughly 40 — nowhere near the 512 most candidates guess on instinct. Walk through why: after k insertions, the odds every key landed in its own bucket is a shrinking product of terms, and that product crosses 50% around the square root of m, not the halfway point.
• A bag has 3 red and 5 blue balls. You draw two without replacement. What’s the probability both are red? Walk it as conditional probability: 3/8 for the first red times 2/7 for the second, which is 3/28.
• You roll a die once. You may keep the value or re-roll once and take the second value. What’s the optimal strategy, and the expected value? Reroll only when the first roll is below the average of 3.5, so you keep 4, 5, or 6 and reroll 1, 2, or 3, giving an expected value of 4.25.
• Write a Python function that finds the two most frequent elements in a list, and give its time complexity. Reach for collections.Counter and its most_common(2); counting is O(n) and interviewers will ask you to state that rather than sorting the whole list.

None of this requires stochastic calculus for a developer-track strat role. Conditional probability, expected value, Bayes, and clear Python get you most of the way. Desk-quant and QR researcher roles go deeper into stochastic processes and derivatives math, so calibrate to the exact posting.

System design for SE III and VP: payments, reconciliation, rate limits

For Software Engineer III and Vice President roles, expect a design round anchored in the firm’s actual problems rather than a generic “design Twitter” prompt. Common shapes: a payments backend that has to be idempotent and fully auditable, an end-of-day trade reconciliation service, a rate limiter for an internal API, or a market-data distribution fan-out. Talk about consistency, retries, idempotency keys, and how you’d prove correctness to an auditor. That last part is what separates a bank design answer from a startup one.

Regulated-bank engineering: process, scale, and five days in office

It’s a regulated bank, and that shapes the day. You’ll deal with change management, SDLC gates, mandatory code review, and audit trails on production access. That’s more process than a startup and less than the horror stories suggest. In exchange you work on scale that’s hard to find elsewhere: the Chase mobile app serves tens of millions of customers, and the payments rails move trillions of dollars a day, where a bug isn’t a bad tweet, it’s real money.

The firm has spent years migrating onto public cloud (AWS) alongside its internal private cloud, so a lot of teams are doing genuine modernization rather than babysitting mainframes, though legacy still exists in corners. Stack-wise it’s Java and Spring across most of consumer and payments, Python for strats and data, and React or Angular on the front end. Since 2025, JPMorgan has been on a five-day in-office policy under Jamie Dimon, so factor that in.

Your experience depends heavily on your team and your location. JPMorgan concentrates engineering in tech centers including Columbus, Plano, Jersey City, Houston, Glasgow, Bournemouth, Hyderabad, Bengaluru, Buenos Aires, and Warsaw. Glasgow alone runs out of a roughly 270,000-square-foot site with around 2,600 staff and pulls in about 75 graduate hires a year, making it one of Scotland’s largest tech employers in its own right. A payments team in Plano and a markets strats desk in New York are almost different companies. Interview for the group, not the logo.

What the money looks like

Base salaries are competitive, especially at the mid level in lower-cost tech centers. The real difference from big tech is the bonus. Banks pay a cash-weighted annual bonus, and at senior levels a slice of it gets deferred into restricted stock or cash that pays out gradually over the following few years, rather than the large annual RSU grants that push Google or Meta total comp higher. At entry and mid levels the gap is small. At senior and staff-equivalent levels, big tech usually pulls ahead on total comp because of equity. These are rough US ranges; check levels.fyi and Glassdoor for the current numbers on your specific title and city.

JPMorgan level (US tech role)	Corporate title	Approx. base salary range	Approx. total comp range (base + bonus)
Software Engineer II / new grad	Analyst	$85k–$130k	$100k–$155k
Software Engineer III (mid)	Associate	$115k–$170k	$140k–$215k
Lead Software Engineer (senior)	Vice President	$160k–$230k	$200k–$330k
Lead / senior manager	Executive Director	$200k–$300k+	$260k–$450k+ (bonus-dependent)

Treat every cell as an estimate, not a quote. Bonuses swing hard with the firm’s results and your desk, and markets-facing strats roles can pay well above the software bands in a strong year. The numbers move enough year to year that you should verify before you negotiate.

Where to spend your prep time

Grind LeetCode easy and medium, weighted toward arrays, strings, hash maps, two-pointer and sliding-window patterns, and basic tree and graph traversal. You do not need to memorize hard dynamic programming for most software tracks. If you’re going for a Java role, refresh the collections framework, concurrency primitives, and enough Spring to explain what dependency injection buys you. For strats, drill probability and expected value until you can talk through them without freezing, and write clean Python fast.

Then do the part most candidates skip: know the business line. Read what the group actually builds, have a real answer for why JPMorgan over a pure tech job, and be ready to describe a production problem you owned end to end. Practice at least one problem in a shared editor with someone watching, because typing while explaining is a separate skill from solving alone. The people who do well here treat it as an engineering job at a bank, not a bank that happens to employ engineers.