How to Answer 'Difficult Technical Decision with Incomplete Data'

Nail the Wells Fargo behavioral interview with a proven STAR-format strategy for answering questions about making tough technical calls under uncertainty.

Why Wells Fargo Asks This Question#

Here's the thing most candidates don't realize — when Wells Fargo asks you "Tell me about a time you had to make a difficult technical decision with incomplete data," they're not just checking if you've been in a tough spot before. They're stress-testing your judgment, your risk tolerance, and your ability to communicate under pressure.

At a financial institution like Wells Fargo, incomplete data isn't an edge case — it's Tuesday. Systems fail, logs get corrupted, a vendor goes dark at 2 AM, and someone still has to make the call. The interviewer wants to know: are you that person?

Let's build your answer from the ground up using the STAR format (Situation, Task, Action, Result), and I'll show you exactly what separates a strong response from a forgettable one.

What the Interviewer Is Really Looking For#

Before you craft your story, understand the scoring rubric in the interviewer's head:

The interviewer is actually checking if you can operate like a senior engineer — someone who doesn't freeze without perfect information, but also doesn't recklessly charge ahead.

Building Your STAR Story#

Situation — Set the Scene Concisely#

Don't spend three minutes on context. Give the interviewer enough to understand the stakes in 30-45 seconds. A strong Situation sounds like:

"We were in the middle of a critical migration of our payment processing service to a new database cluster. Three days before go-live, one of our monitoring dashboards started showing intermittent latency spikes — but only on roughly 15% of queries, and only in production. Our staging environment looked perfectly clean."

Notice what that does: it establishes stakes (payment processing, production), ambiguity (only 15%, staging was clean), and time pressure (3 days to go-live). That's your hook.

Task — Define YOUR Specific Responsibility#

This is where many candidates go vague. Be explicit about what you personally owned.

"As the lead engineer on the migration team, I had to decide: do we delay the launch and potentially cost the business a week of revenue, or do we roll forward with a mitigation strategy while the root cause was still unknown?"

The interviewer needs to know this was your decision to make. Don't say "we decided" if you were the one holding the ball.

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

This section should be 60-70% of your answer. Walk through your actual reasoning process, not just what you did. Here's a framework I coach candidates to use:

The "3-D Decision Framework" for incomplete data:

1. Define what you do know vs. what you don't know
2. Determine the cost of waiting vs. the cost of acting
3. Design a reversible path where possible

Let's say you're describing how you triaged that latency issue. You might say:

"I started by mapping exactly what we knew versus what we didn't. We knew the spikes were isolated to queries hitting a specific shard range. We didn't know if it was a hardware issue, a configuration drift, or a bug in the new ORM layer we'd introduced. Given the 72-hour window, I made the call to go live on schedule but with a feature flag that would let us instantly reroute traffic away from the affected shard range at the first sign of customer impact."

Here's what that feature flag might look like in a simplified implementation — and yes, mentioning something like this in your answer shows technical depth:

# Simplified feature flag check for shard routing
import os
 
SHARD_FAILOVER_ENABLED = os.getenv("SHARD_FAILOVER_ENABLED", "false").lower() == "true"
FAILOVER_SHARD_ID = int(os.getenv("FAILOVER_SHARD_ID", "3"))
 
def get_shard_for_query(account_id: int) -> int:
    primary_shard = account_id % 8  # 8-shard cluster
    
    if SHARD_FAILOVER_ENABLED and primary_shard == FAILOVER_SHARD_ID:
        # Reroute traffic away from the problematic shard
        return (primary_shard + 1) % 8
    

This kind of concrete technical detail — even described verbally — makes your story credible. It shows you didn't just manage the situation, you engineered a solution.

You should also talk about your stakeholder communication. Wells Fargo cares deeply about this:

"I drafted a one-page risk memo to the engineering director and the product owner, outlining the three scenarios — full delay, conditional go-live with failover, or partial rollout to 10% of users first. I recommended option two with a clear rollback trigger: if error rates exceeded 0.5% in the first two hours, we'd automatically divert to the standby cluster."

That right there is gold. You showed initiative, you showed risk quantification, and you showed you didn't make this call in a vacuum.

Result — Numbers, Learnings, Impact#

Always quantify if you can. Fuzzy results feel like you're hiding something.

"We went live on schedule. The latency spikes appeared in the first 20 minutes, but our feature flag routed around them automatically — customers never saw a degraded experience. We later identified the root cause as an index fragmentation issue on shard 3 that only manifested under production load patterns. We fixed it in a hotfix 18 hours post-launch. The on-time delivery saved approximately $240K in delayed revenue, and the incident became the basis for our new pre-migration load simulation protocol."

See the structure there? What happened → customer impact (or lack thereof) → root cause resolved → business value → process improvement.

How to Talk Through This in an Interview#

Here's an example of how to open your answer confidently:

"Sure — I've been in a few situations like this, but the one that comes to mind most clearly is from my time at [Company]. I'll walk you through it using a STAR structure so I stay focused. This happened about 18 months ago during a major infrastructure migration..."

That opener does three things: signals you have multiple examples (you're not scraping), shows self-organization (STAR structure), and anchors a timeline so the story feels real.

If you get nervous mid-story and lose your thread, use this recovery phrase:

"Let me step back — the key decision I had to make was X, and here's the reasoning I used..."

Don't let silence spiral. Interviewers respect candidates who can course-correct calmly.

Where Candidates Get Stuck#

I've seen hundreds of candidates fumble this question. Here are the most common traps:

• Picking a story with no real ambiguity. If you had all the data you needed, that's not the right story. The interviewer will feel it.
• Describing the situation but not the decision-making process. Saying "I didn't have all the info but I figured it out" tells the interviewer nothing. Narrate your thinking.
• Using "we" throughout. The question asks about you. If your team made the decision, find a different story — or be crystal clear about what your specific contribution was.
• Skipping the outcome. Some candidates tell a great story and then say "...and it worked out fine." Fine isn't memorable. Quantify it.
• No reflection or learning. At Wells Fargo especially, continuous improvement is a cultural value. End with what you'd do differently or what new processes emerged.

Follow-Up Questions and How to Handle Them#

Once you finish your story, expect these follow-ups:

"What would you have done if the go-live had failed?" This tests your pre-mortems. Answer: "We had a defined rollback plan. Within the first two hours, if error rates exceeded our threshold, we'd trigger an automated rollback to the previous cluster. I had already drafted the customer communication template and looped in the on-call SRE team."

"How did you get buy-in from leadership with so much uncertainty?" This tests your communication skills. Answer: "I didn't ask for approval by presenting one option. I presented three scenarios with tradeoffs, made a recommendation, and gave leadership a clear rubric for when we'd abort. Giving them decision authority over the abort criteria made them comfortable with the overall risk."

"What data would have made this easier?" This tests technical depth. Have a specific answer:

-- What we wished we had: per-shard query latency histograms in pre-prod
SELECT 
    shard_id,
    PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY query_duration_ms) AS p95_latency,
    PERCENTILE_CONT(0.99) WITHIN GROUP (ORDER BY query_duration_ms) AS p99_latency,
    COUNT(*) AS query_count
FROM query_metrics
WHERE recorded_at >= NOW() - INTERVAL '1 hour'
GROUP BY shard_id
ORDER BY p99_latency DESC;

"If we'd had per-shard P95/P99 latency data in our staging load tests, we would have caught the fragmentation issue before production. That's exactly the monitoring we added post-incident."

That answer is elite-level because you tied the technical gap directly back to your story and showed the organizational learning that followed.

Red Flags That Will Cost You the Offer#

These are the things that make interviewers mentally check out:

• "I escalated it to my manager." This is fine to include, but if escalation was your only action, you've shown you can't operate with autonomy. That's a dealbreaker for mid-to-senior roles.
• "We didn't have time to think it through, so we just shipped." Shipping under pressure is fine. Shipping without any structured reasoning is not — especially at a bank.
• "I can't think of a specific example." Never say this. Every engineer has been in a situation with incomplete information. Prepare 2-3 stories in advance.
• Blaming the lack of data for a bad outcome. Own your decision. If it went wrong, say so, and say what you learned. Interviewers respect self-awareness far more than a perfect story.

Tailoring This for Wells Fargo Specifically#

Wells Fargo operates in a highly regulated environment. When you tell your story, work in one or two of these dimensions if they're authentic to your experience:

• Risk quantification — showing you thought about the financial or compliance cost of a wrong decision
• Audit trail — mentioning that you documented your decision rationale (they love this)
• Customer data protection — if your scenario touched any user data decisions, this is gold
• Cross-functional alignment — showing you worked with legal, compliance, or product stakeholders

You don't need to manufacture these — but if they're genuinely part of your story, surface them. Wells Fargo will prioritize candidates who demonstrate they think about risk the way a regulated institution has to.

Key Takeaways#

On interview day, remember these five things:

• Prepare 2-3 stories in advance that genuinely involve ambiguous technical decisions — don't improvise this one
• Your decision-making process matters more than the outcome — narrate your thinking, not just your actions
• Quantify everything you can — timeline, error rates, business impact, cost of delay
• Show stakeholder communication — Wells Fargo wants engineers who escalate intelligently, not silently
• End with a learning — what process, tool, or habit changed because of this experience?

The candidates who nail this question aren't the ones who've never made decisions with incomplete data — they're the ones who've thought carefully about how they make those decisions. That's the story you need to tell.