# Forward-Deployed Engineer Job Description and Interview Scorecard

Version 1.0 · July 19, 2026 · Prepared by Muhamad J. Akoum · https://akoum.me

Use this as a starting point, then replace every bracketed field with your real workflow, customer, system, and risk context.

## Role outcome

The Forward-Deployed Engineer turns ambiguous customer workflows into safe, adopted production software. This person works directly with users and stakeholders, writes and reviews production code, owns rollout evidence, and returns repeated field learning to the core product.

## First six-month outcomes

- Map [priority workflow] with real users, systems, exceptions, and a measured baseline.
- Ship one narrow production path using real identity, permissions, data, observability, and failure handling.
- Define quality, reliability, security, latency, cost, adoption, and rollback thresholds with accountable owners.
- Reach [agreed adoption or workflow-impact threshold] with [design partner or customer segment].
- Produce the runbook, handoff, and customer-team enablement required for safe operation.
- Convert at least one repeated deployment pattern into a reusable product or platform primitive.

## Responsibilities

- Lead discovery with operators, engineering teams, and accountable sponsors.
- Translate workflows and constraints into a bounded technical plan.
- Build full-stack production software and integrations inside existing systems.
- For AI systems, create representative evals, permissions, human review, observability, and fallbacks.
- Plan canary rollout, feedback collection, adoption, support, and rollback.
- Communicate decisions and trade-offs to technical and non-technical stakeholders.
- Return field evidence to Product, Engineering, Security, and go-to-market teams.

## Minimum evidence to request

- One example of changing the plan after observing the real workflow.
- One production system the candidate built or materially owned.
- One difficult failure, including detection, response, and prevention.
- One customer or user adoption problem the candidate helped resolve.
- One repeated request they turned into a reusable capability.

Do not require confidential code or customer data. Accept architecture explanations, redacted artifacts, public work, and precise verbal evidence with clear boundaries.

## Interview loop

### 1. Evidence review · 45 minutes

Ask the candidate to take one project from first problem signal through production operation. Probe their personal decisions, the evidence available at each stage, trade-offs, failure modes, and what changed for users.

### 2. Discovery simulation · 45 minutes

Give a deliberately incomplete workflow request. Score the questions that reveal users, trigger, systems of record, exceptions, permissions, current baseline, dangerous errors, and accountable owner. Do not reward jumping to a fashionable architecture.

### 3. Existing-system exercise · 90 minutes

Use a small but realistic repository. Ask for a bounded change, a test, and a short handoff. Score how the candidate forms hypotheses, reads local conventions, limits blast radius, communicates uncertainty, and verifies behavior.

### 4. Architecture and risk review · 60 minutes

Ask the candidate to design the production path, including identity, data flow, observability, AI evals where relevant, human approval, rollback, support, and cost. Introduce one changed constraint halfway through.

### 5. Stakeholder handoff · 30 minutes

Ask for a five-minute update to an operator, engineering lead, and executive sponsor. Score whether the candidate separates evidence, assumptions, risks, decisions, and next action.

## Scoring rubric

Score each dimension from 1 to 4. Require written evidence for every score.

| Dimension | 1 · weak | 2 · developing | 3 · strong | 4 · exceptional |
| --- | --- | --- | --- | --- |
| Workflow discovery | Accepts the feature request | Finds some constraints | Maps users, systems, exceptions, baseline, and outcome | Changes the problem definition with decisive evidence |
| Production engineering | Demo-only thinking | Covers the happy path | Designs code, tests, identity, data, failure handling, and observability | Simplifies the system while reducing multiple material risks |
| AI evaluation, if relevant | Relies on impressions | Uses generic metrics | Defines task-specific sets, thresholds, graders, and regression ownership | Connects eval evidence to authority, rollout, and product decisions |
| Judgment | Optimizes one dimension | Names trade-offs late | Makes explicit scope, speed, quality, and risk decisions | Finds a smaller path that preserves the critical outcome |
| Customer communication | Performs or overpromises | Explains the solution | Creates shared clarity across technical and business roles | Surfaces the disagreement or hidden constraint that unlocks progress |
| Rollout and adoption | Stops at deployment | Mentions training | Defines canary, feedback, adoption, support, and rollback | Uses rollout evidence to improve both workflow and product |
| Product leverage | Accepts one-off work | Documents the custom work | Extracts reusable patterns and clear product feedback | Creates a primitive that materially improves future deployments |

## Decision rules

- Define the minimum acceptable score for every dimension before interviews begin.
- Do not average away a serious weakness in production safety, integrity, or communication.
- Use the same exercise, rubric, and evidence standard for every candidate.
- Separate “not demonstrated” from “demonstrated weakly.”
- Record concerns the reference check must resolve.

## Reference-check questions

1. What part of the system or outcome did this person personally own?
2. When did they improve the problem definition instead of only implementing the request?
3. How did they respond when a production assumption failed?
4. Did users adopt what they built? What evidence did the team use?
5. How did they balance one customer's need against product maintainability?
6. What environment helps them do their best work, and where would they need support?

## Candidate-facing transparency

Share the stages, time expectations, scoring dimensions, allowed tools, AI-use policy, and accommodation process in advance. If candidates may use AI in the actual role, test responsible tool use and verification instead of pretending the tools do not exist.

---

Related guide: https://akoum.me/blog/how-to-hire-a-forward-deployed-engineer

FDE role and operating guide: https://akoum.me/forward-deployed-engineer