Same FDE title, very different job: five tests for spotting the impostor roles in a job posting

Between January and September 2025, job postings for forward deployed engineers grew by more than 800%, according to figures cited by Paraform. When a title takes off that fast, not every posting describes the same job.

Nobody can count how many of those openings are old roles renamed to sound current. A cautious guess is still possible: a title is easy to change, while the structure of a job is much harder to change. So candidates should not read the title. They should read the parts a company finds hard to disguise.

For a developer looking to leave outsourcing work for an FDE role, as many in Vietnam now are, this matters directly. Take the wrong job and you could spend two years building pre-sales demos or doing customer support while your CV still says “engineer”. Fortunately, a job description usually gives itself away through five details, if you know where to look.

What are you allowed to build?

Tandem proposes what it calls the “output test”: look at what each role is allowed to produce. A solutions engineer builds demos and architectures to close deals. An FDE writes custom code that did not exist before for a specific customer, then carries it back into the product.

Paraform adds an important point: FDEs write production code, but not for the core product. That line rules out both common misreadings. An FDE is not someone building demos for show, but nor are they a product engineer sitting at headquarters.

Apply this to a hypothetical job description. If the responsibilities read “build POCs and technical demos for prospective customers”, your output is a sales tool, and that is a solutions engineer’s job. If they read “build production applications in customer infrastructure”, you are reading the right kind of posting.

Do you arrive before or after the contract is signed?

The second test is timing. Aced draws the distinction this way: solutions architects work before the sale, while FDEs arrive after the deal is done, to make the product actually deliver value. The practical consequence is simple: any posting that mentions quota, pipeline or “supporting the sales team” leans towards the SA role, whatever the title says.

Aced also draws a subtler line: an SA owns the design, not the running system.

So when reading a job description, look for words that show you are responsible after the system goes into production, such as operating, monitoring and incident response.

If the responsibilities stop at “proposing architecture”, you are the one drawing the plans, not the one building the house.

How success is measured reveals the real job

Timing and output can still be written vaguely. Success metrics are harder to blur. According to Tandem, solutions engineers are measured on revenue and deal count. FDEs are measured on customer outcomes plus the lessons brought back to the product.

If a job description includes a passage on what success looks like after a few months, read that passage most closely. If it is all revenue or renewal figures, the role serves the sales team. If it describes a customer system running reliably and a deployment pattern that has made it onto the roadmap, it is an FDE role.

The hardest test to fake: who brings custom code back into the shared product?

The four tests above can all be fudged in writing. The fifth cannot, because it requires a decision about how the company is organised.

Valletta Software, writing from the employer’s side, argues that any job description with no one responsible for turning custom solutions into something reusable is, in practice, a consulting role with an engineering title.

A post on Substack puts it more bluntly. If nothing gets generalised, an FDE programme is just an ordinary support contract with a grander name. The company is then a services business that happens to call its staff engineers.

Palantir’s original model explains why this feedback loop is central. According to a historical overview citing a Palantir post from April 2019, the company split two groups by scope: Dev built one capability for many customers, while Delta worked for one customer across many capabilities.

The same overview describes the FDE model as a product development strategy that merely looks like services from the outside.

When reading a posting, you can score it quickly with this table:

Test	Real FDE signal	Impostor signal
Output	Custom production code running in the customer’s systems	Demos, POCs, architecture to close deals
Timing	After the contract is signed	Pre-sale, mentions of quota, pipeline
Ownership	Responsible for the running system	Owns only the design
Metric	Customer outcomes plus lessons for the product	Revenue, deal count
Feedback loop	Someone carries deployment patterns back to Product/Engineering	Nothing is generalised

Dissecting a real posting: Anthropic

Anthropic’s FDE posting, now closed to applications, is a good case for testing the table. It describes engineers embedded with strategic customers, working directly in the customer’s systems to build production applications with Claude models. Output test: pass.

On ownership, the posting gives no direct answer. “Working in the customer’s systems” suggests you are close to the running system, but it does not say who operates it after go-live. That is a question to ask in the interview; do not fill in the blank yourself.

The most notable detail is the requirement to identify and codify repeatable deployment patterns, then feed them back to the Product and Engineering teams. That is exactly the feedback loop Valletta and the Substack post treat as the line between FDE work and consulting. The posting passes the hardest test.

It also states travel of up to about 25%. That figure differs from what Valletta considers most useful to publish: the share of time spent working in the customer’s environment. You can work inside a customer’s systems without going anywhere, so travel is only a rough indicator, and you should still ask for the real number.

By contrast, be wary of job descriptions with a lengthy list of required frameworks. Valletta notes that demanding as many as twelve frameworks shows the employer does not know what the job actually needs. Faced with a list like that, take it as a prompt to ask what the day-to-day work really is.

For developers making the move: read the job description like a spec

When a concept is in fashion, some services companies will rename their implementation or support teams as FDEs. That can happen in Vietnam as anywhere else. You do not need to guess their intentions. Read the job description as you would a spec: find the inputs, the outputs, and who receives those outputs.

The table is only the first filter. The next step is the interview, where you ask what the job description does not answer. Where does code written for one customer end up? Who decides to bring a deployment pattern into the product, and when did that last happen? If the interviewer struggles, you have your answer.

The same table works for your own CV. Serious FDE employers look for people who have generalised before, so do not just write “deployed a system for customer X”.

Write something like: solved the customer’s problem, then extracted the data processing into a module reused by the next three projects. A line like that shows both the customer outcome and the lesson brought back to the product.

FDE postings will keep growing, and so will the impostors. Before you apply, find out who at that company turns code written for one customer into a shared product.