All learning paths, roadmaps & 5 AI interviews free till 5 Nov · Prices go up on 4 Nov
See plansAnatomy of an FDE Interview Loop
Each FDE interview round recreates a piece of the job. See how reported loops and AI-tool rules differ by company, and turn your target list into a prep plan.
A round list that looks arbitrary until you map it
Ask three people who have interviewed for FDE roles what the loop was like and you may get three different lists: one had a take-home and a recorded walkthrough, one had a decomposition case and no AI allowed, one spent two hours building with whatever tools they liked. It is tempting to conclude there is no pattern and just prepare for coding. The rounds are less random than they look. An FDE loop is the job cut into one-hour slices. Each round recreates something you would do in a week on site, and scores the signal that predicts doing it well.
| On the job | Round that tests it | Signal scored |
|---|---|---|
| A sponsor hands you a vague goal | Decomposition / ambiguous case | Structured thinking: user, data, MVP, metric |
| First calls with the customer | Customer discovery role-play | Listening, reflecting back, handling skepticism without overpromising |
| Writing the glue and data jobs | Practical coding or data wrangling | Working code, edge cases, extending it when requirements change |
| Designing the LLM system | Applied-AI system design | Starting from requirements, failure modes and evals; cost and latency |
| Shipping fast with AI tools | AI-assisted build (plan, build, review) | Planning, verifying output, owning every line |
| Inheriting someone's codebase | Debugging, re-engineering or learning round | Tracing one input, forming a hypothesis, ignoring red herrings |
| Owning it when it breaks | Behavioral, project deep dive, hiring manager | Ownership under ambiguity, "I" over "we", honest failure |
Read that way, the three different lists above are three different samples from the same table. The loops reported below each draw between three and six of these round types, start with a recruiter call, and in several cases put a take-home or an online assessment before the onsite. The newer additions are the AI-assisted build and the round set in unfamiliar code. Both mirror work the accounts below describe at AI-native employers: steering coding agents, and reading systems you did not write.
How reported loops differ by company
No single loop is canonical, so the useful question is how far to trust each company's reported version. The table below summarizes reported loops as of the research date (2026-10-03). Confidence comes from how many independent sources agree; only Sierra's is written by the company.
| Company | Reported loop | Confidence |
|---|---|---|
| Palantir (FDSE) | Recruiter, technical screen (live or HackerRank), onsite of three 60-minute rounds drawn from five (decomposition almost always, plus learning, coding, re-engineering, system design), hiring manager. About 15 to 20 minutes of behavioral inside coding and design rounds. AI tools prohibited. (Aced, Blind) | High on structure |
| OpenAI | Recruiter, a take-home of about a week (working code, running app, recorded walkthrough), live deep dive on it, 60-minute coding, system design, project deep dive, behavioral (Aced, IGotAnOffer) | High on take-home and coding, medium on details |
| Anthropic | One account: technical use-case screen with Claude and MCP, multi-stage coding, hiring manager, solution design, values round with non-technical evaluators (Aced). Another adds a customer-conversation simulation and a 3 to 4 hour take-home (getperspective) | Medium; sources conflict |
| Sierra | Paid async take-home, then an onsite of Plan, Build (about 2 hours, any AI tools) and Review; a 60-minute system design that replaced the coding phone screen; project deep dive and behavioral. A debugging round on a draft PR is in pilot (Sierra's own blog) | High: company-authored |
| Databricks | Recruiter, technical screen (SQL, explaining a RAG workflow), 60-minute notebook coding, 60-minute decomposition, leadership and values. Candidates reportedly get a PDF listing all six interviews (Aced) | High |
| Scale AI | Online assessment, recruiter, technical screen, onsite of five: credo (behavioral), coding, debugging, system design, hiring manager (Aced) | Medium-high |
| Google Cloud | Coding and algorithms, a "vibe coding" round on an ambiguous production-style spec, agentic and ML system design, Googleyness (Aced) | Medium: one aggregator |
| ElevenLabs | CodeSignal assessment, live coding in a shared doc, a case study on Excalidraw that expects discovery first, founder or CTO interview; no dedicated behavioral round (Aced) | Medium |
Two things stand out across the rows. Decomposition appears in the Palantir, Databricks and OpenAI accounts, and something close to it at ElevenLabs, while discovery shows up as a role-play or a case. Both are open-ended, and neither yields to grinding practice problems, which is why preparing only for coding is the expensive mistake. And several rows rest on one aggregator, so confirm the details with the recruiter before committing weeks to a guess.
What about companies missing from the table? The research found no usable interview-process evidence for Glean, Decagon, Ramp, Harvey, Retool or Microsoft's FDE roles. If you are targeting one of those, the sensible assumption is a Palantir-style decomposition round plus practical coding and behavioral, held loosely. Label it as a guess in your notes.
The rule that varies most: AI tools
AI-tool rules vary more than anything else in a loop, and they change what you should practise. Palantir prohibits AI in interviews, per Aced. Sierra's onsite build allows any tooling, per Sierra. Anthropic's own candidate guidance says no AI assistance in live interviews unless they indicate otherwise (Anthropic), while a single blog post reports Claude being allowed in some coding rounds. When a company's own guidance and one blog post disagree, the company's guidance is the stronger evidence, though the honest move is still to ask. Aced notes that Google has not confirmed whether AI assistants are allowed in its FDE loop.
So ask the recruiter about every round, and practise both with and without AI. A candidate targeting Palantir and Sierra in the same month faces a no-AI loop and an AI-native build. Those are different skills: one tests whether you can write it yourself, the other whether you can plan, delegate and verify what a tool produced.
Turning your target list into a prep plan
Build your plan from your target list instead of from a generic loop. Write the three to five companies you will apply to as rows and the round types as columns, then mark each cell from the table above. Any round type that appears in two or more of your targets gets a weekly drill. For a company with no evidence, mark the Palantir-derived default and flag it as a guess.
Do at least a few sessions reading unfamiliar code: the re-engineering and learning rounds hand you 80 to 250 lines with planted red herrings, per the Palantir accounts. Tracing one input end to end under time pressure is a skill that only comes from doing it.
Treat a take-home as two rounds. OpenAI's reported take-home asks for working code, a running app and a recorded walkthrough, followed by a live deep dive with the team; Sierra's is paid and async. Both are then defended live, so a polished build you cannot explain is a weak submission. Before you submit, write down the three decisions you expect to be asked about, the alternative you rejected for each, and the first failure a real customer would hit. Keep the scope small enough that you finish with time to test it on inputs you did not design.
How this shows up in the interview
Knowing the loop pays off at two moments. The first is the recruiter call. Databricks reportedly sends the full round list unprompted; elsewhere a precise question gets you the list and the AI rules: "Could you tell me which rounds are in the onsite, and whether AI tools are allowed in any of them?"
The second is inside each round, where knowing the signal tells you what to spend minutes on. In decomposition, Palantir interviewers reportedly inject new constraints partway through (Aced), so how you adapt counts for more than your first architecture. Google's vibe-coding round reportedly changes requirements mid-session. Palantir's re-engineering code carries planted red herrings, which rewards tracing over guessing. In each case the interviewer is deliberately disturbing your plan, and the credit goes to a sensible revision of it.
A candidate surprised by an open decomposition prompt tends to grab a tech stack. A candidate who expects it opens with the user instead, and says something like: "Before I pick anything, who uses this and what decision changes when they do?"
Check yourself
- You are interviewing at Palantir and Sierra in the same month. What prep split does that imply? Answer: An AI-free loop with decomposition, coding and debugging at Palantir, and an AI-native plan, build and review at Sierra. Practise both modes.
- Why is a single canonical FDE loop misleading? Answer: Reported loops differ by company and year, several rest on one aggregator, and Anthropic's accounts conflict. Treat each company's loop as its own evidence.
- What does an injected constraint in a decomposition round score? Answer: Adaptation. The interviewer wants to see you revise scope or design sensibly, so a perfect first answer matters less than a good update.
- A target company has no interview evidence at all. What should you assume? Answer: A Palantir-style decomposition round plus practical coding and behavioral, labelled as a guess, and confirmed with the recruiter.