By FDE Interview Prep, a SourceStrongAI company

In this post11 sections
  1. Why strong engineers fail this round
  2. Solving before you ask
  3. Assumptions you never say out loud
  4. Designing the platform instead of the first version
  5. A solution no customer could run
  6. Stopping at the first version
  7. Going quiet while you think
  8. Recovery lines to use mid-round
  9. Questions people ask
  10. Keep reading
  11. More from the blog

You can design a distributed system on a whiteboard without notes, and in a decomposition interview that skill can work against you. Handed a vague customer problem, it is easy to build the platform in your head and never say what you would ship first. This post is one narrow piece of the decomposition interview guide: the mistakes, and the sentence that recovers each one mid-round.

Six mistakes can sink this round:

  1. Solving before you ask.
  2. Assumptions you never say out loud.
  3. Designing the platform instead of the first version.
  4. A solution no customer could run.
  5. Stopping at the first version.
  6. Going quiet while you think.

Why strong engineers fail this round

The clearest description of a bad run comes from one person. A Blind user with a Palantir tag, who said they formerly worked there, wrote in March 2025 that a bad performance means not asking questions, making large assumptions without clarifying with the interviewer, misunderstanding the problem before jumping in, giving impractical solutions, and not expanding on or optimizing the original v0. Source 1Palantir FDSE Interview (Blind)PublisherBlind (Teamblind)Source typecandidate report on BlindSource 2Update: interview experience - Palantir new grad FDSE interview (Blind)PublisherBlind (Teamblind)Source typecandidate report on Blind That is one former employee’s view, not Palantir’s rubric.

It does line up with what Palantir publishes. Palantir describes the skill it calls navigating open-ended questions as tackling technical challenges that have multiple possible solutions with different trade-offs. Source 3Palantir Careers | Navigating Open-Ended QuestionsPublisherPalantir TechnologiesSource typecompany hiring page Its advice for the interview is to articulate the alternatives and trade-offs, be pragmatic enough to arrive at a concrete approach, and deliver a functioning idea first, then expand it. Source 3Palantir Careers | Navigating Open-Ended QuestionsPublisherPalantir TechnologiesSource typecompany hiring page

Why would strong engineers trip on that? In remarks reported by Y Combinator’s Lightcone podcast in September 2025, Bob McGrew, introduced as an early Palantir executive, said that for Deltas, which is what Palantir’s careers page calls its FDSEs, Source 4Palantir Careers | Students and Early TalentPublisherPalantir TechnologiesSource typecompany hiring page you want someone who is really good at prototyping, and that the wrong profile is a craftsman who loves getting abstractions exactly right. Source 5The FDE Playbook for AI Startups with Bob McGrew (YouTube auto-generated English captions)PublisherY Combinator, YouTubeSource typerecorded talk or interview He was describing who suits the job, not how an interview is scored. Still, the instinct he names, getting the abstractions right before anything runs, is one that can eat the clock in an open-ended round.

Solving before you ask

What it sounds like. The prompt: a grocery chain wants shorter checkout lines without hiring more staff. You answer, “I’d put cameras over each lane, run a queue-length model and open lanes as lines grow.” It sounds decisive. But you do not know whether lines are long all day or only at the evening peak, whether the stores have self-checkout, or what the chain records about each transaction. You have a solution and no problem.

The former Palantir employee on Blind listed both of these: not asking questions, and misunderstanding the problem before jumping in. Source 1Palantir FDSE Interview (Blind)PublisherBlind (Teamblind)Source typecandidate report on BlindSource 2Update: interview experience - Palantir new grad FDSE interview (Blind)PublisherBlind (Teamblind)Source typecandidate report on Blind A different Blind poster, who had sat a Palantir interview, wrote in July 2022 that “clarifying the question and data schema/source is super important.” Source 1Palantir FDSE Interview (Blind)PublisherBlind (Teamblind)Source typecandidate report on BlindSource 2Update: interview experience - Palantir new grad FDSE interview (Blind)PublisherBlind (Teamblind)Source typecandidate report on Blind

How you notice. You are drawing boxes and the interviewer has not yet told you a single fact you asked for. Or they ask “why that?” and your only answer is a technology.

The recovery line.

“Let me step back. I jumped to a design before I knew what ‘shorter’ means here. Two quick questions, then I’ll come back to this. Is the pain at the evening peak or all day? And what do the stores record about each transaction today?”

It names the mistake once, asks only questions whose answers would change the design, and promises to come back, so the minutes you spent are not thrown away. If you are not sure which questions change the design, the clarifying-questions post ranks them, and Clarify before you solve has you practice the first five minutes.

Assumptions you never say out loud

This is the quiet version of the same mistake: you thought first, but kept the thinking to yourself.

What it sounds like. The prompt: a regional food bank says donated food spoils before it reaches families. You design temperature sensors for the warehouse, because you assumed that is where the food spoils. It might spoil on the trucks, at partner pantries, or because donations arrive a day from their date. Your assumption was reasonable. It was also invisible, so the interviewer could not correct it.

The former employee on Blind named this one directly: making large assumptions without clarifying with the interviewer. Source 1Palantir FDSE Interview (Blind)PublisherBlind (Teamblind)Source typecandidate report on BlindSource 2Update: interview experience - Palantir new grad FDSE interview (Blind)PublisherBlind (Teamblind)Source typecandidate report on Blind

The fix. Say every assumption as an assumption, and write it on the board with a mark beside it, such as [A]. A spoken assumption is a decision the interviewer can correct. A silent one is a bet you did not tell anyone you placed.

The recovery line.

“I’ve been assuming the food spoils in the warehouse, and I never checked that with you. Is that right? If it spoils at the pantries instead, the sensors go, and the first version becomes a daily list for each pantry of what arrived within two days of its date, so they hand that out first.”

Notice the last sentence. It says what changes if you were wrong, which shows the assumption was holding weight.

An assumption that would sink the whole plan is what we call a tripwire. The word is ours. In the room, say “the thing most likely to sink this is ...”. The lesson on labeling assumptions and surfacing failure modes goes further.

Designing the platform instead of the first version

This is the craftsman’s mistake, and the one you can be proud of while you make it.

One Blind poster, interviewing for a Palantir new-grad role in October 2022, reported that the decomposition question asked for a first-cut solution, from 8000 records of London taxi data, that could be built and deployed in a week. Source 6Palantir Learning & Decomposition Interview (Blind)PublisherBlindSource typecandidate report on Blind A week is the budget. Design for it.

What it looks like. The prompt: a city transit agency says its buses are unreliable and riders are leaving, and you have a week with their team. You draw streaming ingestion for GPS pings, a data lake, a real-time arrival model, a rider app and an operations dashboard. Every box is defensible. None of them ships this week, and no box has a person beside it.

Palantir’s advice is the cure: deliver a functioning idea first, then expand it. Source 3Palantir Careers | Navigating Open-Ended QuestionsPublisherPalantir TechnologiesSource typecompany hiring page We call that functioning idea a walking skeleton: the thinnest version that runs end to end, on real data, for one named user making one real decision.

The platformThe first version
Streaming GPS ingestionLast week’s stop-event export
Real-time arrival modelLate stops per route
Rider appOne weekly report for the service planner
Data lakeOne query on a copy of the data

The core of that first version is one query. In SQLite, where scheduled_at and actual_at are timestamps from the agency’s stop events.

SELECT route_id,
       COUNT(*) AS stops,
       ROUND(100.0 * AVG(
         (julianday(actual_at)
          - julianday(scheduled_at)) * 1440 > 5
       ), 1) AS pct_late
FROM stop_events
WHERE scheduled_at >= '2026-09-14'
  AND scheduled_at < '2026-09-21'
  AND actual_at IS NOT NULL
GROUP BY route_id
ORDER BY pct_late DESC;

It gives the share of stops each route reached more than 5 minutes late. Say one thing out loud as you write it: stop events with no actual time are dropped, so you would count them separately, because a bus that never reported may be the least reliable of all. A good follow-up is a second column for stops made more than 1 minute early, since an early bus strands riders too.

Signs you are doing it. You have named more technologies than people. You have said “we’d also want” more than once. You cannot say who would use the thing on Monday.

The recovery line.

“I’ve drawn where this could end up, and that’s too much for a week. Let me cut to what the service planner could use on Monday: late stops by route, from the stop events the agency already exports. Everything else on the board is a later version, and I’ll say what would earn each piece its place.”

Do not erase the board. Circle the skeleton and leave the rest as later versions. The lesson on the walking skeleton covers what to fake in a first version and what never to fake.

A solution no customer could run

The former employee on Blind also listed giving impractical solutions. Source 1Palantir FDSE Interview (Blind)PublisherBlind (Teamblind)Source typecandidate report on BlindSource 2Update: interview experience - Palantir new grad FDSE interview (Blind)PublisherBlind (Teamblind)Source typecandidate report on Blind Impractical does not have to mean technically wrong. It can mean the customer could not run it:

  • it needs data they do not collect;
  • it needs a team they do not have;
  • it needs every frontline worker to change how they work on day one;
  • it needs a sign-off (legal, security, a union) that will not come in time.

The same trap applies in both kinds of role. At an AI company it is an that needs an evaluation set nobody has built, or fine-tuning with no labeled data. At an enterprise software company it is a new data platform when the customer’s IT team can approve one integration at a time.

A worked example from the AI side. The prompt: a bank wants an AI assistant to answer its support tickets.

  • Impractical. Fine-tune a model on past tickets and deploy it to every customer. Nobody knows if past replies are worth learning from, or how to tell when the assistant is wrong.
  • Runs on Monday. The model drafts replies for three ticket types. Support agents approve or edit every draft before it goes out, and the approved drafts become the evaluation set for the next version.

Our check, the Monday test. Before you commit, answer four questions out loud. Who runs it? On what data? With whose permission? Starting when? A gap in any answer is where the plan is impractical.

The recovery line.

“That idea needs labeled data this customer doesn’t have. Here’s the version that runs on what they do have, and how we’d collect labels while it runs.”

This is also where Palantir’s “alternatives and trade-offs” fit. Source 3Palantir Careers | Navigating Open-Ended QuestionsPublisherPalantir TechnologiesSource typecompany hiring page Name the ambitious option and the practical one side by side, say what each costs, and pick the one that runs.

Stopping at the first version

This is the overcorrection. You read the advice above, shipped a thin first version, and stopped, waiting for the next question. The former employee on Blind ended their list with it: not expanding on or optimizing the original v0. Source 1Palantir FDSE Interview (Blind)PublisherBlind (Teamblind)Source typecandidate report on BlindSource 2Update: interview experience - Palantir new grad FDSE interview (Blind)PublisherBlind (Teamblind)Source typecandidate report on Blind Palantir’s advice has two halves, and the second is “then expand it afterwards”. Source 3Palantir Careers | Navigating Open-Ended QuestionsPublisherPalantir TechnologiesSource typecompany hiring page

The fix: a ladder, where each step is earned by what the last one taught. For the bus case:

  1. First version. Late stops by route, weekly, for the service planner.
  2. Next, if lateness is concentrated. Break it down by stop and hour to find where lateness starts.
  3. Next, if it starts at the first stops. A morning alert to dispatch for routes already late early in the run.
  4. Then. Change the schedule on one route and compare it with the routes left alone.

Every step says “if”: evidence drives the ladder, not a feature list. Add one optimization too: what you would change if the planner wanted it every morning instead of every week, or for every stop instead of every route.

The recovery line, for when you notice you have gone quiet after the first version:

“That’s version one. What it teaches us decides version two. If lateness starts at the first stops, the next step is an early alert to dispatch. Here’s the order I’d go in, and why.”

Going quiet while you think

Palantir’s recruiting blog, in an August 2022 post written by recruiting interns for intern and new-grad candidates, advises thinking out loud during the technical interview and sharing questions and observations, so interviewers can see how you approach the problem. Source 7From Pipeline to Prospect: Insights and Advice from Palantir Recruitment (Palantir Blog; archived copy)PublisherPalantir Technologies (Palantir Blog on Medium)Source typearchived company page A long silence gives the interviewer nothing to work with, however good the thinking behind it.

The opposite fails too: a monologue with no check-ins, in which the interviewer cannot steer you away from a wrong turn.

The recovery lines. When you notice a long pause:

“I went quiet there. Here’s where I am: I’m choosing between a weekly report and a live alert, and I’m leaning toward the weekly report because the planner changes schedules once a week. Stop me if that’s off.”

When you need time before you answer:

“Let me think about that for a moment, then I’ll tell you where I land.”

It also helps to say which step you are in as you enter it (“I’m on data now”) and to write each fact on the board the moment you hear it. The lesson on narration, the board and the clock practices both.

Recovery lines to use mid-round

We have not found an employer that publishes how a mid-round recovery is judged, so this is our method, not a rubric anyone scores you against. It has four moves:

  1. Name it once. One sentence, no long apology.
  2. Fix it in the open. Ask the question, state the assumption, or cut the scope where the interviewer can see you do it.
  3. Say what changes. Show which part of the plan the fix touches.
  4. Keep what still holds. Do not start over. Most of your board survives.
When you noticeSay
You designed before asking“Let me step back. Two questions, then I’ll come back to this.”
A silent assumption“I’ve been assuming X. Is that right? If not, Y changes.”
The board is a platform“That’s where it could end up. Here’s what runs on Monday.”
Nobody could run it“That needs data they don’t have. Here’s what runs on what they do have.”
You stopped at v0“That’s version one. Here’s what version two adds, and why.”
You went quiet“Here’s where I am, and what I’m choosing between.”

Before your next practice run

  • Say each recovery line out loud until it comes out without thinking.
  • Pick one prompt and write your first version in one sentence: who uses it, on what data, for which decision.
  • Write the next two versions, each starting with “if”.
  • Run the Monday test on your plan: who runs it, on what data, with whose permission, starting when.

For more on what the round is looking for, read what the decomposition round tests, and for mistakes in the other rounds, the post on common FDE interview mistakes. The free lesson the open-ended round and the method on one page puts the whole approach in one place.

You won’t know which of these six you make until you run a case out loud. The free practice case puts you in front of an AI customer who only tells you what you ask for, so solving before you ask shows up within minutes. It needs a sign-in, and you finish with a scorecard and a verdict. When you want the rest of the decomposition method and the full question bank, see pricing. Pro starts with a 7-day free trial.

GlossaryDecomposition roundAn open-ended interview in which you work out loud from a vague problem with several possible solutions to a concrete approach and a first working version.More on Decomposition roundGlossaryForward deployed engineerA software engineer who builds and ships production systems inside a customer’s problem and environment, accountable to that customer’s outcome.More on Forward deployed engineerGlossaryAgentA system in which a model chooses steps and tool calls to complete a task, within limits the design sets.More on Agent

Questions people ask

What mistakes fail a Palantir decomposition interview, according to posters on Blind?

One Blind user who says they formerly worked at Palantir listed it in March 2025. Not asking questions, making large assumptions without checking them with the interviewer, misunderstanding the problem before jumping in, giving impractical solutions, and not expanding on the original v0.Source 1Palantir FDSE Interview (Blind)PublisherBlind (Teamblind)Source typecandidate report on BlindSource 2Update: interview experience - Palantir new grad FDSE interview (Blind)PublisherBlind (Teamblind)Source typecandidate report on Blind

Can you recover from a bad start in a decomposition interview?

We have not found an employer that publishes how a mid-round recovery is judged. What you can do is fix the problem in the open. Say which assumption you made, check it with the interviewer, and cut back to a first version you can finish in the time left.

Is over-engineering a mistake in an FDE decomposition interview?

Treat it as one. Our method is to name one user, one decision and the data they already have, build the thinnest version that runs end to end, and put every other box on the board down as a later version with the evidence that would earn it.

Keep reading

Guides

Company guides

Lessons

Questions

More in Interview rounds