Forward deployed engineer job description

A job description for this role has one job: attract the people who will thrive and put off the people who will resign in month four. Most of them do the opposite by being vague about the two things candidates care most about.

The two paragraphs that matter

Which job is this? The analysis of 1,000 postings found the title covers three different jobs: a production engineer embedded with customers at 60 percent, a sales engineer with implementation duties at 30 percent, and an internal tools builder facing no external customer at 10 percent. Candidates know this now. A description that does not say which one it is reads as either careless or evasive.

Say it directly. "You will spend roughly 80 percent of your week writing production code in customer repositories" is a sentence that filters your applicants for you.

How much travel? 68 percent of postings required travel, and where a figure was given, 50 to 75 percent was typical. OpenAI states up to 50 percent on its own postings for the role.

Hiding this does not increase acceptances, it increases early attrition. Put the number in the first hundred words.

There is a third paragraph worth adding even though the data does not name it directly: what happens when the candidate is not travelling. A description that states 50 percent travel but says nothing about the other half leaves the strongest signal of the job unstated. Is the remaining time spent at a home office, at a company office, or at whichever customer site is easiest to reach that week. Candidates who have done this kind of work before will ask, and candidates who have not will assume the better version and be disappointed later. Answer it before they ask.

A template

Adapt it. The comments in brackets are instructions rather than copy.

Title: Forward Deployed Engineer

One-line summary. You will embed with one or two of our enterprise customers, build production software inside their systems, and stay accountable until it runs. [If this is not true, use a different title.]

How the week is split. Roughly 80 percent building, 20 percent with the customer. [State your real number. If it is 40/60, say so and call the role something else.]

Travel: [Your number] percent, in blocks of [days or weeks] at customer sites in [regions].

Compensation: base plus equity, no sales quota. [Across 1,000 postings, 70 percent mentioned equity, 8 percent mentioned commission, and none were quota-carrying. If yours carries a sales target, say so here.]

What you will do

• Work inside a customer's environment, on their real data and their real approval process
• Write and release production code, reviewed and merged in their repository or ours
• Run discovery with the people who will use what you build, and write down what correct means
• Take a system from nothing to running in production, including the security review and release path
• Identify what generalises and feed it back to product [say how often]
• Hand the system over to the customer's own engineers on an agreed date

What we need

• A real engineering foundation. You will pass the same technical standard as our product engineers
• Comfort working without a specification, and the judgment to write one
• The ability to scope a vague problem out loud, in front of people who disagree with each other
• Willingness to say no to work that only ever serves one customer
• Genuine curiosity about how a business actually operates

What we do not need

• Deep expertise in one narrow stack. You will be in unfamiliar systems constantly
• A background in consulting delivery, though it is not a barrier
• [Be honest here. This section builds more trust than the requirements list.]

Stack: [List it. Python appeared in 66 percent of postings and TypeScript in 35 percent, so if yours is unusual, say so early.]

What is hard about this job. [Include this section. Name two real difficulties. Candidates trust a description that admits them, and the ones who are put off were going to leave anyway.]

What to leave out

"Rockstar", "ninja", "wear many hats". The last one is a hidden way of saying the scope is undefined, which is the thing this role already has too much of.

A ten-item requirements list of specific technologies. The role needs generalists who learn unfamiliar systems quickly. A long stack list selects for the opposite.

"Fast-paced environment" as a substitute for the travel number. Candidates read this as an admission you are hiding something.

An inflated seniority label. The data says this role is staffed mid-level: 60 percent of postings targeted three to five years, 20 percent six to eight. Calling it Staff to attract applicants creates a levelling problem you will inherit.

A list of company perks with nothing about the work. A description that opens with unlimited vacation and a stocked kitchen before saying what the person will actually do reads as trying to compensate for something. Lead with the work, because the candidates worth hiring for this role are choosing it for the work more than the perks.

The experience level to actually target

From the same dataset: 12 percent of postings targeted zero to two years, 60 percent three to five, 20 percent six to eight, 8 percent nine or more.

Alongside that, First Round Review reports that ten or more years at a large tech company can be a warning sign for this work, because the role needs people who operate without the support structure of a large company. That is a statement about a specific background rather than about seniority itself.

Previous roles, for sourcing: 45 percent from software engineering, 22 percent from solutions or sales engineering, 15 percent from data engineering or data science, 10 percent from technical consulting, 8 percent founder or early employee.

Write the requirements section to those numbers rather than to a wish list. A description asking for prior forward deployed experience specifically is asking for a small, competed-over pool, since the role itself is still new. A description asking for a strong engineering background plus evidence of working directly with customers, phrased that way, opens the pool to the 45 percent coming from ordinary software engineering roles who have simply never held this exact title before. The skill the role needs, working out what to build inside a company that cannot fully describe it, transfers from several backgrounds. The title does not.

What the interview process should mirror

A job description makes promises the interview process then has to test. If the description says 80 percent building, the interview should include a real coding exercise at the standard the role actually requires, not a conversation about coding. If the description says the candidate will scope ambiguous problems, the interview should hand them one and watch what they do rather than ask them to describe their process in the abstract. Candidates notice when a description and an interview do not match, and the mismatch itself becomes a reason to decline an offer, because it suggests the company does not know what it is hiring for. How to interview a forward deployed engineer covers the process this description should set up.

One line worth copying

If your engineers work with AI-generated code, say what proves it correct. Candidates who are good at this role ask that question in the interview, and a description that answers it first signals you have thought about the part that matters.

Ours reads roughly: the code is AI-written and every change passes an eval suite derived from the specification before it reaches the customer's branch, so the engineering judgment goes into the specification and the verification rather than writing the code.

After you post it

Watch the first week of applications against the description rather than waiting for the whole cycle to finish. If the travel number and the split are stated clearly and the applicant pool still skews toward people asking about remote-only arrangements in their first message, the description is not being read carefully enough, or it is being read carefully and ignored because the rest of the market is vaguer and candidates assume yours is too. Either way, a fast read of the first ten applications tells you more about whether the description is working than any amount of further editing before it goes live.

Next: how to hire for sourcing and signals, and how to interview for the interview process.