One FDE drill, worked end to end: the rollout question

FDE New World — Sat, 14 Nov 2026 08:27:18 +0000

Most FDE preparation advice stops at the prompt. You get the interview question, maybe a list of things a good answer "should cover," and then you are on your own.

This article does the whole thing instead. One drill from the FDE Practice Pack, answered twice: once the way strong engineers actually answer it under pressure (and fail), and once the way the loop scores well. Then the rubric, so you can score your own answers the same way.

A note on where this comes from: FDE New World is a research publication. I study the forward deployed engineer loop — job posts, candidate reports, practitioner writing — and turn it into drills. I am not an FDE, and nothing here is a leaked interview question. The drill below is built from what the decomposition stage of the loop consistently tests, according to candidate reports: breaking an ambiguous problem down before solving it.

The drill

Scenario. You have built a support-ticket triage assistant for a logistics company. In offline tests it looks good. The customer's VP of Operations wants it live for all 400 support agents on Monday. It is currently Thursday.

Ask.

Do you ship it Monday? Answer yes, no, or "yes, if" — and state the condition.
Who is in the pilot group, how many people, and why them?
What has to be true at the end of week one for you to widen the rollout?
What is your kill switch — the specific signal that takes it offline, and who can pull it?

You have about ten minutes of speaking time. Go.

The weak answer

"I'd ship it. The offline results are good, and the VP wants it live, so delaying hurts trust. I'd monitor the dashboards closely in the first week — ticket resolution time, CSAT, error rates. If something goes wrong we can roll back. I'd also send the agents a feedback form so we hear about problems early. The pilot idea is nice in theory, but with a committed launch date it's better to launch and iterate."

This sounds like a competent product engineer. It scores badly. Here is why, point by point:

No numbers. "Monitor the dashboards" names no baseline and no threshold. Resolution time compared to what — last week's? Measured how, when agents are simultaneously learning a new tool?
No examples. Not one concrete failure is imagined. What does "something goes wrong" look like for a triage assistant? Misrouted tickets? Plausible-sounding wrong categories that nobody catches because the output looks fine?
No constraints. The VP's Monday deadline is treated as a fact of nature. The 400 agents' current workflow, the escalation path, the union or works-council rules some logistics firms have — none of it exists in this answer.
No week-one success definition. "Launch and iterate" is not a success criterion. There is no state of the world at day 7 that this answer would call a failure.
No refusal. The answer never pushes back on anything. In a role whose entire job is standing between a customer's enthusiasm and a production system, an answer with no "no" in it is a red flag.

Scored on the pack's rubric (0–2 per point): numbers 0, examples 0, constraints 0, week-one success 0, refusal 0. 0/10. That is harsh, and it is the point: in a scored loop, fluent-but-empty fails quietly. Candidates often never learn this is why they were rejected.

The strong answer

"Yes, if — it ships Monday to a pilot, not to all 400.

The pilot. 40 agents: the two teams with the highest ticket volume, plus their team leads. High volume gives us signal fast; team leads in the group means the people who will judge it are inside it. The other 360 keep the current workflow untouched — that is also our control group.

The baseline. Before Monday, we pull last week's numbers for the pilot teams: tickets per agent-hour, first-response time, misroute rate as sampled by leads. Without a baseline week there is nothing to compare Monday against, and I would rather delay two days to get it than fly blind. That is my condition: no baseline, no launch.

Week one success. Three numbers, agreed with the VP before launch: misroute rate no worse than the human baseline, first-response time down at least 15% on pilot teams versus control, and zero Sev-1 incidents caused by the assistant. Hit all three and we widen to 150 agents in week two. Miss one and we hold and fix. That agreement happens on Friday, in writing, not after a bad week.

The kill switch. Two signals take it offline immediately: any ticket sent to a wrong external party — a customer, a carrier — because of a misroute, or a misroute rate above twice baseline on any rolling four-hour window. The on-call engineer and either team lead can pull it; nobody needs the VP's permission at 2 a.m. Rollback is one config flag back to the old queue, tested on Friday.

The refusal. What I will not do is all 400 on Monday — not because the tool is bad, but because if it is bad, we find out with 40 agents and a control group, or we find out with the whole support org and no comparison. The VP still gets a Monday launch, a date for the widen decision, and numbers she can take to her boss."

Scored: numbers 2 (baseline, thresholds, percentages), examples 2 (external misroute, control group), constraints 2 (baseline condition, Friday agreement, tested rollback), week-one success 2 (three named criteria with consequences), refusal 2 (a clear no, with the reason and the alternative). 10/10 — and notice it is not longer because it is cleverer. It is longer on specifics and shorter on adjectives.

The pattern to copy

Every strong decomposition answer we score has the same skeleton:

Numbers first. Baseline before launch, thresholds before opinions.
Real examples second. Name the failures concretely, especially the plausible-looking ones.
Constraints third. Deadlines, people, and permissions are part of the problem, not obstacles to it.
Week-one success fourth. Define it before the work starts, with the person who will judge it.
A refusal fifth. One clear no, with the reason and what happens instead.

If your answer has all five, it is very hard to score below passing. If it has three or fewer, more talking will not save it — different talking will.

Practice it

This drill is one of ten scored drills in the FDE Practice Pack ($9), which comes with the 7-Day Sprint Plan for running them against the clock. If your interview is inside the next two weeks, that is the fastest route from reading answers to producing them:

https://fdenewworld.gumroad.com/l/hscppa?utm_source=devto&utm_medium=article&utm_campaign=fde

If your interview is further out, start free: the FDE Cheatsheet is the one-page map of the loop, the numbers, and the drill framework:

https://fdenewworld.gumroad.com/l/qfkmcq?utm_source=devto&utm_medium=article&utm_campaign=fde

And if you score your own answer to the drill above, reply to this post with your five numbers. I read every reply, and the interesting failure modes end up (anonymised, with permission) in future drills.

— FDE New World