Module 12Take-homeBoth kinds of role

Take-homes and presentations

Scoping a time-boxed take-home, full-stack prototypes a non-engineer can use, the written deliverable, the walkthrough and demo, using AI within the rules, the live build with AI tools, and presenting past work.

8 lessons
1 h 26 min
All in Pro
8 of 8 live
Both kinds of role

By the end of this module you can

Scope a time-boxed take-home and ship a cut list with it
Build a prototype a non-engineer can run in one command
Write a README, a design doc and a decision memo a reviewer can grade
Walk through, demo and defend the work

What employers publish about take-homes

OpenAI publishedOpenAI’s interview guide says its skills-based assessments vary by team and may include take-home projects. Source 1Interview Guide | OpenAI (read through the r.jina.ai reader proxy; a direct fetch returned 403)PublisherOpenAISource typecompany hiring page
Teleport publishedThe Kubernetes challenge Teleport lists for FDE candidates starts with a design document to be approved early and ends with a walkthrough call. Source 2Deploy a service in Kubernetes (challenge)PublisherTeleport (gravitational/careers on GitHub)Source typecompany job posting
Notch publishedNotch published an FDE home assignment with TypeScript tasks for a support agent, including creating a return label through an API that starts the request, then polling it until the label is ready. Source 3fde-task: Forward Deployed Engineer Home AssignmentPublisherNotch (get-notch on GitHub)Source typecompany website
ELITH publishedELITH published an FDE challenge that asks for a bounded improvement inside an existing product, submitted with an FDE decision memo. Source 4ELITH LOCK: FDE Challenge 2026PublisherELITH (elith-co-jp on GitHub)Source typecompany website

No employer publishes a pass rate or a round weight.

The lessons

8 lessons, 1 h 26 min of reading. 8 of 8 live today.

12.1Take-homes in FDE loops: what is published and reported11 minProLive

You can classify a take-home brief by shape, separate its effort from its window, predict the review that follows, and fill a one-page brief sheet before you start.

What it covers

What employers say: “may” means ask
Six shapes, and what to polish first
Effort against window
What comes after you submit
Reading your own brief: the brief sheet

Key takeaways

Read the brief for its shape, and polish first the file that shape makes central.
Plan to the hours of effort, not the days of window, and write your hours in the README.
Prepare for the review you’re told about, and make the README stand alone for the one you’re not: Ethyca publishes a walkthrough call, and one Adobe candidate reported never presenting.
Ask at most three questions, each with the default you will use.

Practice

4 more planned.

Do this now

Answer ‘What would you change with another day?’ about your last take-home or project

12.2Scoping a time-boxed take-home11 minProLive

Given a take-home brief, you can write a one-page scope note before any code that says what you will build, skip and measure, and when you will stop.

What it covers

Reading the brief for the grader
The scope note
What to skip on purpose: the skip test
The thin end-to-end version, in a take-home
Stopping on time

Key takeaways

Write the scope note before any code.
Build the thinnest end-to-end version first, then deepen one part.
Say what you skipped and why; one published brief asks for a complete, smaller solution over an ambitious fragment.
Stop at the time box and write up.

Practice

4 more planned.

Do this now

Say your scope note out loud, then code only the thin path

12.3The prototype a non-engineer can use: full-stack take-homes12 minProLive

In a time-boxed take-home you can ship a small deployed web app that a non-technical user can run, starting in one command, with a short note on what you cut.

What it covers

What published briefs ask for: portals, dashboards, assistants
Choosing a stack you can finish inside the time box
The one screen the user needs first
Putting the model or API behind it safely
Running it in one command: a Makefile or a hosted link
What to cut, and how to say so
Show it failing, on purpose

Key takeaways

Briefs published on GitHub, and candidates’ repos, show full-stack builds: a client portal, a question-answering web app, a deployed assistant.
When we checked them, C3 AI’s and Adobe’s FDE postings described full-stack work.
Build the one screen the user needs first, then make it run in one command.
Ship a cut list with the build: what you left out, and why.

Practice

5 more planned.

Do this now

Sketch the one screen for a spreadsheet import a non-engineer can use

12.4The written deliverable: README, design doc and decision memo11 minProLive

You can write a README a reviewer can run and judge without you, a one-page design doc that gets approved before you build, and a decision memo that says what you chose, what you cut and why.

What it covers

What published briefs ask you to write
The README: run it, then prove it
The design doc: problem, constraints, options, decision, risks
Getting a design approved before you build
The decision memo and the cut list
The client version of the scope note

Key takeaways

Published briefs ask for writing: Teleport wants a design document approved in the first days, ELITH an FDE decision memo, and AzurePartners scores written answers.
Prove the README from a clean clone with no API key before you submit.
A README says how to run it in one command and shows evidence that it works, pasted from a run anyone can repeat.
A decision memo names the choice, the best case for each option you rejected, and what you cut.

Practice

4 more planned.

Do this now

Write a one-page decision memo for the duplicate webhook fix

12.5The walkthrough and the demo: structure, defense and a timed pitch11 minProLive

You can give a structured walkthrough of your submission and defend each major choice against a skeptical reviewer.

What it covers

The structure of a live walkthrough
Demo first or design first
Defending a choice: the defense map
When the reviewer finds a bug
A timed pitch to someone playing the customer
Knowing your audience, and switching mid-review

Key takeaways

Show the result running before the architecture.
Prepare a defense map: the other option’s best case, your deciding constraint, and the seam where it would plug in.
When the reviewer finds a bug, agree, reproduce it with a failing test, fix it, and rank it; never relabel a miss as a cut.
Ask who the audience is; one candidate reported being told one audience and asked to present to another.

Practice

3 more planned.

Do this now

Defend one choice from your last take-home as if to the customer’s architect

12.6Using AI in a take-home: disclose, log, defend9 minProLive

You can follow a take-home’s AI rule, keep a record of what the assistant did, and defend every line in the walkthrough.

What it covers

Reading the rule for this assessment
When AI is forbidden: a workspace that shows it
When AI is expected
Keeping a log git can print
Defending generated code: the random-line drill

Key takeaways

Classify the rule for this assessment: forbidden, allowed, expected, or required with a record.
When AI is off, turn it off in the workspace and say so in the README.
When it is on, leave a record git can print: trailers on assisted commits and a log of your overrides.
Be able to explain any line a reviewer points at.

Practice

4 more planned.

Do this now

Answer how you use AI tools, with one place it was wrong

12.7The live build with AI tools: plan, build, review11 minProLive

In a timed build with your own AI tools, you can state a plan and scope cuts out loud, get a working core running, judge generated code before you keep it, and defend the path to production in review.

What it covers

What Sierra publishes, in one paragraph
Other live formats, and what they share
Your setup, before the day
The spoken plan: users, scope, what you will cut
Building with an assistant without losing the thread
Judging generated code before you keep it
The demo and the review: a ranked path to production

Key takeaways

Sierra publishes its engineering onsite, not an FDE-specific loop, in three parts (plan, build with the candidate’s own AI tools, review) and shares evaluation criteria and advice in advance, including that it’s OK to cut scope and skip boilerplate such as CRUD and auth.
Ramp’s director of engineering said on a podcast that some of its interview questions didn’t allow AI yet, that this was changing, and that Ramp wanted candidates using their on-the-job tools in every interview.
One OpenAI Deployment Company FDE, speaking personally on a podcast, said he would assess how candidates orchestrate agents, build feedback loops and build their own tools.
Scope cuts, a working core and judgment about generated code are what you can show; practice all three against a clock.

Practice

5 more planned.

Do this now

Run a timed build with your assistant and explain every change

12.8Presenting a past project to a technical panel10 minProLive

You can present a past project in a short, timed presentation with the problem, the architecture, your decisions, what broke and what you would change, and defend each under follow-ups.

What it covers

Where past-project presentations show up
Choosing the project
The structure of a timed presentation
Handling deep questions: the ledger, the numbers, ten times the load
Confidentiality

Key takeaways

Two candidate reports from Cognition’s FDE process describe past work under scrutiny, one a project presentation and one a deep unpacking of past roles, and a former Ironclad leader called presenting a past problem Ironclad’s most effective FDE interview tactic.
Pick a project where you made the decisions and can source the numbers, and that a newcomer can follow from one sentence and one diagram.
Show what broke, how you found out, your part in it, how your own safeguard let it through, and what changed.
Prepare a sanitized diagram; never show a current or former employer’s confidential material.

Practice

3 more planned.

Do this now

Give the presentation on your own project and take the follow-ups

Preview a Pro lesson

Lesson 12.111 minProLive

Take-homes in FDE loops: what is published and reported

You can classify a take-home brief by shape, separate its effort from its window, predict the review that follows, and fill a one-page brief sheet before you start.

What it covers:

What employers say: “may” means ask
Six shapes, and what to polish first
Effort against window
What comes after you submit
Reading your own brief: the brief sheet

The recruiter’s email has a PDF attached and a deadline at the end of next week. Before you pick a framework, read the brief for three answers: its shape, its hours of effort against its days to submit, and who will open what you send. The free post on FDE take-homes tables the published briefs; this lesson turns yours into one filled sheet and a short list of questions.

What employers say: “may” means ask

You can find out which format your team uses before you plan a single hour. OpenAI’s interview guide says assessments vary by team and “may include” take-home projects. Source 1Interview Guide | OpenAI (read through the r.jina.ai reader proxy; a direct fetch returned 403)PublisherOpenAISource typecompany hiring page Cohere’s careers page says “you may be asked to complete a take-home assignment.” Source 2Careers | CoherePublisherCohereSource typecompany hiring page ElevenLabs’ careers FAQ says steps vary by role, sometimes with a skills assessment such as a take-home or case study. Source 3Careers at ElevenLabsPublisherElevenLabsSource typecompany hiring page

Each page describes the whole company’s hiring, not an loop, and none promises a take-home: OpenAI and Cohere say “may”, and ElevenLabs says “sometimes”. So ask in writing before you block out your week:

“Which format does this team use for the technical step: a take-home, a build with you in the room, or a presentation? Is the time box hours of work or days to submit? And what follows it: a call, a recorded walkthrough, or neither?”

Practice

Questions

Client scenarios

3 planned

Coding drills

1 planned

Take-homes

8 planned

Locked behind Pro

Every lesson in Module 12 is in Pro, the first lesson included, with its preview and practice.

Get Pro

Onsite this week?

Do these first. Each is live and free.

The evidence behind this module

The plan for this module cites 67 claims: 33 from employers' own pages and postings, 29 candidate reports, 2 press reports, 1 from our own counts and public data and 2 from prep sites, labeled as such. How we source what we say.

What Pro adds to this module today

8 of 8 Pro lessons live, and the rest as they ship.
Model answers to 13 questions this module practices Pro

See Pro and pricing

Questions about Module 12

Is Module 12 free?

No. Every lesson in Module 12 is in Pro, the first lesson included.

How long is Module 12?

8 lessons, 86 minutes of reading in all, plus the practice each lesson ends with.

Is Module 12 written yet?

Yes. All 8 lessons are live.

Which kinds of FDE role is it for?

Both: roles at AI labs and AI product companies, and roles at enterprise software and data companies.

Sources

Interview Guide | OpenAI (read through the r.jina.ai reader proxy; a direct fetch returned 403) OpenAI, company hiring page
Deploy a service in Kubernetes (challenge) Teleport (gravitational/careers on GitHub), company job posting
fde-task: Forward Deployed Engineer Home Assignment Notch (get-notch on GitHub), company website
ELITH LOCK: FDE Challenge 2026 ELITH (elith-co-jp on GitHub), company website