Forward deployed engineer jobs sit between product engineering and customer delivery. Hiring teams use the title for a specific motion: ship outcomes on a platform for buyers who will not implement the product themselves.
If you are scanning listings for “FDE,” “forward deployed,” “applied AI engineer,” or “deployment engineer,” most of the variance is branding. The load-bearing question is whether the company has (or will invest in) shared primitives—or whether they are hiring a travel-heavy services team and calling it FDE.
This post is a field guide for candidates and hiring managers: how to read a posting, what day-one work looks like, which skills actually show up, career shapes, interview questions that surface reality, and the runtime floor agent-heavy FDE jobs quietly assume.
What “FDE job” means when the title is honest
An honest forward deployed engineer job has four non-negotiables:
- Software engineering bar — you ship production systems, not only decks.
- Customer surface — you own discovery and stakeholder entropy, not only tickets.
- Platform assembly — you build on shared primitives, not a permanent private stack per logo.
- Handoff — success is an operable outcome that can live without you on-site forever.
Kevin Bai’s FDE 101 framing (Anthropic Applied AI; founding FDE at Rippling; ex-Palantir) keeps the profile unglamorous on purpose: the ideal FDE is a customer-facing software engineer—hire as an SWE and trust them with a customer. If a job description drops either half, treat the title as marketing.
The economic design behind the role is also load-bearing: customers buy outcomes, not “we organized the tables” or “we stood up a model.” Product alone leaves a training tax. Hours alone become a services firm. The FDE job is the human half of selling product + delivery as one package—while the platform prevents the 55-repo maintenance death spiral.
How to read an FDE job post
Strip the adjectives. Map the post onto three axes:
- Who is the buyer? If the buyer is a non-technical executive for a technical platform, FDE is a real GTM design. If the buyer is a staff engineer choosing a library, you may be looking at DevRel or SE with a fashionable title.
- What is the platform? Name the product you build on. If the answer is “whatever the client needs,” you are looking at consulting.
- What is success? “Closed tickets” is wrong. “Customer can operate the outcome without you on-site forever” is closer. “Platform absorbs 30% of last quarter’s custom work” is excellent.
Phrase decoder
| Job-post language | Often means | Verify by asking… |
|---|---|---|
| “Own the customer relationship end to end” | Real delivery ownership or pure services heroics | What is the platform? What becomes product? |
| “Travel 50%+” | On-site culture | Is travel optional for remote-capable work? |
| “Full-stack generalist who loves customers” | Vague; may lack product | Show me primitives I build on in 90 days |
| “Applied AI / deployment engineer” | Agent-era FDE or prompt demos | Isolation, eval, always-on story |
| “Partner with product” | Healthy feedback loop or lip service | % of field work productized last two quarters |
| “Fast-paced, ambiguous environments” | Real enterprise entropy or no process | How do you prevent 55 repos? |
Green flags
- Explicit product surface and primitives
- Pairing with product eng / PM on what to productize
- Production ownership (creds, monitoring, handoff)
- Mentions of multi-customer patterns, templates, or internal platform teams
- Travel optional or targeted—not “always on a plane” as the whole value prop
- Interview loop that includes coding and a messy customer scenario
- Clear incident ownership after handoff
Red flags
- “Full-stack generalist who loves customers” with no product named
- Success measured only in billable hours
- Every engagement starts from an empty repo
- No path for field work to become product
- Agents or AI workloads expected to run on personal laptops indefinitely
- Security review treated as an afterthought slide
- Single-hero embedding with no multi-FDE collaboration model
Day-one work (honest version)
Week one is rarely “write the cool agent.” It is:
- Learn the product’s primitives and anti-patterns
- Shadow a customer call; note where demos lie
- Find the last three engagements and reverse-engineer what was bespoke vs reusable
- Inventory how environments, keys, and data are isolated today
- Read the last postmortem or the reason the last pilot stalled
- Meet the people who own legal, security, and support—the real change board
Week two onward, the loop looks like:
Discover → assemble on platform → productionize → generalize.
Skip generalize and you will drown. Skip productionize and you will only ship pilots. Skip discover and you will build the wrong workflow elegantly.
A realistic first 30 / 60 / 90
| Window | Outcomes that prove the job is real |
|---|---|
| 30 days | You can explain the platform primitives; you have shadowed discovery; you know the isolation story for multi-customer work |
| 60 days | You shipped a scoped production path (or a hard security-approved pilot plan); you opened at least one platform ticket from field pain |
| 90 days | One operable handoff; two productized improvements proposed or merged; you refused one snowflake request with a platform path |
If 90 days pass with only demos and no production ownership, you are not in an FDE job—you are in a rebranded SE or services role.
Skills that show up in real FDE jobs
You do not need every skill at hire. You need a path to them.
Engineering (non-negotiable bar)
- Ship production software: tests, reviews, observability
- Comfortable in customer networks and constrained environments
- Can design for multi-tenant and multi-customer blast radius
- Write design notes other engineers will actually read
- Know when a “quick script” will become a permanent dependency
Customer surface
- Run a discovery conversation without becoming a pure note-taker
- Write for executives and for implementers
- Hold a “no” when the request is a one-off that should be product
- Manage stakeholders across security, legal, ops, and the executive sponsor
- Leave runbooks, not tribal knowledge
Systems judgment
- Know when to customize vs configure
- Prefer shared runtime primitives over snowflake ops
- Spot repeated patterns across logos and push them into the platform
- Choose isolation and secret custody before feature novelty
AI / agent deploy craft (when the product is agentic)
For AI / agent FDE jobs, add:
- Isolation models (hardware-backed guests vs shared-kernel density)
- Secret custody and BYOK inside the tenant boundary
- Always-on vs ephemeral sandboxes—when each shape is honest
- Persist, restore, and fork paths
- Evaluation harnesses and golden tasks after every change
- Tool permission design that looks like auth, not like hope
- Cost caps and human-in-the-loop gates for irreversible actions
You will not learn all of this from a model card. You learn it by shipping multi-customer systems that must stay up.
Career shapes: FDE as first job vs mid-career move
First job in AI / FDE
High learning rate, high chaos. You will see real enterprises fast. Risk: becoming a prompt-and-slides person if the team lacks engineering bar. Protect yourself by demanding production ownership and pairing with strong platform engineers.
Mid-career SWE → FDE
You already ship; you learn customer entropy. Risk: underestimating politics and overbuilding elegant systems for the wrong outcome. Protect yourself by forcing platform feedback loops and writing discovery notes before architecture.
SE / PS → FDE
You already face customers; you may need to raise the engineering bar and refuse pure body-shop work. Protect yourself by insisting on code review culture equal to product and by measuring handoffs, not only deal support.
Support / success + coding → FDE
You have domain empathy and fire-fighting scars. Gap: systems design and platform discipline. Protect yourself by shipping production services on the side and documenting multi-environment judgment.
None of these paths work if the company has no platform. Confirm that in the interview—twice.
How hiring managers should write the job (and mean it)
If you are hiring, your posting should answer:
- Platform: name the product and the primitives FDEs assemble
- Buyer: who buys, and why they will not implement alone
- Ownership: production incidents after handoff
- Productization: how field work becomes roadmap
- Runtime: especially for agents—isolation, keys, always-on
- Travel: actual policy, not vibe
- Success metrics at 6 months: outcomes + platform contribution
Sample success metrics that are not vanity
- Number of operable handoffs (not demos)
- % of engagement work that reused templates / primitives
- Platform PRs or specs accepted from field
- Mean time to second similar logo (should fall)
- Security findings that block production (should trend down with better primitives)
- Secrets never stored on personal devices for multi-customer work
Sample metrics that attract the wrong people
- Hours billed
- Number of on-sites
- “Wow” scores without production criteria
- Features built that never reappear for a second customer
Interview questions you should ask them
- Show me the platform primitives I will build on in the first 90 days.
- What percentage of last quarter’s field work became product?
- How do multi-customer environments isolate credentials and data?
- What dies when a laptop closes—does the customer agent stay up?
- Who owns production incidents after handoff?
- How is success measured at six months for this role?
- When did you last refuse a customer request because it should be product?
- How do multiple FDEs share context so one person is not the bus factor?
If they cannot answer isolation and always-on for agent workloads, you are interviewing for demo theater.
Interview questions they should ask you (be ready)
- Walk through a production system you left operable without you as the hero.
- Describe a time you chose configuration over a rewrite—and when you correctly chose a rewrite.
- Given a messy stakeholder map (security + exec + ops), how do you sequence discovery?
- Design isolation for three customers with overlapping SaaS tools and separate keys.
- How would you turn last month’s custom work into a template?
Coding screens should still feel like SWE screens. If they drop the engineering bar, they are not hiring an FDE.
Agent fleets change the job description
Many FDE jobs now imply agent fleets: one engagement is not one process; it is a set of always-on agents with customer keys, tools, and memory.
That changes what “day-to-day” looks like:
| Classic FDE artifact | Agent-era FDE artifact |
|---|---|
| Dashboard / workflow app | Always-on agent + tools + eval harness |
| One-time data pipeline | Continuous tool calls with side effects |
| Shared staging box | Per-customer isolation boundary |
| “It works on my machine” | “It works when my machine is closed” |
| Manual runbook only | Runbook + restore + cost caps |
Category failures to reject in the job’s infrastructure
- Laptop fleets for production customer agents
- DIY VPS snowflakes with no template or restore culture
- Shared-kernel density hosts next to production credentials without a clear risk decision
- Ephemeral sandboxes sold as always-on agent hosts
A strong FDE job either builds the runtime floor internally or buys a managed one. Weak jobs leave every field engineer inventing ops.
Where jurniti shows up in the job
When the work is multi-customer agents, the runtime is part of the job design—whether or not the posting says so.
jurniti is a managed Firecracker microVM host for agent harnesses—BYOK, tenant isolation, persist volumes, templates you can fork. It is not the employer. It is the kind of runtime floor strong FDE teams either build internally or buy so field engineers do not invent ops per logo. Harness examples people actually ship include Hermes, OpenClaw, and other agent stacks; the platform stays harness-agnostic while the FDE stays focused on outcomes.
No free trial or free tier. First purchase includes a 30-day money-back guarantee if you need a real always-on box while you interview, practice deploy craft, or stand up a delivery motion.
Offer-stage diligence checklist
Before you sign:
- Platform named and demoed, not only described
- You met a product engineer who receives field feedback
- Isolation story for multi-customer credentials is coherent
- Always-on story exists for agent workloads
- Success metrics include handoff and productization
- Travel policy is written
- You know who owns production after you leave
- Comp and leveling treat FDE as engineering, not pure services
If more than two boxes stay unchecked, negotiate clarity or walk.
Get the free series
FDE 101 is a seven-email sequence: what the job is, when you need the function, primitives vs dev shop, agentic GTM, and deploy craft for fleets.
Prefer to provision a real box while you interview? Pricing — 30-day money-back on first purchase, no free tier.