Build the Production Evidence FDE Interviews Require

Every other page on this site makes you interview-ready. This one is about the thing that actually gets the offer, and it's the one page that has to be honest about its own limit.

The Forward Deployed hiring bar is demonstrated production execution. A resume that lists AI keywords loses to a candidate who can say "I shipped this, real users depended on it, here's what broke and how I knew." Personal-productivity AI use — you use Copilot, you built a weekend chatbot — does not clear the bar, because none of it was ever tested by a real customer under real constraints.

The bar: production AI vs. hobby AI

This is the rubric an interviewer is applying, whether or not they say it. Every row is a question they can ask, and "no" on most of them marks the work as a hobby project.

The gap between the columns is not model sophistication. A simple system with real users and a real constraint beats a clever one that never left your laptop. The interviewer is buying evidence that you have operated something someone depended on.

Before reading on: think of the most impressive AI thing you've built. Score it against the five rows. If it's mostly in the right column, the problem is not your skill — it's that nothing has yet forced your work into the left column. The rest of this page is about arranging that.

How to move your work into the left column

You have a job, or access to a side project. The move is not "build something new in your spare time" — it's to reshape something real so it clears one row at a time.

Start from work that already has a user. The fastest path to the left column is an AI feature inside something people already use — at your job, in an open-source project, for a community you're part of. A user you didn't invent is the hardest column to fake, so start there and let it drag the rest across.

Add one real constraint on purpose. Pick the constraint that makes it production: a latency budget, a cost ceiling, a compliance rule, messy real data instead of a clean sample. One genuine constraint, taken seriously, teaches more than three features. It also gives you the tradeoff you'll be asked to defend.

Instrument it so you can answer "how do you know it's working?" The single most common thing hobby projects lack is a way to know they're right. Add an evaluation — even a small held-out set scored to one number — and a way to watch it in production. The moment you can say "here's how I measured it and here's what I'd do when it drifts," you sound like someone who has shipped.

Write down the tradeoff you made and why. The evidence isn't the artifact; it's your ability to defend the decisions. Keep a short log: the constraint, the option you rejected, the number you optimized, what broke, what you'd do differently. That log is what you'll draw on in every round.

No AI at your job? Create the on-ramp

The section above assumes you have AI-adjacent work to reshape. Plenty of strong engineers don't — you're at a shop with no AI initiative, doing solid work that never touches a model. That doesn't disqualify you; it means your first move is to create the on-ramp. Three ways, best first.

Pitch a pilot at work. Take one real, painful problem at your company to your manager as a small, scoped AI pilot — with a named metric, a fixed budget, and a kill date. This is the fastest route, because a real problem at a real company arrives with the whole left column built in: real users, real data, real constraints. A shipped pilot is the strongest evidence there is. And a rejected pitch, well-argued, is still interview material — you scoped an ambiguous problem, named the risk, and translated it to a business metric, which is most of the FDE job. Write the one-page proposal even if you never send it.

Join the effort that already exists. Most companies have one AI thing limping along — a stalled proof of concept, a team experimenting on the side, a "we should use AI for X" that nobody owns. Get onto it. It's faster than starting cold, because the users and the problem are already there; what these efforts almost always lack is exactly what you'd bring — the production discipline (evaluation, guardrails, a way to know it's working) that turns a demo into something shippable.

Ship a side project that actually clears the bar. The honest hard case. A hobby project doesn't count — so a side project becomes evidence only if it has what hobby projects lack: real users and a real constraint. A chatbot you built for yourself is still hobby AI. A tool that people you didn't recruit actually depend on — an open-source project with real adopters, a deployment you run for a local nonprofit or community — and that you keep working when load or messy data breaks it, is production AI on your own initiative. It's slower than the other two, but it's the path that needs no one's permission.

The reader with no AI at work isn't stuck. The bar is the same; only your starting line is a step further back. Pick one of the three and you're on the on-ramp.

Three shapes, increasing in ambition

These are shapes to point your real work at, not starter kits to clone. Each is deliberately generic; the value comes from pointing it at data and users you actually have.

• The instrumented feature. Take one AI feature in a system that already has users and give it an evaluation and a dashboard. Modest scope; it clears users, real data, and a quality bar at once. This is the highest evidence-per-hour move for someone with a day job.
• The constrained deployment. Take a working prototype and make it survive one hard constraint — run it under a cost ceiling, on messy production data, or with a compliance rule — and document what changed. This clears constraints and gives you a defensible tradeoff.
• The owned outcome. Find a real problem someone has, run the discovery move to find the real one, ship something they adopt, and measure whether it moved their number. This is the full FDE loop in miniature, and the strongest evidence there is — it clears every row.

How to talk about it in the loop

Evidence you can't articulate isn't evidence. In the interview, lead with the constraint and the stakes, not the tech stack:

• Name who depended on it and what was at risk. "Support engineers used this daily; a wrong answer sent a customer down the wrong path." That one sentence clears three rows at once.
• Lead with the measurement. "I knew it was working because I scored it against a held-out set daily and watched the correction rate in production." This is the habit the system-design round rewards, applied to your own work.
• Volunteer the tradeoff. Say what you gave up and why, before you're asked. It signals an engineer who makes decisions and can defend them.
• Be honest about the limit. If the users were internal and few, say so. An interviewer trusts "three engineers relied on it" far more than an inflated claim they can puncture with one question.

The limit, restated

This page targets and frames evidence; it cannot manufacture it. The offer comes from shipping something real. What you can do today is point existing work at the bar, keep the log, and learn to talk about it in the customer's terms.

Next: Interview Practice — Overview — the evidence is targeted; now the reps that make you fast in the room.