# FDE interviews reward candidates who say out loud they guessed wrong

> A four-part sentence lets the interviewer hear how you change course when the customer drops a new fact in the middle of the call.

Original: https://fdetimes.net/en/guides/fde-interview-think-aloud-hypotheses/

You are in the final round. The interviewer plays a customer and opens with a vague complaint. Ten seconds later you already have a hypothesis in your head. What gets scored is not only whether that hypothesis is right, but whether you say it out loud, and whether, five minutes later, you are willing to say it was wrong.

This is not a rare scenario. Aced's interview guide describes Cognition's final rounds as live customer simulations, such as a pitch to executives or a case-study call.

Techinterview.org explains that FDE interviews simulate the ambiguity of customer work, so most of the time is spent talking rather than typing code. One of the things these rounds test is whether you can reason aloud while the situation is still unclear.

If you are used to LeetCode-style interviews, where only the final answer counts, you will lose points where you least expect it. Aced puts it plainly: interviewers score how you move towards a solution, not whether you arrive at a particular one. Your job is to make that path audible to the person scoring you.

## Why does a wrong guess earn points?

Think of the round as a debugging session. According to techinterview.org, FDE interviews reward a systematic debugging loop: reproduce the problem, form a hypothesis, narrow it down, then verify the fix.

Google's SRE book describes troubleshooting in exactly that rhythm: repeatedly proposing possible causes and testing them, using an experimental method to keep or eliminate each hypothesis.

In that loop, eliminating a hypothesis is as much a step forward as proposing one. The SRE book also warns against latching on to causes seen in the past. In an interview room, the easiest way to show you do not suffer from that habit is to let the interviewer hear you discard an idea you initially believed.

That is why Aced advises treating your first answer as a draft, revising it as new information arrives, and stresses that going back to revise an earlier decision is a good signal, not a weakness.

Techinterview.org notes that in Palantir-style decomposition rounds, the interviewer deliberately adds a requirement midway to see whether your design bends or breaks. So prepare to receive new facts rather than hoping they will not come.

**Key point:** Interviewers score the path you take to a solution, not just the final answer.

## A sample call, line by line

Imagine the following prompt. The "customer" is the head of operations at a delivery company and says: "The dashboard shows the late-delivery rate has doubled since Monday. I need to know what's going on, now." No spec, no schema, just a worrying number.

A weak candidate goes silent for thirty seconds, then proposes rewriting the pipeline. A strong candidate states a hypothesis out loud and labels it as an assumption, just as Aced advises:

"First, this is only an assumption. Orders may not actually be later; the way 'late' is calculated may have changed, for example a deploy that shifted the time zone. If that's the case, end customers wouldn't be complaining any more than usual. Can I ask: has anyone changed anything in the reporting system since Monday?"

The customer dodges: "I don't know what engineering has been doing. But the call centre has had far more complaints this week."

This moment shows most clearly how you reach a solution. The strong candidate does not quietly switch direction, but says it plainly: "Then let's drop the display-bug hypothesis. If it were just a calculation error, end customers wouldn't be calling the call centre."

Then continues: "Now I'm leaning towards orders genuinely being late. There are two branches: one specific region is slow, or the whole system is slow. I'd check by region first, because if that's right, the scope of the fix is much smaller."

That last sentence follows techinterview.org's advice: at a fork, say why you are choosing this branch.

Then the interviewer drops a new requirement: "My boss needs a report by Friday." The strong candidate updates the plan aloud: today, narrow it down by region and confirm the cause with a specific sample of orders; the root-cause fix can wait until the report is in.

## Write it on the board so the interviewer can keep up

The SRE book advises recording which ideas you have had, which tests you ran and what results you saw. In an interview room, those notes let the interviewer see and trace each step of your reasoning. The board for the call above looks like this:

| Hypothesis | Test | Result |
|---|---|---|
| The "late" calculation changed; orders are not really late | Ask whether the system changed and whether end customers are complaining | Rejected: the call centre is receiving more complaints |
| Orders are genuinely late in one region | Break down the late rate by region or warehouse | Waiting for data |
| The whole system is slow | Check only if the second hypothesis is wrong | Not yet tested |

The "Rejected" row is worth as much as the row waiting for data. It shows you eliminate on evidence, not on gut feeling.

## The four-part sentence and how to practise it

Every hypothesis you voice should have all four parts: "My assumption is X, because Y. If X is true, we'll see Z. To check, I need to ask or look at W." Part Z matters most. Without it, your hypothesis cannot be disproved, and the interviewer has no idea at what point you would change your mind.

When the evidence points the other way, use a three-part rejection: "This rules out X, because it contradicts Z. Moving to the next hypothesis. I'm picking it first because..." The sentence is short, but it shows the interviewer evidence, flexibility and a reason for your priorities.

Techinterview.org suggests a concrete way to practise: run a decomposition round aloud with a friend playing an evasive stakeholder who refuses to give a clear spec. Ask your friend to deliberately offer information that contradicts your first hypothesis, and to throw in an extra requirement at the ten-minute mark.

## The mistakes that sink strong candidates

The most common mistake is thinking in silence. Aced calls silence in decomposition interviews a negative signal, because interviewers cannot score reasoning they cannot hear. You may be thinking exactly right, but on the scorecard it is still blank.

The second mistake is changing direction silently: you start talking about a new hypothesis without announcing that you have dropped the old one. The listener sees you jumping around, not eliminating. The third is apologising when you revise an idea, as if it were a failure, when Aced counts going back to an earlier decision as a plus.

The last mistake is subtler: latching on to a familiar cause, along the lines of "last time it was the cache too", and then bending every new fact to fit it. That is precisely the trap the SRE book warns about.

## Put the skill on your CV

This skill is not just for getting through interviews. At a real customer, the spec is just as vague, and saying clearly what you are ruling out helps everyone in the meeting keep up with you.

When you write your CV or prepare stories for the behavioural round, tell an incident using the three columns above: what you suspected first, which test ruled it out, and what evidence led you to the real cause.

A CV line such as "ruled out a display bug using call-centre data, narrowed the incident to one region in two hours" shows a reader how you work far more clearly than words like "proactive" or "strong thinker".

Next time a hypothesis collapses in front of the interviewer, do not rush to paper over it. Say where it went wrong and which direction you are taking next, because that path is exactly what is being scored.

**Try this week:**

- Ask a friend to play an evasive customer who will not give a clear spec, then work through a 20-minute scenario and record it.
- Listen back to the recording and count how many times you changed direction without saying which hypothesis you were dropping.
- Rewrite an incident you have handled as three columns of hypothesis, test and result, then put a short version on your CV.

## Sources

- [What the forward deployed engineer interview really tests (techinterview.org)](https://www.techinterview.org/post/3233477236/forward-deployed-engineer-interview/?format=md)

- [How to Answer Decomposition Interview Questions: The Definitive Guide (2026) – Aced (formerly Exponent)](https://www.aced.io/blog/how-to-answer-decomposition-interview-questions-the-definitive-guide-2026)

- [Inside the Palantir engineering interview loop (techinterview.org)](https://www.techinterview.org/post/3233476805/palantir-interview-process/?format=md)

- [Effective Troubleshooting – Google SRE Book, Chapter 12](https://sre.google/sre-book/effective-troubleshooting/)

- [Cognition Forward Deployed Engineer Interview Guide | Sample Questions (2026) - Aced (formerly Exponent)](https://www.aced.io/guides/cognition-forward-deployed-engineer-interview)