behavioral-interview

jpmorgan

star-format

decision-making

interview-prep

risk-management

Ace JPMorganChase's Incomplete Information Interview Question

Master the STAR format for JPMorganChase's toughest behavioral question: deciding under uncertainty in high-stakes situations.

August 25, 202611 min read

Share this article

LinkedIn Twitter / X

LinkedIn post (click to copy):

Loading...

The Question That Separates Good Candidates From Great Ones#

Let me be straight with you: when JPMorganChase asks "Tell me about a time you had to make a decision with incomplete information in a high-stakes situation," they are not looking for a story about how you Googled something really fast. This question is a window into how you think under pressure, how you manage risk, and whether you can be trusted to act decisively when the data isn't perfect — which, in financial services, is basically every Tuesday.

I've coached dozens of candidates through JPMorgan interviews specifically, and this question (or a close variant of it) shows up constantly for roles in technology, quant finance, operations, and risk. Here's what the interviewers are really looking for — and how to nail it.

What the Interviewer Is Actually Checking#

Before you even think about crafting your story, understand the signals the interviewer is calibrating against:

Can you identify what you know versus what you don't? This is a core risk management skill. At a bank, operating on assumptions without labeling them is dangerous.
Did you take a structured approach to reduce uncertainty? Panicking and guessing is one thing. Rapidly triangulating the best available data is another.
Did you own the decision — or wait for permission? JPMorgan values leaders who act, not bystanders.
What was your risk mitigation plan if you were wrong? Strong candidates build in checkpoints and reversibility.
Did you communicate clearly under pressure? Finance is a team sport. Even brilliant solo decisions need stakeholder buy-in.

A strong answer demonstrates analytical rigor, clear ownership, calm under fire, and a concrete outcome. A weak answer sounds like: "I didn't have all the info, so I asked my manager and we figured it out together." That tells the interviewer nothing about you.

The STAR Framework — Done Right for JPMorgan#

STAR stands for Situation, Task, Action, Result. You've heard this. But here's the thing most people miss: JPMorgan interviewers are trained to probe between the letters. They're going to ask follow-ups on your reasoning, your alternatives, and your lessons learned. So your STAR story needs skeleton and muscle.

Let me walk you through how to build this out.

Situation — Set the Stakes Immediately#

Don't bury the lede. Open with what was at risk.

"We were six hours from a production deployment window that served 40 million users, and our lead data engineer had just flagged a potential data corruption issue in the pipeline — but couldn't confirm the scope before the window closed."

Notice what that does: the interviewer knows immediately that this is real and consequential. You haven't even told them what you did yet, and they're already leaning in.

Red flag to avoid: Choosing a low-stakes story because you think it's "safer." Interviewers at this level have a finely tuned BS detector. If you say it was high-stakes, it needs to feel high-stakes.

Task — Be Specific About Your Role#

This is where candidates often get vague. Say exactly what you were responsible for deciding — not your team, not your manager.

"As the on-call senior engineer, I had the authority — and the accountability — to decide whether we deployed on schedule, delayed by 24 hours (triggering SLA penalties and downstream partner disruptions), or rolled out a partial deployment to a canary subset while we investigated."

Three options. Clear ownership. The interviewer now knows you understand trade-offs.

Action — This Is Where You Win or Lose the Interview#

This section needs the most detail. Walk the interviewer through your thinking process, not just what you did.

Here's an example structure for the Action section:

Step 1: Rapidly inventory what you know vs. what you don't

KNOWN:
- Data engineer detected anomaly in 2 of 47 pipeline segments
- Anomaly appeared in non-critical user preference data (not financial records)
- Last successful validation checkpoint: 4 hours ago
- Rollback procedure: tested and available, estimated 45 min to execute

UNKNOWN:
- Whether anomaly had propagated to other segments
- Root cause
- Whether anomaly would surface in production or stay dormant

ASSUMPTIONS (labeled explicitly):
- Assuming financial transaction data was clean (based on separate validation layer)
- Assuming canary 5% traffic would surface issues within 30 minutes of deployment

That right there — writing out your assumptions explicitly — is the move that separates a 10x engineer from an average one. And it's exactly what JPMorgan risk culture demands.

Step 2: Consult briefly but decide yourself

You had 15 minutes. You pinged two people: the data engineer (technical read) and the product owner (business impact read). You synthesized, you decided.

Step 3: Choose and explain why

You went with the canary deployment. Here's how to articulate the reasoning:

"The downside of a full delay was concrete and immediate — financial penalties and partner disruption. The downside of full deployment was unknown but potentially severe. A canary deployment was reversible, observable, and gave us 30 minutes of real signal before we committed. Given that the corrupted segments appeared non-critical and we had a tested rollback path, the canary was the highest-information, lowest-irreversibility option."

That's the language of someone who thinks in risk and optionality. JPMorgan will love this.

Result — Be Specific and Honest#

Don't just say "it worked out." Give numbers. Give nuance.

"Canary deployment ran for 22 minutes with zero anomalies surfacing in production. We proceeded to full rollout. Post-deployment analysis confirmed the corruption was isolated and dormant in that context. We documented the gap in our validation pipeline and added a coverage check that's caught two similar issues since. We avoided an SLA breach that would have cost the company an estimated $180K in penalties."

Bonus: you ended with a learning that you institutionalized. That shows maturity.

How to Talk Through This in an Interview#

Here's the actual dialogue pattern I coach candidates to use. Practice this out loud — seriously, record yourself.

Opening (set the stage fast):

"Sure, I have a good example of this from my time at [Company]. This was a situation where I had maybe 20 minutes to make a call that affected [X users / $X in revenue / a compliance deadline], and I didn't have the full picture."

During the action — narrate your thinking:

"The first thing I did was separate what I actually knew from what I was assuming. I've found that when you're under pressure, those two things blur together really quickly and that's where bad decisions come from."

If you start to ramble — self-correct:

"Let me be more specific about the decision point here..."

Closing — invite the follow-up:

"Looking back, I think the key move was treating this as a risk/reversibility problem rather than a pure technical problem. Happy to go deeper on any part of this."

That last line signals confidence and invites engagement. Interviewers love it.

Where Candidates Get Stuck#

I've seen this go sideways in very predictable ways. Here's what to watch for:

Choosing a story where you weren't actually the decision-maker. If your answer includes "so my manager ultimately decided," you've answered the wrong question. Find a story where you pulled the trigger.
Skipping the "incomplete information" part. Candidates get excited about the outcome and rush past the uncertainty. Slow down. Spell out what you didn't know and why that made it hard.
Being vague about stakes. "It was really important" is not stakes. "It affected our Q3 revenue targets and three downstream teams" is stakes.
No mention of risk mitigation. JPMorgan is a risk-management organization at its core. If you made a decision with incomplete information and you had no contingency plan if you were wrong, that's a red flag. Always answer the implicit question: "What would you have done if the decision was wrong?"
Forgetting the learning. Interviewers at this level expect you to have extracted a lesson and applied it. "I learned to always document assumptions" is weak. "I built that into our team's incident playbook and trained three other engineers on it" is strong.

Follow-Up Questions and How to Handle Them#

Once you finish your story, expect to get probed. Here are the most common follow-ups at JPMorgan and how to handle them:

"What would you have done differently?"#

Don't panic — this isn't a trap. It's an opportunity. Pick something real and small.

"I probably would have pulled in the product owner earlier. I waited until I'd done my own analysis first, which cost me about five minutes I didn't have. Having her context upfront would have made my decision faster."

"How did you communicate the decision to stakeholders?"#

This is checking your communication under pressure. Have a crisp answer:

"I sent a single Slack message to the #incident channel with three lines: what we were doing, why, and what the rollback trigger would be. I didn't want people asking questions mid-deployment, so I preemptively answered the three questions I knew they'd ask."

"What if the canary had shown problems?"#

This is checking your contingency thinking. You should have this ready:

"We had a clear trigger: if error rates exceeded 0.1% or any anomaly appeared in financial transaction data, we would execute rollback immediately. I had the rollback script ready to run. The 24-hour delay and SLA penalty was the fallback, not a failure — it was the cost of getting more information."

"How do you know when you have 'enough' information to decide?"#

This is a deeper analytical question. A great answer:

"I think about two things: the cost of waiting for more information versus the cost of being wrong, and whether the decision is reversible. If being wrong is recoverable and the cost of delay is concrete, I'll move on incomplete information. If being wrong is catastrophic and irreversible, I'll pay almost any cost to get more data first."

That answer, right there, will make a JPMorgan interviewer nod slowly. Write it down.

A Note on Quantitative Framing#

JPMorgan loves numbers. Even in a behavioral interview. If you can frame your decision-making in terms of probability and expected value — even informally — you will stand out.

Here's how a candidate might informally quantify their reasoning:

Option A: Full deployment
  - Upside: No SLA penalty ($180K saved)
  - Downside: Unknown probability of data incident (estimated ~15% based on anomaly scope)
  - If incident occurs: estimated $2M+ in remediation + reputational damage
  - Expected cost: 0.15 * $2M = $300K risk exposure

Option B: Full delay
  - Upside: Zero deployment risk
  - Downside: Certain $180K SLA penalty + partner disruption
  - Expected cost: $180K certain

Option C: Canary deployment
  - Upside: Real signal within 30 min, maintains deployment timeline if clean
  - Downside: Small residual risk to 5% of users, rollback overhead (~45 min)
  - Expected cost: Much lower — risk isolated to canary population with fast exit option

You don't need to present this as a formal model. But if you think this way and can articulate it conversationally, you're speaking JPMorgan's language.

Red Flags That Will Tank Your Answer#

Starting with "So basically..." — it signals informality and lack of structure
Taking longer than 3 minutes without being asked a follow-up — you're monologuing, not conversing
Not knowing the outcome in numbers — if you don't know the impact, pick a different story
Saying "we" when you mean "I" — be honest about your contribution, but don't hide behind the team
Showing no uncertainty about your decision — the best leaders acknowledge what they didn't know. Fake confidence reads as arrogance.

Key Takeaways#

Here's what to carry into your JPMorganChase interview:

Choose a story where you were the actual decision-maker — not a participant or an advisor
Explicitly name what you didn't know — this shows analytical discipline, not weakness
Label your assumptions — this is the move that signals risk management maturity
Frame your decision in terms of reversibility and risk — JPMorgan thinks this way culturally
Have a contingency ready — always answer the implicit question "what if you were wrong?"
Quantify your outcome — even rough numbers are better than "it went well"
Invite follow-up questions — it signals confidence and turns the interview into a conversation
Practice out loud at least 5 times — STAR stories that sound polished in your head often ramble in real life

You've got this. The goal isn't a perfect story — it's an authentic one that shows you can think clearly when the stakes are real and the data is incomplete. That's exactly the kind of person JPMorgan wants making decisions in their systems.