Decomposition interview practice, on a real codebase
The round Palantir FDSE and Stripe engineering interviews actually run.
Easiest lab · 45 min · no account needed
Pick a case lab
Debugging and re-engineering
2 labsCode you did not write, plus a bug report. Find the real defect, not the one that looks wrong.
Usage Rollup Double-Count
Palantir · FDSE
A metered-usage pipeline bills some accounts twice. Find out why.
code comprehension · debugging · reading unfamiliar code · deduplication / idempotency
Billing Webhook Idempotency
Stripe · Software Engineer
Subscription webhooks arrive twice and out of order. Make the worker safe.
idempotency · event ordering · at-least-once delivery · billing correctness · decomposition
Decomposition and feature-build
2 labsThe system exists and something is missing. Pin the ambiguity down before you type.
911 Dispatch Optimization
Palantir · FDSE
Rank which responder units to send, with a human still in the loop.
decomposition · ranking under constraints · stale / real-time data · human-in-the-loop design
Ontology Learning Round
Palantir · FDSE
Learn an unfamiliar object graph from minimal docs, then extend it.
learning unfamiliar APIs · reading minimal docs · graph traversal · palantir ontology
Sprint labs
3 workbooksTen sprints on one codebase. The repo remembers what you did, and sprint 9 breaks the code you wrote in sprint 4.
Fixture Demo: Contracts Sprint
A tiny two-ticket workbook that exists to exercise the Sprint Labs content compiler end to end.
1 sprint - 2 tickets - ~2 h - Junior / Mid
typescript · api-contracts
Graded on escaped defect rate: the share of hidden checks that get past you. It goes down over 1 sprint, and that curve is the artifact.
Meridian
Join a multi-tenant claims platform as its third engineer and ship ten sprints of real tickets - contracts, money, tenants, delivery, deployment, and the agent's own PRs included.
10 sprints - 50 tickets - ~58 h - Mid to Senior
typescript · api-contracts · serialization-data-contracts · databases-transactions-rls · concurrency-distributed-systems · containers-environment-parity · cloud-deployment-aws · observability-operations · ai-engineering-production · verifying-ai
Graded on escaped defect rate: the share of hidden checks that get past you. It goes down over 10 sprints, and that curve is the artifact.
Prove It
A cheat-proof research sandbox. Untrusted strategy code runs sealed from the future, and every run can be re-derived byte for byte.
7 sprints - 18 tickets - 12 to 16 h - Senior to staff
Process isolation · setrlimit and seatbelt · Subprocess protocols · Canonical serialization · Content addressing · Durability and torn writes · Determinism · Adversarial testing
Graded on escaped defect rate: the share of hidden checks that get past you. It goes down over 7 sprints, and that curve is the artifact.
Server-side isolated grading and additional languages land next month.
How a case lab works
Every lab runs the same five milestones in the same order. You can move between them freely, and nothing is hidden until you have earned it. Hover, tab to, or tap a step to read what it asks of you.
What is a decomposition interview?
A decomposition interview hands you a problem that is too vague to start coding on, and scores what you do before you start. You ask what “best” is supposed to mean. You name the entities the system actually has and find the bottleneck. You commit to a contract with named inputs and outputs, and you say what happens when the primary path is unavailable. Only then do you touch the codebase.
It is not a system design interview. You are not sizing a fleet or drawing a diagram of services nobody will build. A decomposition round ends in running code inside a repository somebody else wrote, where the design you argued for has to survive contact with the files you are allowed to change and a test suite that either passes or does not.
Who interviews this way
Palantir's forward-deployed engineering loop is the clearest example. It runs a decomposition round on a vague operational problem, a re-engineering round on a codebase you did not write, and a learning round on an API you have never seen and almost no documentation for. Stripe runs the same shape against payments-grade correctness, where the hard part is at-least-once delivery and event ordering rather than the algorithm.
These labs are modeled on that shape. They are original problems written in the same style, not leaked questions. Each lab also names the rounds of that company's loop it does not cover and where to prepare those, because finishing one lab is not the same as being ready for the interview.
Common questions
How do I prepare for a Palantir FDSE interview?
Prepare the rounds separately, because they score different things. The forward-deployed loop runs a decomposition round on a vague operational problem, a re-engineering round on a few hundred lines you did not write with a plausible red herring planted in them, and a learning round on an unfamiliar API documented only by its docstrings. There is also a timed assessment before the onsite.
The three Palantir labs here take one of those rounds each: 911 Dispatch Optimization is the decomposition round, Usage Rollup Double-Count is the re-engineering round, and Ontology Learning Round is the learning round. Each one names the parts of the loop it does not cover, so you can see what is left.
What is the difference between a decomposition interview and a system design interview?
A system design interview asks you to size and shape a system you will never build, and it ends at the diagram. A decomposition interview ends in running code: you scope the ambiguity, commit to a contract, then open an existing multi-file repository and change it until the tests pass.
The overlap is real, which is why both reward naming entities and defending tradeoffs. The difference is what is on the table at the end. A design round scores the architecture you can argue for. A decomposition round scores the ambiguity you resolved and the code that came out of it.
What is the difference between Practice mode and Onsite mode?
You pick a mode before the lab starts. Practice is open and hint friendly. Onsite runs interview conditions: a clock against the lab's estimated time, and a curveball dropped into the Build milestone once your tests have run, which changes a constraint and asks whether your design survives it.
Do I need an account to use a case lab?
No. You can open a lab and work through it without one, including the Build milestone and the test suite, which run in your browser. Signing in is what saves the run so you can come back to it, and the interviewer chat and the written review are AI backed, so those need an account.
Can I move between milestones freely?
Yes. The five milestones always run in the same order, but nothing is locked and nothing is hidden until you have earned it. You can jump ahead to Build, run the tests, and come back to Clarify when the code tells you something the brief did not.
Where to practice next
A lab is an hour of work. These are the shorter routes, and the reading, around it.
- Bug-fix interview practiceShorter debugging rounds against a broken codebase, with the AI interviewer, when you want the Build milestone without the four milestones around it.
- How to practice bug-fix interviewsThe written guide: how to read unfamiliar code under time pressure, and what a debugging round is actually scoring.
- AI mock interviewA timed round with a voice-enabled interviewer, on either a coding problem or a debugging scenario, ending in written feedback.
- Free coursesPython, data engineering, and system design lessons, if the gap a lab exposed is knowledge rather than practice.