You've been scrolling job boards for twenty minutes and you've seen fourteen listings for "Forward Deployed Engineer." One wants a customer support rep with a laptop. Another needs a road warrior in airport lounges forty weeks a year. A third mentions "solutioning" four times and hasn't said "deploy" once. The forward deployed engineer job red flags are already visible — title inflation disguising support gigs, sales roles, and body-shop contracts as embedded engineering.

Your instincts are correct. The forward deployed engineer job red flags are everywhere because the title has become recruiting catnip. It sounds modern. It sounds elite. It implies a level of autonomy and impact that makes candidates excited. So recruiters use it for roles that have almost nothing to do with actual embedded engineering. The result is a landscape where genuine FDE opportunities sit next to support roles, pre-sales positions, and body-shop contracts that all share the same inflated title.

Knowing how to spot the fakes saves you from months of misery. A real FDE role has specific characteristics: you write production code, you deploy it, you sit with users, and you own outcomes. The fake ones have different characteristics: you demo existing products, you file tickets for engineering, you travel endlessly without shipping accountability, or you get rented out by the hour with no project continuity. Here's how to tell them apart before you waste time on a hiring process that leads to the wrong job.

The Title Inflation Problem: When Everyone's an FDE

Five years ago, "Forward Deployed Engineer" meant something specific. It was Palantir's term for engineers who embedded with government and enterprise clients, shipped software in hostile environments, and owned outcomes that mattered. The title carried weight because the role was unusual and the bar was high. Then other companies started copying it. Then staffing firms got involved. Now it's a buzzword.

The inflation follows a predictable pattern. A company needs someone technical who can talk to customers. Their actual need is a solutions engineer, a sales engineer, or a technical account manager. But those titles don't attract top engineering talent. So they rebrand. "Forward Deployed Engineer" sounds like you'll be building things. And maybe you will — a demo script here, a configuration there. But the core job is client-facing theater, not embedded shipping.

This isn't always malicious. Sometimes hiring managers genuinely don't know what an FDE does. They heard the term at a conference. They liked the sound of it. They applied it to their open req without updating the responsibilities. The result is the same: you apply thinking you'll be shipping code at a client site, and you end up running QBR presentations for a product you didn't build.

Red Flag 1: No Shipping Mentions

Open the job post and hit Ctrl+F. Search for "deploy." Search for "production." Search for "git" or "code review" or any word that implies you'll actually be writing and releasing software. If the post talks extensively about "client relationships," "solutioning," "stakeholder management," and "driving outcomes" but never mentions the mechanics of shipping, you're looking at a support or sales role wearing a fancy hat.

A real FDE post reads like an engineering job description that happens to mention clients. It lists specific languages and frameworks. It mentions CI/CD, testing, or infrastructure. It talks about building features instead of merely configuring them. A typical fake FDE post reads like a consulting job description that happened to mention JavaScript. It wants "strong communication skills" and "ability to translate business needs to technical teams." Translation: you'll be talking to engineers, not being one.

The severity of this red flag depends on what you want. If you're an engineer who wants to stay technical, a no-shipping FDE role is a trap. You'll spend six months realizing that your "engineering" job is actually presales support with extra steps. By then, your coding skills have atrophied and your GitHub profile looks like a ghost town. The career paths after FDE work depend on having actually shipped things.

Red Flag 2: The Travel Trap

"Up to 80% travel required." This phrase appears in more fake FDE posts than any other. The reality is simple: real embedded engineering sometimes requires travel. You might spend a week onsite to kick off an engagement, or a few days monthly for demos and feedback sessions. But perpetual travel (four days a week, every week, forever) is not an FDE role. It's a road warrior role with a misleading title.

The difference matters. Travel tied to specific build phases makes sense. You're onsite for discovery, for the initial deploy, for key demos, and for handoff. Between those phases, you're heads-down writing code. Travel as a permanent lifestyle means you're not building. You're visiting. You're doing status meetings in different zip codes. You're living in hotels because the job is client coverage, not client embedded engineering.

Ask directly in the interview: what percentage of travel is for specific project milestones versus ongoing client coverage? If they can't give you a clear answer, or if the answer reveals that you'll be hopping between clients with no shipping accountability, you're not being hired as an FDE. You're being hired as a highly technical account manager who flies coach.

Red Flag 3: Pre-Sales in Disguise

This is the most sophisticated fake FDE role. The job post mentions code. It mentions clients. It sounds like embedded engineering. But the actual work is demonstrating an existing product, configuring it for prospects, and helping the sales team close deals. You're a solutions engineer with a title upgrade.

The telltale signs are in the responsibilities. Look for phrases like "own the technical sales cycle," "deliver product demonstrations," "drive proof-of-concept engagements," and "partner with account executives." These are sales engineering verbs, not FDE verbs. A real FDE owns the deployment and the ongoing iteration. A pre-sales FDE owns the demo and the handoff to someone else who actually implements.

There's nothing wrong with solutions engineering as a career. It's a valid path with good pay and interesting work. But it's not FDE work. Solutions engineers demo and configure. FDEs build and deploy. If you want to write production code, a pre-sales role will leave you frustrated. You'll spend your days in PowerPoint and Salesforce instead of VS Code. And when you try to pivot to a real engineering role later, your resume will confuse recruiters who see "FDE" but read "sales support."

Red Flag 4: The Body-Shop Model

The body shop is the oldest trap in technical staffing, and it's alive and well in the FDE market. Here's how it works: a staffing firm advertises a "Forward Deployed Engineer" role. You interview. They place you at a client site. You bill hours. The staffing firm takes a margin. You have no equity, no project ownership, and no feedback loop that connects your work to outcomes.

These arrangements are technically employment, but they function like hourly rental. You're a warm body with a technical resume. The client treats you as a temporary resource, not an embedded partner. The staffing firm treats you as a margin multiplier. And you treat it as a job because the title sounds impressive. Six months in, you realize you haven't shipped anything meaningful, you have no relationship with the client beyond tickets and status reports, and your career trajectory is flat.

Real FDE work requires project ownership and direct client collaboration. You need to be accountable for outcomes, instead of merely clocking hours. You need a feedback loop where your work gets evaluated by results, not by timesheet compliance. Body shops can't provide this because their business model is built on fungible labor, not embedded expertise. The what FDEs actually earn discussion matters less if the role itself is a dead end.

Green Flags That Matter: What a Real FDE Post Looks Like

For every red flag, there's a corresponding green flag. A genuine FDE job post has specific characteristics that are easy to spot once you know what to look for. It mentions a specific tech stack: not "familiarity with modern tools" but "Python, FastAPI, React, Postgres, deployed on AWS." It describes specific shipping outcomes: "build and deploy a customer-facing dashboard" or "reduce manual reporting time by 60%." It references specific client context: "embedded with our logistics clients" or "onsite with healthcare operations teams."

The responsibilities section talks about building, testing, deploying, and iterating. It doesn't hide behind verbs like "facilitate," "drive," or "align." The requirements section asks for coding ability first and communication ability second. Not because communication doesn't matter (it matters enormously), but because the primary output of the role is code that ships, not conversations that happen.

A real FDE post also mentions iteration and feedback. It talks about working directly with users, gathering requirements in context, and adjusting based on what you learn. It doesn't describe a waterfall handoff from product to engineering to QA. It describes a continuous loop of build, deploy, observe, and refine. That's the embedded model. That's what you're looking for.

Questions to Ask in the Interview

The job post is just the starting point. The interview is where you separate the real FDE roles from the dressed-up support gigs. Here are five questions that reveal the truth about what you'll actually be doing.

"What did the last person in this role ship in their first month?" A real FDE hiring manager can answer this with specifics. A fake one will give you vague generalities about "learning the domain" or "building relationships."

"Who owns the codebase I'll be working in?" If the answer is "the client's engineering team" and you'll be filing PRs into their repo, that's consulting, not embedded. Real FDEs own their code.

"What's the deploy cadence?" If they look confused by this question, run. A real FDE environment ships continuously or at least weekly. A demo-driven sales cycle ships never.

"How much of my week will be client meetings versus heads-down building?" The honest answer for a real FDE role is something like 70% building, 30% client interaction. If it's inverted, you're in a client-facing role, not an engineering one.

"What's the path from this role to more senior embedded work?" Body shops and sales-engineering traps won't have a clear answer. Real FDE organizations have progression paths that involve bigger engagements, more autonomy, and eventually leading embedded teams. The equity and compensation conversation should also surface naturally if the role is genuine and senior.

Not every job with "FDE" in the title is a lie. But enough of them are that you need to screen carefully. The forward deployed engineer job red flags aren't subtle once you know what to look for. No shipping mentions, endless travel, pre-sales disguises, and body-shop economics are the four horsemen of fake FDE roles. Learn to spot them, ask the hard questions, and hold out for the real thing. Your career will thank you.