Tell me about a decision you made that turned out to be wrong. How did you find out, and how fast did you reverse it?

The question asks three things in order: what you decided, how you found out it was wrong, and how fast you reversed it. A close cousin appears in writing: as of September 2026, the application form for one Palantir posting, the New York new-grad Forward Deployed Software Engineer (Commercial) role, asks applicants to describe a time they changed their mind, in 150 words at most. That cap is a useful length check for your spoken first answer: the decision, the signal and the reversal fit in it. Give each of these a sentence or two, and the reversal the most: The decision, and why it was reasonable. The information you had, the alternative you rejected, and why. Keep it short. A decision that was obviously wrong at the time makes a weak story, because the lesson is then “think harder”. The signal. The specific evidence: a metric, a correction log, a user doing something you didn’t expect. Say when you saw it relative to when you decided. The reversal. How long from signal to action, who you told and in what words, what you did about the damage already done, what it cost to unwind, and what you kept. What changed in how you decide. One check or habit you added, and one later time it worked. Put the clock on it out loud: “I saw the correction log on Wednesday, confirmed it Thursday morning, and told the customer that afternoon.” The gap between signal and action is the center of the answer, so give it in days or hours, not “quickly”. Hold back the design of the fix. Name it in a clause; the interviewer will ask for the detail if they want it, and the time is better spent on the signal and the cleanup. Two traps. The first is the humblebrag reversal, where the mistake was being too careful. The second is spending most of your time defending the original call. Give it two sentences, then move to the evidence. If you kept going after the first signal, say why, and say what finally made you stop; sunk cost told plainly is better than sunk cost hidden.

A decision you got wrong and reversed

A practice prompt we wrote. No company or candidate report names it, so it carries no company tag.

How to answer

The question asks three things in order: what you decided, how you found out it was wrong, and how fast you reversed it. A close cousin appears in writing: as of September 2026, the application form for one Palantir posting, the New York new-grad (Commercial) role, asks applicants to describe a time they changed their mind, in 150 words at most. Source 1Apply: Forward Deployed Software Engineer, New Grad - Commercial (New York, NY) - Palantir on LeverPublisherPalantir Technologies (Lever)Source typecompany job posting That cap is a useful length check for your spoken first answer: the decision, the signal and the reversal fit in it.

Give each of these a sentence or two, and the reversal the most:

The decision, and why it was reasonable. The information you had, the alternative you rejected, and why. Keep it short. A decision that was obviously wrong at the time makes a weak story, because the lesson is then “think harder”.
The signal. The specific evidence: a metric, a correction log, a user doing something you didn’t expect. Say when you saw it relative to when you decided.
The reversal. How long from signal to action, who you told and in what words, what you did about the damage already done, what it cost to unwind, and what you kept.
What changed in how you decide. One check or habit you added, and one later time it worked.

Put the clock on it out loud: “I saw the correction log on Wednesday, confirmed it Thursday morning, and told the customer that afternoon.” The gap between signal and action is the center of the answer, so give it in days or hours, not “quickly”.

Hold back the design of the fix. Name it in a clause; the interviewer will ask for the detail if they want it, and the time is better spent on the signal and the cleanup.

Two traps. The first is the humblebrag reversal, where the mistake was being too careful. The second is spending most of your time defending the original call. Give it two sentences, then move to the evidence. If you kept going after the first signal, say why, and say what finally made you stop; sunk cost told plainly is better than sunk cost hidden.

Follow-ups

What the interviewer may ask next, once your first answer is on the table.

What would have had to be true for your original decision to be right?
Who pushed back on the reversal, and what did you tell them?
When did you last use the check you added, and what did it catch?

Where answers go wrong

Picks a decision that was never really theirs, or a mild “wrong” call such as being too thorough, so there is nothing to reverse.
Defends the original decision at length and rushes the signal and the reversal, which are the parts the question asks about.

Answer this in two minutes

Write the answer you would say out loud. The clock starts with your first word.

Compare with the model answer

Illustrative answer about a fictional project

Written in the first person to show the structure. Tell yours from your own work.

I was building lease abstraction for a retail chain that held about 2,400 commercial leases as the tenant; a missed renewal-option deadline cost it the right to renew.

The decision was mine: extract all 40 fields in one language-model pass, not field by field with a rules fallback, which would have cost two more weeks. On the customer’s 50-lease sample it scored 94%.

On Wednesday of the pilot’s first week, the correction log showed renewal dates wrong on 31% of amended leases. Our sample had three amended leases, the portfolio was about 40% amended, and the governing date often sits in a later amendment. I confirmed it Thursday morning on 60 random amended leases and called the head of lease administration that afternoon: “The renewal dates on amended leases aren’t reliable, and that’s my design choice, not bad data. I’m turning off automatic write-back for date fields today.”

I also pulled every date already written back, 212 fields across 61 leases, sorted by nearest deadline, for her team to check first. Two renewal notices due within 60 days had wrong dates.

I kept the single pass for the other fields and rebuilt dates in two stages: find the governing document, then extract from it. On Thursday’s call I’d told her date write-back would come back about a week and a half late; the rebuild took eight working days. On 150 amended leases I hadn’t looked at, date accuracy was 97%.

What changed: in week one I ask what share of the customer’s documents are amended, scanned or unusual, and build the evaluation set to that mix. On my next project, that question showed a quarter were scanned faxes before I wrote any code.

The same story in under 150 words, for a written prompt. The spoken answer above runs longer; this is its written form, with the same decision, signal, reversal and check.

Building lease abstraction for a retail chain, I chose to extract all 40 fields in one language-model pass rather than field by field with a rules fallback, because it scored 94% on the customer’s sample and saved two weeks. In the pilot’s first week, the correction log showed renewal dates wrong on 31% of amended leases: our sample had almost none, and an amendment often holds the governing date. I confirmed it the next morning and told the head of lease administration that afternoon that it was my design choice, not bad data. I turned off automatic date write-back and sent her team every date already written back, nearest deadline first; two renewal notices were wrong. I rebuilt dates in two stages, find the governing document and then extract, and reached 97% on unseen amended leases. Now I build the evaluation set to the customer’s real document mix.