How to evaluate a forward deployed engineer

People are not looking for a medal

Search for a forward deployed engineer and you will mostly get job boards ranking OpenAI and Palantir, tool vendors ranking their own stack, and career posts explaining the title. People typing “best forward deployed engineer” are usually doing one of two things: hiring, or telling a consultant from the real job. The job boards do not answer that.

This page is the test I would want run on me. It is also the test I run on the work. It does not rank people. It does not name a winner. It tells you what has to be true of the system before the title means anything.

If you are hiring, use it in the first conversation. If your pilot has stalled, use it on the thing you already have. The questions are the same.

The Monday test

Ask what happens on the first Monday after the builder leaves. Not “is there a deck.” Not “did the prototype impress the steering group.” What writes into the system of record? Who approves it? Who gets paged when an API returns a 500 at 7am? Who on the team can turn it off?

A consultant can leave a recommendation that is correct and still leave you with a demo. A forward deployed engineer is on the hook for the write, the gate, and the runbook. I wrote the shorter version of this in forward deployed engineer vs consultant. The rest of this page is how you inspect the work itself.

Six things that have to be true

This is the order the work has to happen in if the result is still running six months later. It is not a methodology. It is the minimum.

1. Scoped against real data. Not a sample export. The actual table, with the actual nulls, and a workflow where a failure is visible to someone. If they have not seen the production rows, they are guessing.
2. A thin slice, end to end, in production conditions. One path. Shadow mode against what the humans already did. A slide that says “phase 2” is not a slice.
3. Wired to the system of record. The real CRM, job board, or ledger. A side database proves the model can write somewhere. It does not prove anyone will trust it.
4. A human in the approval path. Draft, do not send. The gate stays until the error rate earns its removal, and often it never does. A prompt that says “be careful” is not a gate.
5. It reports its own health. An engine that cannot report failure will fail silently. You want a page, a kill switch, and a log that distinguishes skip from success.
6. Handed over. A runbook, and someone on the team who can operate it. The job is finished when it runs without the person who built it.

If any one of those is missing, you do not have a deployed system. You have a demo with a longer meeting.

What to ask for in the first thirty minutes

You do not need a take-home. You need answers that name a system.

• Which production system did you last write into, and what happened when that write failed halfway?
• What is the system not allowed to do, and is that rule in code or in a prompt?
• Show me the approval step. Who is on it, and what would make you take them off?
• What did you refuse to ship, and why?
• Who operates it now, and what is in the runbook?

The answers I would give are on the deployments: a quote engine that is 100% idempotent on re-run because a vendor UI can strip the completion marker; assistants that return zero sources for out-of-scope queries rather than a refusal message; a mortgage slider that recomputes with zero model calls; a call-to-CRM path that replayed 15 real calls before a prompt change went near production; agents whose saves are refused until a search has actually run; a conversion pipeline with exactly one enabled rule so double-counting is structurally impossible.

Three of those eight run inside businesses I do not own. That is the part of the job worth judging. The rest sit on Emerge Digital and Aquora, where I prove patterns on my own bill.

Guardrails as code, not as instructions

This is the distinction that separates a forward deployed engineer from someone who is good at prompting. A prompt-level rule degrades quietly under pressure. A callback either ran or it did not, and you can see which in the trace.

On the agents I run on Vertex AI Agent Engine, a save is refused until a search has actually run, and anything that looks like outbound is refused until the policy preflight has run. On the quote engine, labour estimates are clamped against the pricebook and the whole job stops on a single file touch. On the knowledge assistants, scope is enforced at the retrieval layer, not asked for in the prompt — leak probes re-run after every index pass.

If the candidate cannot point to a control that fails closed, they are asking you to trust a paragraph.

The numbers that are allowed to be missing

A lot of “evaluate the FDE” advice asks for revenue impact, time saved, or a percentage improvement. Those are easy to invent and hard to attribute. I do not put them on this site. The numbers I will stand next to are operational and traceable: idempotency on re-run, documents indexed and failed, model calls per interaction, calls replayed before deploy, agents live, directory resources verified, quota errors per hour, enabled conversion rules.

Ask for that class of number. If they only have a percentage, ask what was counted and what was left out.

The restraint test

The piece of work I would want to be judged on is not a capability. Building a machine-readable data feed for a property portal meant deriving price statistics per community. Only 47 of 132 had enough underlying sales to survive a minimum-sample test. The other 85 were withheld entirely rather than smoothed, clamped, or averaged into something that looked complete.

A number an agent will cite has to be a number that is true. The honest move is usually to publish less than you can. If the person you are evaluating has never withheld a figure, they have not been close enough to a system of record for the incentives to bite.

Hire or engage

The work is the same either way. I take embedded builds through Emerge Digital — most often four to twelve weeks, sometimes a one-to-two-week diagnostic first — and I am open to a full-time forward deployed role. The first conversation is thirty minutes and free, and it is usually long enough to tell whether there is anything worth doing.

If you came here because you searched for the person who can make a demo survive Monday, start with the systems or book the half hour.