# The FDE take-home: build an app that runs, then defend every decision in the walkthrough > A candidate who took OpenAI's take-home found that most of the grading seemed to turn on whether you could explain why each choice served the customer's need, not on the code alone. Original: https://fdetimes.net/en/guides/fde-take-home-defend-every-decision/ According to Aced's interview guide, the take-home round for Forward Deployed Engineer roles at OpenAI gives candidates about a week. You must submit three things: working code, a running application and a pre-recorded walkthrough video. Slides are optional. One candidate who took the assignment says the brief was to build a semantic search system over Amazon product data for ChatGPT. Their main takeaway lay elsewhere, though: most of the grading seemed to turn on whether you explained your decisions clearly and tied them back to customer needs. A working app, then, is only what gets you considered further. This guide walks through how to prepare a submission in which every decision has a reason you can defend. The semantic search brief above serves as the running example. ## What you will build, and what you need The end result has four parts: an application with a working link, a README that includes a decision log, a small eval set, and a script for the walkthrough video. You need a deployment platform that produces a public link the grader can open, plus a screen-recording tool. From the first minute, create an empty file called `DECISIONS.md` and keep it open next to your code window. A word on time: do not spend the whole week polishing code. If the candidate's observation is right, explaining decisions carries real weight, so set aside proper time for documentation, evals and rehearsing the walkthrough. ## Step 1: rewrite the brief as the need of a specific person Palantir runs a dedicated decomposition round to test whether you can break a vague real-world problem into buildable parts. That same skill should be the first thing you apply to a take-home, before writing a line of code. For the semantic search brief, picture the customer as a shopper typing something like "giày chạy bộ đi mưa không trơn" (non-slip running shoes for the rain). They do not know product names; they only know what they need. Write that at the top of the README — who the user is, what success means (the right result appears in the top five) and what is out of scope (checkout, personalisation, multiple languages): ```markdown ## What the customer needs - User: a shopper who describes their need in plain words and doesn't know product names - Success means: the right result is in the top 5 results - Out of scope: payments, personalization, multilingual support ``` Check: if a non-technical reader can understand from these three lines what problem you are solving, you can move on. ## Step 2: build a thin slice that runs end to end Do not optimise the embedding step before there is a search box. Build a thin slice: load part of the data, index it, accept a query, return results to the interface, and deploy straight away. The brief asks for a running application, and a working link is worth more than ten features that only run on your machine. Check: open the link in a different browser, type three queries and see results. Only then go back to improving quality. ## Step 3: record decisions as you make them Every time you choose between two paths, write an entry. A guide on fde.academy says the most common mistake in the take-home round is perfect code with no documentation. In the same piece, fde.academy quotes a view from another source: a well-documented 70% solution beats an undocumented 100% one. ```markdown ### Q3: Index only title + description, skip reviews - Why: shoppers describe their need in terms of product features, and that's what the description covers - Trade-off: we miss signals from real-world experience in reviews - If the customer changes their mind: add reviews as a separate field with a lower weight ``` The entry above records the decision (index only titles and descriptions, skip reviews), the reason, the trade-off, and what changes if the customer changes their mind. That last line is where you score points. The candidate mentioned earlier says they prepared not only the reasoning behind the current design but also how they would adjust the system if the customer's needs changed. ## Step 4: prove the system works with numbers According to Aced, OpenAI candidates are prepared to answer how you would measure whether a deployed AI system is working correctly. So do not submit without an eval, however small. Here is a hypothetical example, simplified for clarity. You write 20 queries, each paired with the product you consider the correct answer, then count how many have that answer in the top five. If 14 out of 20 pass, your accuracy is 70%. The six misses are the most interesting part of the video. ```text query, expected_product_id, in_top5 "non-slip running shoes for rainy weather", P0123, yes "headphones for people who wear glasses", P0456, no ``` Check: you must be able to say why each query missed. If many miss because users describe situations while product descriptions list specifications, you already have an improvement to present. ## Step 5: talk about impact in the first five minutes Aced's guide for Cognition advises making clear why the project matters within the first five minutes, and only then explaining how it was built. Applied to the video: open with the shopper's need and the eval number, then open the code. **Key point:** Code gets you into the interview room. The reasoning behind each line is what keeps you there. Remember that your audience may not need technical detail. A view from DataInterview's Palantir guide, quoted by fde.academy, holds that candidates who can code but cannot explain their thinking to non-technical people will struggle badly. Aced's guide also makes clear that the walkthrough exists to show your work meets the customer's need, not to show off code. ## Step 6: rehearse the "why" questions After the video comes a live deep-dive. According to Aced, it centres on customer needs, and interviewers will press you on why you chose your approach. Beforehand, reread your decision log and practise answering each entry in three sentences. Ask yourself the hardest question: if the customer says the results are right but slow, what do you change first? If you have no answer yet, put it plainly in a "not yet done" section of the README rather than hiding it. ## Mistakes that sink a submission that works One is a video that walks through each file in folder order. Worse still is having no eval, so that when asked "how do you know it's correct?", all you can say is "I tried a few queries." Nor should you assume every company sets the same kind of assignment. According to Aced, Cognition's take-home is not a traditional coding challenge: it is done inside the Devin product, involves almost no coding, and the candidate plays the customer. Palantir bans the use of AI throughout its interview process. Read the rules carefully before choosing your approach. ## On a customer site, you will give many more walkthroughs The take-home can be seen as a miniature of the job itself. fde.academy argues that employers care about how you reason through deployment problems, not just how you write code. PostHog likewise lists communication skills for customer discovery and for explaining technical concepts to different stakeholder groups among an FDE's core competencies. So the decision log and eval set should not end with the submission. Put them in your portfolio and describe them on your CV along the lines of "defined success criteria with the customer, measured with a 20-query eval set". If a job description mentions customer discovery or stakeholder work, have that decision log ready as a concrete example when asked. Any architecture will change eventually. What the walkthrough wants to know is whether you can explain to a real customer why the system works the way it does. **Try this week:** - Take an old side project and rewrite its README in four parts: what the customer needs, what you decided, how you measure it, what is not done yet - Write 10 queries with expected answers for a feature you are working on, then score how many the system gets right - Record a five-minute video introducing that project for a non-technical friend, then ask whether they understood why the project matters ## Sources - [OpenAI Forward Deployed Engineer (FDE) Interview Guide | Sample Questions (2026) - Aced (formerly Exponent)](https://www.aced.io/guides/openai-forward-deployed-engineer-interview) - [Forward Deployed Engineer Interview Experience (OpenAI) - Aced (formerly Exponent)](https://www.aced.io/experiences/openai-forward-deployed-engineer-interview-0b9c09) - [Cognition Forward Deployed Engineer Interview Guide | Sample Questions (2026) - Aced (formerly Exponent)](https://www.aced.io/guides/cognition-forward-deployed-engineer-interview) - [Common Reasons Candidates Fail Forward Deployed Engineer Interviews](https://fde.academy/blog/common-reasons-candidates-fail-forward-deployed-engineer-interviews) - [Palantir Forward Deployed Engineer (FDE) Interview Guide | Sample Questions (2026) - Aced (formerly Exponent)](https://www.aced.io/guides/palantir-forward-deployed-engineer-interview) - [Forward Deployed Engineer Job: Resume, Portfolio & Interview Guide](https://fde.academy/blog/forward-deployed-engineer-resume-portfolio-interview-guide) - [WTF is a forward deployed engineer? (and why everyone is hiring them)](https://posthog.com/blog/forward-deployed-engineer)