A founder I know posted a job for a "forward deployed engineer" last spring. By Friday she had 200 applicants. A week later she had interviewed nine of them and needed a nap. Eight of the nine were consultants who had seen the words "client-facing" and "travel" and dusted off their deck templates. One candidate asked whether the role came with a slide library.

The applicants weren't the problem. The posting was. It read like a consulting job wearing an engineer costume, so consultants applied, exactly as advertised.

What follows is a forward deployed engineer job description template you can copy-paste today, plus the annotation explaining why each piece exists. The template works because it leads with shipping instead of skills, is honest about the messy parts, and quietly gives pure consultants nothing to grab onto. Steal it, change the nouns, post it.

Why Your FDE Posting Attracts the Wrong People

Job descriptions are filters whether you design them or not. A JD full of "stakeholder management," "strategic alignment," and "5+ years of experience" is a filter that passes professional meeting-attenders and stops the person who automated their last client's invoice flow for fun.

Builders read job posts looking for evidence they'll get to build. Deck-writers read the same post looking for evidence they'll get to advise. Every sentence in your posting votes for one of those audiences. Most FDE postings vote wrong because they're copied from a generic "solutions consultant" template and then given an engineer title, which is like labeling a salad "steak" and being surprised vegetarians show up.

The Forward Deployed Engineer Job Description Template (Steal This)

Here it is, section by section. The blockquotes are the copy-paste text; the notes between them are for you, not the posting.

Forward Deployed Engineer

We embed engineers directly inside our clients' operations to build software that fixes the problem this week, not the platform someday. You'll sit with the people doing the work, find the spreadsheet or the manual step that's eating their day, and ship something real against it. Then you'll do it again.

Two sentences of pitch, no adjectives doing cardio. The phrase "ship something real" does the filtering: builders hear a promise, consultants hear a warning.

What you'll do

  • Ship working software to a real client in your first two weeks. Small, ugly, used daily.
  • Spend real time onsite or shoulder-to-shoulder with the people who have the problem, watching how the work actually happens.
  • Own your builds after they ship: the bug reports, the 8 a.m. "it's broken" messages, the fixes.
  • Turn what you learn onsite into the next thing you build.

Note what's missing: "gather requirements," "liaise with stakeholders," "produce documentation." Those are activities. This list is outcomes. The "own your builds after they ship" line scares off exactly the people you want scared off.

What you'll need

  • You've shipped production code that real people used, recently, and you can walk us through it.
  • You can hold a conversation with a warehouse manager in the morning and refactor an API in the afternoon.
  • You're comfortable when the spec is "make this less painful" and the documentation is a sticky note.
  • You write clearly, because your README might be the only manual the client ever reads.

Four requirements, all verifiable in an interview, none of them a years-of-experience incantation.

The honest parts

  • Travel is real: expect to be onsite with clients roughly one week a month, sometimes more at the start of an engagement.
  • The work is ambiguous. Some weeks the hardest problem is a person, not a codebase.
  • You will sometimes ship something you're not proud of yet, because Friday's working version beats next quarter's elegant one.

This section is the one most companies chicken out of. Don't. Honesty about travel and ambiguity costs you a few applicants who would've quit in month three anyway, and it's a magnet for the ones who read "ugly but working" and nod.

Compensation and logistics

Salary range: $X to $Y depending on experience, plus [equity/bonus]. We hire in [locations]. The interview is one conversation about something you shipped, one scoping exercise, and one working session. No take-home exam, no whiteboard trivia.

Yes, post the range. The forward deployed engineer salary data says the band is wide, and builders with options skip postings that hide the number.

Annotated: Why Each Section Exists

The pitch paragraph comes first because it's the only part most candidates read twice. "You'll ship in week one" filters better than any skills list ever written, because it's a claim the candidate immediately tests against their own history. Builders think "finally." Advisers think "that sounds like a lot."

As for the "honest parts" section: it exists because hidden downsides don't disappear; they detonate in month two. Travel honesty in particular is non-negotiable in this role. A candidate who discovers the real travel load after signing is a resignation letter with a delay fuse.

And there's no "5+ years" theater anywhere, because years are a proxy for the thing you actually want, which is evidence of shipped work under ambiguous conditions. A great 28-year-old with four client rescues beats a 40-year-old with fifteen years of tickets. Ask for the evidence, not the birthday.

Requirements That Filter Builders In

The three requirements that do the heavy lifting, and why they're phrased that way:

Notice none of these mention a tech stack. If you're hiring for embedded work and your requirements list reads "React, Kubernetes, GraphQL, 12-factor apps," you've written a software engineer JD and stapled a flight itinerary to it.

What to Leave Out

Deletion is the highest-impact editing move you have. Each of these lines, removed, raises applicant quality:

One client-adjacent team I worked with rewrote their posting this way and watched the pool go from 200 applicants with maybe 12% real builders to 60 applicants with nearly half worth a phone call. Same salary, same company, different filter.

After the Posting: The First Filter

The JD gets builders to apply; the 15-minute screen tells you if the posting's claims survive contact. One question does most of the work: "Walk me through something you shipped for a client or a user in the last quarter. What broke after it shipped?"

Builders answer with names, dates, and a bug they're still slightly embarrassed about. Everyone else answers with a methodology. If you want a deeper bench of questions after that first screen, our set of FDE interview questions that reveal builders picks up right where this leaves off, and the Palantir FDE interview teardown is worth a read for the "would I deploy with this person" test.

Post the honest version, screen for the shipped thing, and your dark-room Fridays are over. The builders were always out there. Your old job description was just telling them, politely, not to apply.