A walking skeleton is the thinnest end-to-end version of a system, linking its main components to perform one small real function, built first and then extended. Alistair Cockburn defines it as “a tiny implementation of the system that performs a small end-to-end function” that links together the main architectural components, so that architecture and functionality can then evolve in parallel (quoted on the C2 wiki). In work we add one condition to that definition: the skeleton runs on the customer’s real data for one named user. It is also how Cursor describes the job: as of September 2026, its FDE postings ask FDEs to ship a fast first version in days, then harden it over weeks with rollout plans and monitoring. Source 1Forward Deployed EngineerPublisherCursor (Ashby job board)Source typecompany job board
Why it matters in interviews
Palantir’s advice for open-ended questions is to deliver a functioning idea first, then expand it afterwards. Source 2Palantir Careers | Navigating Open-Ended QuestionsPublisherPalantir TechnologiesSource typecompany hiring page The walking skeleton is how you do that out loud. A strong candidate states it before the halfway point of a case, in one breath: “A nightly export of the dispatch table into Postgres, a single query for late routes, and one page the dispatcher opens each morning. I’ll fake the delay prediction with a rule; I won’t fake the data.” Then they say what decides the next step: “If the dispatcher opens that page every morning for a week, I replace the rule with a model. If they don’t, I go and find out why before I build anything else.” A weak answer builds one layer deeply, such as a perfect ingestion design, and never reaches a user.
The lesson The walking skeleton: a functioning first version covers choosing the first user, what to fake and when to tear it up.