One FDE title, several jobs: coding ranges from 30% to 90% of the week
Before asking whether forward deployed engineering is "technical enough", work out which of the jobs sharing that title the posting in front of you actually describes.
In brief
- Bloomberry analysed 1,000 job postings and found the FDE title covers three different jobs; the Builder type accounts for 60% and spends 70-90% of its time coding.
- About 30% of postings are really sales engineering (30-40% coding, with a quota); the remaining roughly 10% build internal-only tools and barely meet customers.
- In the Builder role, customer work does not displace code but feeds it: you write software inside the customer's own systems.
Bloomberry read 1,000 Forward Deployed Engineer job postings and found something odd: under the same title, some postings expect you to spend 70-90% of your time writing code, while others need only 30-40% and come with a sales quota. The gap is so wide that it is hard to call them the same job.
Bloomberry is not alone in noticing this. DataCamp writes that two jobs called FDE at two different companies can have almost nothing in common. Scaler goes further: the share of coding is not tied to the title at all but is a range set by each employer.
If you are a software engineer thinking of moving into FDE work, the question “is this job technical enough?” starts from the wrong place. The better question is: which type of job is the posting in front of me? Compare 30-40% with 70-90%, and the weekly coding hours of the two largest types can differ by as much as threefold.
Most postings describe a builder’s job
Bloomberry splits the FDE title into three types of job. The Builder type accounts for 60% of postings, a majority, and is identified by 70-90% of time spent coding and plenty of travel. Scaler, in an independent analysis, also estimates that about 60% of postings are building roles.
Translate that into a 40-hour week. At 70-90%, you write code for 28 to 36 hours, almost the full week of an ordinary software engineer.
Do customers eat into your time, or feed your work?
PostHog, a company that hires FDEs, puts it briefly: FDEs still do software engineering, but spend far more time talking to customers. A Perspective survey of 1,500 FDEs found a median of 47% of the week spent working directly with customers, with coding at only about 31%.
The 31% figure seems to contradict the Builder’s 70-90%, but the survey does not break results down by type of job, so its median lumps sales engineers together with builders.
Put differently, Builder postings promise a lot of code, while the actual week of FDEs in general tilts towards customers, which is one more reason to ask hard questions before accepting an offer.
In the Builder role, the two need not compete. Read PostHog’s description this way, and the hours spent talking to customers are the input to the code: they are when you work out what needs to be built.
Postings from large companies say the same. Palantir requires strong coding skills for its Forward Deployed Software Engineer role. Anthropic, for its FDE Applied AI role, ties building production systems to being regularly on site with customers to work alongside them.
Picture building on site at a customer. You rarely get to choose the stack, you cannot know in advance what the data looks like, and the users are standing right there when something breaks. That makes a Builder FDE’s coding much harder than the percentage suggests.
What do the other two types look like?
Bloomberry places about 30% of postings carrying the FDE title in a Sales Engineer+ group. The signs are 30-40% of time spent coding, pay that includes commission and a quota to carry. In a 40-hour week, that is 12 to 16 hours of coding, less than half the Builder’s upper end.
The remaining roughly 10% are Internal Tools Builders: serving only the company itself, mostly on CRM integration, with almost no travel. Here the FDE name has drifted almost entirely from its original meaning, since there is no external customer to “deploy” to.
Sales engineering is not a lesser job, and neither is building internal tools. But once you carry a quota, revenue becomes part of how your work is measured. If you want to move into FDE work to build real things for real customers, mistaking either of these for a Builder role is the easiest trap to fall into.
The table below sets Bloomberry’s three types alongside two specific postings:
| Share of FDE postings | Share of time coding | Travel | Distinguishing sign | |
|---|---|---|---|---|
| Builder (Bloomberry) | 60% | 70-90% | 30-50% | Builds for external customers |
| Sales Engineer+ (Bloomberry) | 30% | 30-40% | Under 20% | Carries a quota, earns commission |
| Internal Tools Builder (Bloomberry) | About 10% | Not stated | Under 5% | Internal only, CRM integration |
| Palantir FDSE | — | No share stated, requires strong coding | Up to 25%, flexible to preference | Works on site with customers when needed |
| Anthropic FDE Applied AI | — | No share stated, builds production systems | 25-50% | Builds directly with customers |
Read a job posting like a spec
The clearest signals are the words “quota” and “commission”. If they appear, you are most likely reading a sales engineering role, whatever the title says. “Internal”, “CRM” and almost no travel point to the internal tools type.
The travel figures in the table are useful but not conclusive. Palantir, a clearly code-heavy role, lists a level below the Builder’s usual range, and makes it flexible for each person. Judge on this number alone and you may misclassify the role, so read it together with the quota signal and what you are expected to build.
Once you reach the interview, ask directly: last week, how many hours did an FDE on the team spend writing code, and what was the last thing they shipped into a customer’s system? If the interviewer answers with revenue rather than a specific system, you have your answer.
What do you need to prove?
For the Builder type, employers need to see two things together. First, that you genuinely code: Python above all, since it appears in 66% of the postings Bloomberry analysed, and better still, a project that has run in an environment you did not fully control. Second, that you can find problems yourself rather than waiting for someone to hand you requirements.
So on your CV, do not write two separate paragraphs along the lines of “strong communication skills” and “proficient in Python”. Tell one story: what problem the user had, how you discovered it, what you shipped into their system and what it changed.
A small project that solves a real problem for a real user, runs on their data and has a README that explains the problem clearly says more than a certificate. It proves exactly the two things the Builder role needs at once.
Builder-style FDE work is in fact more technical than many people think, because the code has to run in the messiest place of all: someone else’s system. Your job before applying is to read the posting carefully enough to be sure it describes that job.
Was this article useful?
Thanks for the feedback!
7 sources
- I analyzed 1,000 Forward Deployed Engineer jobs (Bloomberry) · 2025-11-18
- Do Forward Deployed Engineers Actually Code? The Answer May Surprise You
- What is a Forward Deployed Engineer? (DataCamp) · 2026-07-17
- State of Forward Deployed Engineering 2026: Survey of 1,500 FDEs · 2026-05-18
- WTF is a forward deployed engineer? (and why everyone is hiring them) · 2026-02-11
- Forward Deployed Software Engineer (Palantir, Lever)
- Forward Deployed Engineer, Applied AI (Anthropic, via General Catalyst job board)