JPMorgan Chase Phone Screen: What It Covers and How to Pass

Most candidates think the JPMorgan phone screen is one call. It's two. Miss that distinction and you'll prepare for the wrong thing and fail the one you didn't see coming.

Two rounds: an async HackerRank assessment, then a 45-minute live technical screen with an engineer. Both are filters with different failure modes. This guide breaks down what each one tests, how evaluators score it, and what a passing performance looks like.

Two Screens, Not One

JPMorgan's screening phase has two distinct stages: a take-home coding assessment and a live technical phone screen.

The OA is asynchronous. You get a link, open HackerRank, solve two problems in 60 minutes, submit. No interviewer. The live screen is a 45-minute session with a senior engineer where you code and narrate simultaneously.

Candidates who only grind LeetCode often pass the OA and then freeze in the live screen. Candidates who only practice verbal communication get filtered by the OA's speed requirement before they ever reach a human. Prepare for both, separately.

Goodbye compiler errors meme: you celebrate fixing compile errors, then linker errors and runtime errors appear

Pass the OA feeling great. Then the live screen introduces itself.

Stage One: The Online Assessment

The HackerRank OA is proctored. Your webcam stays on, the browser locks to fullscreen, and any tab switching gets flagged. Yes, they can see you googling "how to swap two numbers without a temp variable." Plan accordingly.

The format is two problems in 60 minutes, typically one easy and one medium by LeetCode classification. The topics lean toward fundamentals: array manipulation, string processing, hash maps, basic recursion, and sometimes a simple graph or DP problem.

The difficulty level is modest compared to FAANG-style assessments. The bar isn't "can you solve hard problems?" It's "can you solve medium problems reliably, with clean code, before time runs out?"

That last part is the trap. Many candidates solve both problems but don't advance because their solutions were slow or only partially correct. JPMorgan scores these competitively. A complete, correct solution delivered in 25 minutes beats an almost-correct solution delivered in 55. Speed and correctness both count.

What the OA tests

Arrays and strings (frequency counts, two-pointer patterns, sliding window)
Hash maps for O(1) lookup
Recursion and simple dynamic programming
Edge case handling: empty arrays, single elements, negative numbers, integer boundaries

Write clean, readable code even though there's no interviewer watching. Some teams review OA submissions for code quality before extending a live screen invite. Name your variables. Handle edge cases explicitly. Add a comment if your logic isn't obvious. No one is impressed by tmp2.

How to approach it

Skim both problems before starting either. The order matters. If problem 2 is easier, start there. A completed easy problem with full test cases passing is worth more than an abandoned medium.

For each problem: read constraints first, identify the pattern, write a brute force mentally, then optimize before typing. The 60-minute window is tighter than it feels.

Stage Two: The Live Technical Screen

This is where most candidates get filtered. The live screen is 45 minutes with a senior engineer or team lead. You'll be on a video call with screen sharing, coding in HackerRank's paired environment.

The interviewer is watching your process, not just your output. Solving the problem in silence and then declaring done is the fastest way to get a "no hire" writeup.

Format breakdown

Expect two problems: one straightforward (easy to medium), one with a follow-up. The follow-up often extends the first problem, asking you to optimize for time, optimize for space, or handle a new constraint. This is intentional. The interviewer wants to see how you think under constraint changes, not just whether you solved a static problem.

The first 5 minutes are usually a brief intro and problem statement. The last 5 minutes are for questions you want to ask. The 35 minutes in between are yours to manage.

Phase	Duration	What's happening
Intro / setup	~5 min	Brief background, problem statement read
Problem 1	~15-18 min	Clarify, code, test
Problem 2 / follow-up	~15-18 min	Extend or solve new problem
Candidate questions	~5 min	Your turn

What JPMorgan's technical screen actually covers

Data structures and algorithms are the core, but the bar is calibrated toward practical competency, not puzzle-solving expertise.

Reported topics from recent candidates include:

Array and string manipulation (sliding window, prefix sums, frequency maps)
Linked list operations (reversal, cycle detection, merging)
Tree traversal (DFS, BFS, level-order)
Hash map patterns (two-sum variants, grouping by key)
Simple recursion and backtracking
Sorting and binary search on sorted arrays

For senior-level roles (SDE2 and above), the screen often includes one round with design flavor: "how would you structure this class?" or "how does your solution change if the input is a million rows?" These aren't full system design questions. They're probes for whether you can reason beyond the immediate problem.

Java knowledge comes up more often at JPMorgan than at most tech companies. If you're coding in Java, expect possible follow-up questions on HashMap internals, generics, collections, or basic concurrency. Python is also common and carries no such follow-up risk. Use whatever language you're most fluent in, with Java being the one exception where you need depth beyond syntax.

How the Screen Is Scored

Difficulty ratings from candidates average around 2.9 out of 5, where 5 is hardest. For comparison, Google and Meta screens typically rate 3.8 to 4.5. JPMorgan is not trying to stump you. They're trying to confirm baseline competence.

The four things evaluators are watching for:

1. Problem clarity. Do you ask the right clarifying questions before coding? Interviewers flag candidates who jump straight to implementation. A 60-second clarification conversation signals maturity.

2. Approach narration. Talk through your solution before you write it. State the pattern you recognized, the time and space complexity you're targeting, and why. Silent coding is a red flag even if the solution is correct.

3. Code quality. JPMorgan reviews code for financial infrastructure. Readable, correct code with handled edge cases signals that you'd write maintainable production code. Clean variable names and explicit edge case handling matter.

4. Follow-up responsiveness. When the interviewer extends the problem or asks about optimization, candidates who engage and iterate score higher than candidates who defend their first solution. Treat follow-ups as collaboration, not criticism.

The Mistakes That Kill You

How it feels while failing to write basic logic through code: clown at a computer

You practiced for weeks. Now you're staring at a two-sum variant and your brain has left the building.

Jumping to code. This is the most common failure. Interviewers at JPMorgan note it explicitly because they're building software that processes financial transactions. Misunderstanding a requirement at this company has real consequences, and they know it. Ask about constraints. Ask about edge cases. Spend 60 seconds thinking out loud before your fingers touch the keyboard.

Going silent. If you're stuck, narrate the stuckness. "I'm trying to figure out whether I need to handle negative integers here" is better than three minutes of silence. The interviewer is watching your process, and silence produces no data for them to write up.

Optimizing prematurely. Start with a working brute force, state its complexity, then optimize. A candidate who delivers a clean O(n²) solution and correctly identifies the O(n) path scores better than a candidate who fumbles toward an O(n) solution and never finishes.

Language-specific gotchas. If you're using Java, know that HashMap is not thread-safe, and Integer comparison with == breaks above 127 due to integer caching. These are common interview pitfalls. If you're using Python, know your sort stability guarantees and default dictionary behavior.

Not testing your code. Before you declare done, walk through a concrete example manually. Run through at least one edge case (empty input, single element). JPMorgan evaluates whether you test your own work. It's a scored dimension.

How to Prepare for the JPMorgan Phone Screen

Timeline: 3 to 4 weeks of focused prep is enough for most candidates targeting SDE1 or SDE2 roles. The bar is practical competency, not competitive programming mastery.

For the OA:

Solve 30 to 40 medium LeetCode problems across arrays, strings, hash maps, and trees
Practice under timed conditions: 25 to 30 minutes per medium problem
Don't optimize until the brute force passes all test cases

For the live screen:

Practice narrating while you code. This is a separate skill from solving. If you haven't done it, start now. SpaceComplexity lets you practice live voice-based mock interviews with real-time feedback, which directly trains the communicate-while-coding skill that live screens demand. Thinking out loud in a dark room by yourself does not.
Review your chosen language's standard library: common collection methods, sort behavior, built-in data structures
If using Java, review: HashMap vs LinkedHashMap, ArrayList vs LinkedList, basic generics, how equals and hashCode interact

Patterns to prioritize:

Two-pointer (sorted array problems, fast/slow pointer for cycles)
Sliding window (fixed and variable size)
Hash map for O(1) lookup
BFS/DFS on trees
Binary search on sorted input
Basic recursion and DP (coin change, climbing stairs, subsets)

What Passing Looks Like

A passing live screen at JPMorgan looks like this: you ask one or two clarifying questions, state your approach before coding, produce a working solution that handles the main edge cases, explain the complexity correctly, and engage with the follow-up question by iterating rather than deflecting.

You don't need to be fast. You need to be methodical and communicative. The evaluators are not comparing you against Jane Street candidates. They're asking: would this person write reliable code and communicate clearly with their team?

The difficulty rating of 2.9 out of 5 is honest. The problems are solvable. The bar is cleared by preparation, not genius.

Before the screen, also read JPMorgan Chase Software Engineer Interview: Every Round, Decoded for the full picture of what comes after the phone screen.

For general advice on what the technical screen is actually evaluating before your code finishes, The Technical Phone Screen Decides Before You Finish Coding is worth reading.