The take-home walkthrough video: a script that shows your judgment in a few minutes

By FDE Interview Prep, a SourceStrongAI company

In this post11 sections

1. Which take-homes ask for a video, and what they ask it to cover
2. What the video has to prove
3. The script, shot by shot
4. Exact words for the decision and the trade-off
5. The README that goes with it
6. Recording setup in ten minutes
7. Recording mistakes and how to fix them
8. When the submission leads to a live walkthrough
9. Questions people ask
10. Keep reading
11. More from the blog

You finished the build, the tests pass, and the last line of the brief says to record a walkthrough video, so now you are staring at a screen recorder with no idea what to say. A take-home walkthrough video is a short screen recording that shows the problem, runs the core path live and explains the decisions behind it; keep it inside the length the brief sets and spend it on judgment, not on a tour of your files. That means one decision, one trade-off, how you checked it works and what you would do next. This post is one part of the FDE interview guide, and it gives you a shot-by-shot script, the exact words for the hard parts, a README template and the recording mistakes that hide good work.

Which take-homes ask for a video, and what they ask it to cover

Not every FDE take-home or build-to-apply project asks for a video, and the ones that do ask for different lengths and different content. Company-published briefs come first, then candidate reports, which carry less weight.

A few details matter. As of September 2026, Palantir’s Build to Apply postings are for Deployment Strategist roles in US Government: applicants build a Foundry and AIP project as their application and submit within 7-10 days of starting to build. ^{[2, 3]}Source 2Deployment Strategist, Build to Apply - US Government (Washington, D.C.) - Palantir on LeverPublisherPalantir Technologies (Lever)Source typecompany job postingSource 3Deployment Strategist, Build to Apply - US GovernmentPublisherPalantir Technologies (Lever)Source typecompany job posting And a Blind commenter with an HR call scheduled for OpenAI’s AI Deployment Engineer role wrote, in March 2026, that the process included a take-home of about 5 hours with a video walkthrough; they had not taken any round, so read it as the process described to them. ^[11]Source 11Anthropic/OpenAI FDE Interview loop -- same as SWE?PublisherBlind (teamblind.com)Source typecandidate report on Blind

So obey your brief’s length. When it says only “record a walkthrough”, Coframe’s list is a sound default: demo, solution, tools, edge cases, path to production. For what these briefs ask you to build, read the FDE take-home post.

What the video has to prove

The repository shows what you built. The video is where the reviewer hears your reasoning in your own voice, in the order you choose. Build it to make sense to someone who has not read a line of your code.

Sierra publishes how it reviews the build in its onsite: after the build, the candidate demos the work, then the interviewers debate the product flows and choices and review the code to understand technical judgment. ^[12]Source 12The AI-native interviewPublisherSierraSource typecompany blog The same Sierra post says the review also covers the path to production and how the candidate used AI along the way. ^[12]Source 12The AI-native interviewPublisherSierraSource typecompany blog One candidate reported, in August 2026, a Tavily FDE brief that puts the same idea plainly: “We’d rather see a small thing done well than a large thing done loosely.” ^[13]Source 13Tavily - FDE - Take Home AssignmentPublisherazamkhan99 (GitHub)Source typecandidate’s take-home repository

So your video has four jobs:

1. You understood the problem. The customer’s problem, in their terms, not the brief’s first line read aloud.
2. It works end to end. One realistic input goes in, and the result a user would see comes out, live.
3. You decided things on purpose. One choice, the alternative you rejected, and why.
4. You know where it breaks. How you tested it, what failed, and what you would do next.

A video that nails those four in a few minutes beats a longer tour of a bigger build.

The script, shot by shot

This is our script, not a format any company publishes. It assumes a brief with a 5:00 limit; scale the times to yours.

To make it concrete, take a made-up brief: sync a clinic’s appointment spreadsheet with a scheduling API and flag double bookings.

The problem. Open on the top of your README, not your editor. Say who has the problem and what it costs them, then what you built, in two sentences. “The front desk keeps appointments in a spreadsheet and the booking system in the API, and they drift, so patients get double-booked. I built a sync that runs every few minutes and flags conflicts before a patient shows up.” To practice naming a customer’s problem out loud, run the free AI practice case.

The demo. This is the longest shot, and it is the core path only. Start from a state where the tool is already installed and running, then edit one row in the sheet, run the sync and show the conflict flag appear. This is the thin end-to-end version the walking skeletons lesson teaches, shown working. Skip login screens, settings pages and every feature a user would not touch on day one.

One decision. Pick the choice a reviewer is most likely to question, and open the one file or function behind it. Do not scroll. Highlight the lines that matter and talk over them.

One trade-off. Name something you gave up on purpose to fit the time box. The next section has the words.

Evaluation. Show how you know it works: a test run, a small labeled set with a score, or a before-and-after table. Show at least one miss and say what causes it. “I ran it on 40 rows with known answers and it got 37. The three misses are all merged cells, which the parser reads as empty.”

Next steps. Say what stands between this and production, in the order you would do it, and end there. “Before a real clinic uses this: first, retries and alerting when the API is down; second, an audit log of every flag; third, change notifications instead of polling.”

If the brief asks about AI tools, add one line here: which tools, for what, and what you checked by hand. “I used a coding agent to scaffold the API client and the first tests. I wrote the matching logic myself and checked every conflict flag against the 40 labeled rows.”

Exact words for the decision and the trade-off

Judgment shows in these two shots. Use a fixed shape for each.

The decision. Name both options, give a reason tied to this customer, and say when the other option would win.

“I had two ways to match rows to appointments: by patient name and time, or by the booking ID the front desk already types into column C. I used the booking ID, because names are misspelled and times get edited, so matching on them would create false conflicts. If the clinic stopped entering IDs, I’d fall back to name and time with a confidence score, and send low-confidence matches to a person.”

The trade-off. Say what you gave up, what it costs, why that is fine for now, and the signal that means it is time to fix it.

“To fit the time box, the sync polls the sheet instead of listening for changes. That means a conflict can sit unflagged for up to the polling interval. It’s fine for a clinic that books a day ahead. If they start booking same-day slots, I’d switch to change notifications, and that’s the first thing on my next-steps list.”

Three phrases to cut, and what to say instead:

If a reviewer shortlists you, expect these same two moments to come back as questions. Practice them with the free question on what you would change in your take-home, then with defending a design choice as if to the customer’s architect.

The README that goes with it

The video and the README should tell the same story. Keep the README short and put the decisions near the top, where the reviewer looks first.

# Appointment sync

## The problem
Two sentences, in the customer's words

## Watch first
Video: <link> (test it signed out)

## Run it
Two or three commands; sample data

## Built, and left out
- Built: the core path.
- Left out: auth, retries. Why.

## Decisions
- Booking ID, not name: reason.

## How I checked it
Test command, score, known misses

## Next steps
In the order I would do them.

## AI use
Tools, what for, what I checked

The “left out on purpose” list does the most work. It turns a gap a reviewer might count against you into a decision you made. The writing for customers lesson covers the same habit for an executive summary: lead with what the reader needs to decide, then the detail.

On the AI section: briefs differ, so read yours. Coframe’s brief asks you to include every AI tool you used and how it shaped the result. ^[1]Source 1Coframe Forward Deploy — Take-HomePublisherCoframe (GitHub)Source typecompany website ELITH asks for a separate AI Usage Memo. ^[6]Source 6ELITH LOCK: FDE Challenge 2026PublisherELITH (elith-co-jp on GitHub)Source typecompany website One candidate reported, in August 2026, a Tavily FDE brief that asks for a record of how the work was built, such as coding-agent chat history or session logs. ^[13]Source 13Tavily - FDE - Take Home AssignmentPublisherazamkhan99 (GitHub)Source typecandidate’s take-home repository When the brief is silent, the post on whether you can use AI on a take-home covers how to decide and how to disclose.

Recording setup in ten minutes

You do not need special software. Use what your machine already has, unless the brief names a host or tool.

• On a Mac, press Shift-Command-5 to open the screen-recording controls, as Apple’s guide to recording the screen on Mac describes. Choose to record a selected portion so only your window is captured.
• On Windows 11, the Snipping Tool records video: press Windows logo key + Shift + R, per Microsoft’s Snipping Tool guide.
• Resolution. Record at your normal screen resolution, with one window shared, and make the text bigger rather than the recording.
• The test clip. Record about 20 seconds of yourself explaining the first shot, then play it back on your phone. If you cannot hear yourself clearly or read the terminal, fix that before the real take.
• Upload. Use the host the brief names, then test the link, as the last mistake below explains.

Recording mistakes and how to fix them

Leaving no time to record. The video gets whatever minutes are left, and it shows. Even a three-hour brief can budget for this. One published by a GitHub account named brianbrainforge-wq (its link to Brainforge is inferred from the name) sets aside 15 minutes for demo prep and 10 for limitations. ^{[14, 15]}Source 14AI FDE ChallengePublisherbrianbrainforge-wq (GitHub account)Source typecompany websiteSource 15Shared challenge briefPublisherbrianbrainforge-wq (GitHub account)Source typecompany website Fix: put demo prep and recording in your plan from the start, not after the last feature.

Opening on setup. Installing dependencies and walking through environment variables uses the minutes when the reviewer is most attentive. Fix: start with the tool already running, and put setup in the README.

Touring the files. Scrolling every folder shows nothing the repository does not. Fix: open one file, for the decision shot.

Demoing only the happy path. A demo that only shows the happy path leaves the reviewer guessing where it breaks, and they will go looking. Fix: show one input that fails in the evaluation shot and say what causes it.

Unreadable screen. Small fonts and a wide monitor turn into a blur in a browser tab. Fix: record one window, zoom the editor and terminal well past your normal size, and hide the sidebar.

Leaking secrets. An open .env file, an API key in a terminal history or a notification with a colleague’s message ends up in a video you cannot edit once sent. Fix: turn on do-not-disturb, close everything else, and watch the whole recording before you send it. If a key appears on screen, rotate it and re-record; blurring a frame is not enough.

Running long. Going past the limit breaks the one explicit rule in the brief, and the minutes past it may never be watched. Fix: time your dry run, and cut the demo before you cut the decision or the evaluation.

Twenty takes. Chasing a perfect take eats the time you should spend checking the build. Fix: record in shots, cut the dead time between them, and accept small stumbles. Do not cut a failure out of the demo.

A link that does not open. Palantir’s Deployment Strategist Build to Apply postings ask for the video as an unlisted YouTube link. ^[3]Source 3Deployment Strategist, Build to Apply - US GovernmentPublisherPalantir Technologies (Lever)Source typecompany job posting Fix: whatever host the brief names, open your link in a private window, signed out, before you submit.

When the submission leads to a live walkthrough

For some briefs the video is not the end. One candidate reported, in a repo created in September 2026, a brief in which the ~3-minute video is followed by presenting the solution and answering technical questions in an interview. ^[9]Source 9FDE Home Assignment (PDF)Publisherpeerfichman (GitHub)Source typecandidate’s take-home repository Other processes skip the video and go straight to a live review: a GitHub account named AzurePartners published an FDE take-home whose shortlisted candidates get a 45-minute session to walk through what they built and extend it live ^[16]Source 16Take-home: the planning agentPublisherAzurePartners (GitHub account)Source typecompany website, and Sierra’s onsite has the candidate demo the build, then debate product choices and review the code. ^[12]Source 12The AI-native interviewPublisherSierraSource typecompany blog

Treat the video, or your first five minutes, as your opening statement for that conversation:

• Keep the script. Your live walkthrough can follow the same six shots, with more room for questions after the decision and the trade-off.
• Know every line you shipped. If an AI tool wrote a function, read it until you can explain it and change it on the spot. A live extension will land on the code you understand least.
• Prepare the extension points. Pick the two places where a new requirement would plug in, and know which file you would open first for each.
• Narrate while you change code. Say what you are about to try and why before you type. The narration, board and clock lesson drills this under a timer.

When the questions move from the take-home to the rest of your work, it is a deep dive by another name, and the project deep dive post has the drill for it. The script above borrows from three habits the curriculum teaches in full: building a thin end-to-end version first, writing so the reader can decide, and narrating while you work. Start with the free first lessons below.

Questions people ask

How long should a take-home walkthrough video be?

Follow the brief, because briefs differ. Palantir’s Deployment Strategist Build to Apply postings ask for a demo video under 5 minutes, and other briefs set shorter or longer limits. If the brief gives no length, keep it short and cover the problem, the demo, one decision and what you would do next.^{[2, 3]}Source 2Deployment Strategist, Build to Apply - US Government (Washington, D.C.) - Palantir on LeverPublisherPalantir Technologies (Lever)Source typecompany job postingSource 3Deployment Strategist, Build to Apply - US GovernmentPublisherPalantir Technologies (Lever)Source typecompany job posting

What video lengths do candidates report for FDE take-homes?

One candidate reported, in April 2026, an FDE take-home that asks for a 5 to 8 minute walkthrough. Another candidate reported, in September 2026, a brief that asks for a video of about 3 minutes, followed by a presentation in an interview. Whatever yours says is the limit to keep.^{[8, 9]}Source 8Forward Deployed Engineer — Take-Home Assignment (PDF)PublisherJoshOlam (GitHub)Source typecandidate’s take-home repositorySource 9FDE Home Assignment (PDF)Publisherpeerfichman (GitHub)Source typecandidate’s take-home repository

Should I say which AI tools I used in the walkthrough video?

If the brief asks, yes. Coframe’s public FDE take-home asks candidates to include every AI tool they used and how it shaped the result. If the brief is silent, check the company’s published AI rules first, then say briefly what you used and what you checked yourself.^[1]Source 1Coframe Forward Deploy — Take-HomePublisherCoframe (GitHub)Source typecompany website

Should I show code in a take-home video?

Briefly. Show the one piece of code behind your main decision, not a scroll through every file. The reviewer can read the repository; the video is for the reasoning they cannot see in it.

Should my face be on camera?

Only if the brief asks for it. If you add one, keep it small and in a corner where it never covers the terminal, the output or the code you are explaining. Your voice and a readable screen matter more.

Can I edit the video or does it have to be one take?

Unless the brief says otherwise, cutting out dead time such as installs, long waits and false starts is fine. Do not cut a failure out of the demo to make the build look better than it is; show it and say what causes it.

Keep reading

Guides

• The forward deployed engineer interview, round by round

Lessons

• The walking skeleton: a functioning first version
• Writing for customers: executive summaries and the follow-up email
• Narration, the board and the clock

Questions

• Looking at your take-home submission, what would you change with another day, and what did you leave out on purpose?
• In your take-home you chose one approach over the obvious alternative. Defend that choice as if I were the customer’s architect.
• Present a past technical project to a mixed audience of engineers and executives, then take questions.

More from the blog

1. Interview rounds

   Forward deployed engineer take-homes: what real prompts ask for and how to scope yours

   What published and candidate-reported FDE take-home prompts ask for, the deliverables they share, and how to scope yours to the time box.

   11 min readPublished September 2026

2. Interview rounds

   Prompt engineering interview tests: what they look like and how to work under the clock

   What timed prompt-engineering tests for FDE and applied AI roles look like, and a test-first way to work against the clock without guessing.

   10 min readPublished September 2026

3. Interview rounds

   The project deep dive: how to present your own work when they keep asking why

   Present your own project in an FDE deep dive: a five-part structure, a why-ladder drill to run on yourself, and the one slide worth preparing.

   11 min readPublished September 2026

More in Interview rounds, page 4