A while back we watched a company hire for a forward deployed role the way you'd hire for a big-tech backend team: two LeetCode screens, a system design round, and a take-home asking candidates to build a rate limiter. They hired the person who aced the rate limiter. He quit in eleven weeks, largely because the job turned out to involve standing in a warehouse asking a shift supervisor why nobody scans returns.
The lesson isn't that take-homes are bad. It's that an FDE hiring take home assignment has to test the actual job, and the actual job is judgment under ambiguity, not algorithm recall from a decade-old textbook.
So, should FDE candidates get a take-home test? Yes, but a specific kind: a short, paid, simulation-style exercise that hands the candidate a messy client brief and asks for a scoping decision, a thin prototype, and a memo explaining what they'd build first and what they'd refuse to build. Generic coding tests predict who's good at generic coding tests. A good simulation predicts who'll still be effective in week three of an engagement, which is the thing you're actually paying for.
Why Generic Coding Tests Miss the Point
Embedded engineering work breaks down to roughly 40% writing code and 60% everything else: extracting requirements from a VP who answers questions with different questions, deciding what not to build, and shipping something by Thursday that a dispatcher will tolerate. A rate limiter exercise tests none of that. It selects for people who practiced rate limiters.
We've seen this filtering error from both sides. Strong embedded engineers fail algorithm screens because they haven't memorized graph traversal since school. Polished interview athletes pass every screen and then freeze the first time a client says "just make it work like the old system, but different." Your interview loop selects for whatever it measures, so measure the job.
What a Good FDE Hiring Take Home Assignment Looks Like
The best version we've used is a half-day simulation. The candidate gets a packet: a two-page brief from a fictional mid-size company (say, a regional HVAC distributor), three contradictory stakeholder emails, a sample CSV of their messy order data, and a hard constraint like "the ops manager is only free for 20 minutes on Tuesday."
Deliverables, due in four to five hours of effort:
- A scoping memo of one page: what you'd build first, what you'd explicitly not build, and the two questions you'd ask in those 20 minutes.
- A thin prototype of the single most valuable workflow, in whatever stack they like. Ugly is fine. Real is mandatory.
- A risk note: the one thing most likely to sink this engagement and how they'd de-risk it in week one.
Notice what's absent: no algorithm puzzles, no framework trivia, no "design Twitter." You're watching how someone behaves when the requirements are contradictory and the clock is rude, because that's Tuesday in the actual job.
Two construction details matter. First, rotate the brief every hiring cycle, because candidates share exercises in the same channels where they compare notes on you, and a leaked brief grades memorization instead of judgment. Second, keep the company fake but the data real: export an anonymized slice from an actual messy system, complete with duplicate rows, missing timestamps, and one column nobody can explain. The candidate who asks about the mystery column is the one you want in the seat.
Grading the Simulation
The rubric matters more than the exercise. Four signals, weighted roughly equally:
- What they cut. Candidates who try to build everything in the brief fail the job's core skill. You want someone who murdered 80% of the scope and can explain the knife work.
- What they asked. The two questions they chose for the ops manager tell you whether they think about workflows or about technology. "How do drivers currently report a failed delivery?" beats "what database do you use?" every time.
- How they communicated. The memo is the deliverable that predicts client survival. Clear writing, honest tradeoffs, no jargon armor.
- What the prototype proves. Not polish. Proof that the one chosen workflow actually works end to end on the messy CSV you gave them.
A candidate who ships a modest prototype plus a razor-sharp memo beats a candidate who ships a beautiful app with no opinion about why it exists.
Write the rubric down before the first packet goes out, and have every grader score independently before comparing notes. It costs twenty extra minutes and it saves you from the loudest voice in the debrief room, which is usually the person with the strongest opinions about tabs versus spaces and the weakest evidence for them.
One more thing: run a live debrief. Thirty minutes where the candidate walks you through their choices, and you push back on one of them. You learn more in that half hour than in the entire written packet, because defending a scope decision out loud is the single most common activity in the actual job. A candidate who revises gracefully under pushback is gold. A candidate who treats their memo as scripture will treat a client's feedback the same way.
Keep It Short, Paid, and Respectful
Three to five hours of effort, maximum. Anything longer and you're selecting for people with free weekends, which correlates with nothing except their current employment situation. Pay a stipend for the time; a few hundred dollars filters out the resentment that poisons your employer brand in a market this small.
Give real feedback afterward, even to rejections, especially to rejections. The FDE world is tiny. The candidate you ghost today is the engagement lead at a partner firm in four years, and they have a long memory and a Slack full of peers. Candidates compare notes on interview processes more than they talk about salary bands, which is saying something given how openly people discuss current forward deployed engineer salary ranges.
Red Flags on Both Sides
Employer red flags, if you're the candidate reading this: a take-home that's clearly free consulting on their real roadmap, a week-long scope, silence after submission, or an interviewer who can't explain what the rubric measures. Walk away. A company that can't design a fair four-hour exercise will not design a fair engagement, and surviving FDE burnout is hard enough at places that respect your time.
Candidate red flags, if you're hiring: gold-plating the prototype while ignoring the memo, asking zero questions about the fake client's business, or a risk note that lists only technical risks. The engagement fails on people and process nine times out of ten, and you want someone who already knows that in their bones.
There's a subtler failure mode worth naming: the candidate who aces your simulation by pattern-matching it. They've read the same blog posts you have, so they perform "scope-cutting" theatrically while missing obvious operational details, like the fact that the fictional distributor's drivers work offline half the day. This is why your brief should include one or two traps only a genuinely curious person would catch. Curiosity about the client's world is the trait you're buying, and it's the hardest one to fake for four straight hours.
Run the simulation, pay for it, grade it on judgment, and close the loop with everyone. Do that for one hiring cycle and your offer conversations get noticeably easier, mostly because candidates arrive pre-sold on how you work. At that point the negotiation is the easy part, and if you need help there, we've written about negotiating the FDE offer that follows too.