Forward-Deployed Engineer Job Description Template and Interview Scorecard

What should a forward-deployed engineer job description include?#

Six-month outcomes, responsibilities framed as ownership rather than tools, the minimum evidence you will ask candidates for, a published interview loop with its time cost, the scoring dimensions, and the working conditions. Disclose pay, work mode, and travel. Those are the three things a candidate cannot infer and will otherwise guess wrong.

The complete template is below, rendered in full rather than locked behind a form. It is also available as a Markdown file if you would rather paste it straight into your applicant-tracking system.

What real postings disclose#

Before the template, the disclosure baseline. I opened and recorded ten Forward Deployed Engineer and Forward Deployed Software Engineer postings by hand on July 19, 2026 and published them in the FDE market tracker. Across those ten:

• Nine disclosed a pay range. Three of the nine attached a qualifier: one was a San Francisco base-pay range, one combined published base ranges across IC6 to IC8, and one was described as an estimated base salary. Qualifying a range costs one clause and prevents a bad-faith conversation later.
• All ten stated a work mode. Four hybrid, two on-site, two remote, one remote-first, and one remote or hybrid. Four of the ten permitted remote work in some form, and none stated an absence of location or hiring-jurisdiction restriction.
• Eight stated a travel or field expectation. Five gave a percentage. One gave a cadence of roughly two weeks per month on-site. One said the majority of time is in the field without a number. One described on-site visits as the exception rather than the norm.
• Seven named at least one programming language; three named none. The three without a language named delivery, integration, and infrastructure capability instead.
• Titles were not uniform. One used Forward Deployed Software Engineer, one hyphenated Forward-Deployed Engineer, four used Forward Deployed Engineer exactly, and four carried a qualifier such as a city name, AI Platform, Software, or Product Focus.

Two practical implications. Publishing a qualified range is the majority behavior in this sample, so an unqualified posting looks evasive next to its competition. And if you use a non-standard title, expect candidates searching one spelling to never see it.

The template#

Replace every bracketed field. Everything below is meant to be edited, not pasted verbatim.

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.

Requirements, separated by type#

Split this section in two, because conflating the halves is what produces the unreadable stack-list posting.

Non-negotiable on day one. Production coding and code review, systems judgment under ambiguity, clear written and verbal communication with non-engineers, accountable delivery through rollout, and [the one domain or regulatory constraint that genuinely cannot be learned here].

Learnable in the first month. [Your model provider], [your orchestration library], [your CRM or system of record], and your internal deployment tooling. Naming these as learnable widens the candidate pool without lowering the bar.

Working conditions to disclose#

• Compensation: [range], [scope of that range: single location, single level, or combined levels], [equity], [bonus].
• Work mode: [on-site, hybrid with a stated number of office days, remote-first, or remote], plus [the countries or regions you can hire in].
• Travel: [percentage or cadence], and what triggers it.
• On-call: [expectation], and who shares the rotation.
• Customer access: what systems, data, and environments the role will hold.

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.

The interview loop#

Publish this loop in the job description, including the time cost. Candidates who cannot commit the time should learn that before stage one, and the transparency itself is a hiring advantage.

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. Do not use real customer code, credentials, or unpaid production work.

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.

The scoring rubric#

Score each dimension from 1 to 4. Require written evidence for every score, recorded before the debrief so the loudest voice in the room does not set the number.

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.

Before you publish#

Run the description against four checks.

1. Could a strong candidate tell what they would own in six months? If the answer comes only from the responsibilities list, the outcomes section is not doing its job.
2. Have you separated non-negotiable from learnable? A merged list reads as a wish list and filters out the people who would have been strongest.
3. Have you disclosed pay scope, work mode, and travel? Nine of ten reviewed postings published a range and eight stated travel. Silence on either is now conspicuous.
4. Does the title match what candidates search? Four spellings appeared across ten postings. Pick the one people type, and put the variant in the body text.

Related reading#

How to hire a forward-deployed engineer covers the process around this template: the outcome scorecard, red flags, and the full-time versus contract decision. The interview questions post supplies the questions for each loop stage and what a strong answer contains. The salary post covers what the reviewed postings disclosed about pay. For the role boundary, see the definition in the complete field guide.

I have not held the FDE title, and this template is not endorsed by any company in the reviewed dataset. It is my synthesis of what those postings publish and twelve years of shipping and operating production software across mobile, web, backend, Rust, encrypted systems, and applied AI. If you are hiring for this shape of work and want a candid read on whether an FDE is what you actually need, send me the workflow, current stack, users, and the decision you need to reach.