# How to Become a Forward Deployed Engineer

> A practical path into FDE: engineering bar, customer surface, platform discipline, and agent deploy craft—without cargo-culting the title.

- Published: 2026-07-28 · Updated: 2026-07-29 · jurniti
- Canonical: https://www.jurniti.com/blog/how-to-become-a-forward-deployed-engineer

**How to become a forward deployed engineer** is less mysterious than LinkedIn makes it. You need a **software engineering bar**, a **customer surface**, and the discipline to build on **platform primitives**—not a mystical “AI aura.”

The perfect profile, in Bai’s public FDE 101 framing (Anthropic Applied AI; founding FDE at Rippling; ex-Palantir), is blunt: **nothing more than a customer-facing software engineer.** Hire as an SWE *and* trust them with a customer. That is the bar to aim at.

This guide is a practical path: decide if you want the job, raise the engineering floor, practice customer trust without quitting tomorrow, learn platform thinking, add agent deploy craft if that is your lane, interview cleanly, and survive the first 90 days without becoming a snowflake factory.

## Step 0: decide if you want the job, not the title

FDE work includes:

- Incomplete requirements
- Security reviews
- Politics
- Production pressure
- Travel or intense remote customer time (varies)
- Saying “no” to work that should be product—and living with the tension

It also includes:

- Fast learning
- Visible impact
- Rare end-to-end ownership
- Direct line from field pain to platform improvement

If you want only model research or only pure product tickets, pick a different path. If you want only demos, pick SE. If you want permanent custom software with no productization duty, you want consulting—not FDE.

### A quick self-test

Score yourself 0–2 on each:

1. I enjoy incomplete problems more than I resent them.  
2. I can explain a system to an executive and to an SRE without lying to either.  
3. I ship code I would defend in review.  
4. I notice when work should be configuration, not a rewrite.  
5. I can leave a runbook and sleep.  
6. I care whether the next customer is cheaper than the last.

**0–4:** explore adjacent roles first.  
**5–8:** build missing muscles deliberately.  
**9–12:** you are already practicing FDE shape—package it.

## Step 1: raise the engineering floor

You cannot fake this long-term.

Target: peer of a mid/strong product SWE at a serious company.

### Concrete skills

- Ship production services with tests and observability  
- Understand auth, networking, and failure modes  
- Be comfortable in constrained environments (VPCs, proxies, locked laptops)  
- Write clear design notes  
- Participate in code review culture without drama  
- Debug under time pressure without turning every incident into theater  

### How to close the gap if you are under-bar

| Gap | Practice project | Evidence for portfolio |
| --- | --- | --- |
| Weak production experience | Own a small service end-to-end at work | Metrics, alerts, postmortem notes |
| Weak systems design | Design multi-tenant resource isolation on paper + spike | Written design + tradeoff table |
| Weak security instincts | Threat-model a tool-using agent | Data-flow diagram + controls list |
| Weak testing habits | Add golden-path evals to an automation | Eval suite that fails on regressions |

Do not “become FDE” by collecting agent demos. Become FDE by becoming someone product eng trusts with production.

## Step 2: practice the customer surface without quitting your job

You do not need “consultant” on your résumé first.

### High-signal practice inside a normal SWE job

- Own an internal tool used by non-engineers  
- Run office hours for a platform your team builds  
- Sit in on sales/SE calls and write postmortems on why deals stall  
- Mentor support through hard escalations  
- Lead a design partnership-style spike with a real stakeholder  
- Write the handoff document you wish last quarter’s hero had left  

Goal: be someone a non-engineer trusts when something is on fire.

### Discovery practice drill (30 minutes)

Pick a messy internal process. Interview one operator. Produce:

1. Outcome in their language  
2. Constraints (security, tools, politics)  
3. What already exists that you must assemble on  
4. What would make the second team’s version cheaper  
5. What you will refuse to custom-build  

That drill is more FDE-shaped than another weekend chatbot.

## Step 3: learn platform thinking

FDE without a platform is consulting. Study:

- What is configured vs developed  
- What should be productized from field work  
- How multi-tenant systems isolate blast radius  
- How templates prevent 55 repos  
- How atomic primitives should be for *your* user base (broad platforms trend more granular; vertical motions sometimes ship heavier pre-built assemblies)

Bai’s FDE 101 pedagogy is explicit: if each “FDE” builds entirely from scratch, you have a **dev shop**, not an FDE function. Maintenance and engineer retention lose first; finance loses second. The key ingredient is building **on shared primitives**.

### Side project that trains the muscle

Build something small with **shared primitives + per-tenant config**. Even two “customers” (two configs) teaches the split:

- Shared: auth, runtime, logging, template  
- Tenant A: policy, tools, credentials  
- Tenant B: different policy and tools—same platform  

Document:

- What is forbidden to copy-paste per tenant  
- What the restore path is  
- What you would productize after a third tenant appears  

### Platform vs customer decision table (memorize this)

| Signal | Move to platform | Keep customer-scoped |
| --- | --- | --- |
| Second logo will need it | Yes | — |
| Encodes one org’s org chart | — | Yes |
| Changes multi-tenant safety | Yes (carefully) | Never as a one-off hack |
| One-off legacy connector | Maybe later | Yes initially |
| Harness install / host pattern | Yes | No snowflake hosts |

## Step 4: add AI / agent deploy craft (if that is your lane)

If you want AI-native FDE roles, classic FDE skills are necessary but not sufficient. Agent products fail in specific, boring ways.

### Five skills that separate demos from delivery

1. **Isolation models** — shared-kernel containers vs microVMs; why credentials care about blast radius  
2. **Always-on vs ephemeral** — when sandboxes lie about long-running work  
3. **BYOK** — keys in the tenant boundary, not a shared hero laptop  
4. **Eval harnesses** — golden tasks after every change  
5. **Restore and fork** — bad days and next logos  

### Category failures to understand deeply (no vendor shopping required)

**Laptop fleets.** Great for spikes. Terrible for multi-customer production: batteries, airports, device loss, unreviewable secret sprawl.

**DIY VPS snowflakes.** Always-on possible; template culture optional. Without discipline you invent 55 hosts instead of 55 repos.

**Shared-kernel density.** Efficient packing; shared kernel risk classes. Acceptable for some low-trust workloads; stressful next to production keys.

**Ephemeral sandboxes.** Excellent for short code execution. Poor fit for always-on agents that need memory, schedules, and durable credentials.

### Portfolio piece that beats ten chat screenshots

Build one multi-environment agent setup:

- Two isolated environments (“customers”)  
- Separate credentials  
- Persist that survives restart  
- A restore drill you have actually run  
- A template or fork path for environment three  
- A one-page runbook a teammate can follow  
- Three golden eval tasks that gate deploys  

Harness choice can be whatever you ship with—Hermes, OpenClaw, Pi, or another stack—so long as the **deploy craft** is real.

## Step 5: package your résumé and portfolio

### Résumé lines that signal FDE shape

Prefer:

- “Shipped X to production; handoff owned by Y team; reduced Z”  
- “Assembled on platform primitives A/B; generalized C for next account”  
- “Designed isolation for multi-customer credentials”  

Avoid:

- “Prompt engineered 50 demos”  
- “Collaborated cross-functionally” with no artifact  
- Tool laundry lists without outcomes  

### Portfolio structure (one page is enough)

1. Problem and buyer outcome  
2. Constraints  
3. What you assembled vs invented  
4. Production evidence (monitoring, handoff, restore)  
5. What became reusable  
6. What you would do differently  

If you cannot fill (4) and (5), keep practicing.

## Step 6: interview like an FDE

### Expect

- Coding equal to SWE screens  
- System design with multi-tenant twists  
- A customer scenario: messy stakeholder + incomplete data  
- Security and production questions  
- For agent roles: isolation, keys, always-on, eval  

### Ask them

- What platform will I build on in 90 days?  
- What fraction of field work became product last two quarters?  
- How are multi-customer credentials isolated?  
- What stays up when a laptop closes?  
- Who owns incidents after handoff?  
- When did the team last refuse a snowflake request?  
- How do multiple FDEs avoid single-person bus factor?  

Walk if they cannot answer isolation and handoff.

### Practice prompts (self-drill)

1. A non-technical VP bought an agent platform for claims triage. Security wants a review in two weeks. Design discovery and a production path that is not a laptop demo.  
2. Three customers need “similar” GTM agents. Two share a CRM; one does not. Where do you put primitives vs config?  
3. An agent can send email. Design tool permissions, human gates, and audit.  
4. A bad model change ships. What is the restore story?  
5. Your manager wants billable customization that will never reappear. How do you push productization without being obstructive?

## Step 7: first 90 days on the job

1. Learn primitives and anti-patterns  
2. Shadow discovery calls  
3. Ship one production handoff  
4. Open two platform improvements from field pain  
5. Refuse one request that should be product—politely, with a path  
6. Write the isolation and key-custody story for your engagements  
7. Establish a multi-FDE notes habit so context is not trapped in your head  

You are not measured by how many demos you run. You are measured by outcomes that survive you.

### 90-day anti-patterns

- Becoming the permanent on-site hero  
- Building private stacks because “the platform is incomplete” *without* filing platform work  
- Storing customer keys on personal devices “temporarily”  
- Measuring yourself only by executive smiles  
- Avoiding product eng because “they move too slow”  

Incomplete platforms are normal early. Silent snowflake creation is not.

## Common entry paths

| From | Leverage | Gap to close |
| --- | --- | --- |
| Product SWE | Engineering depth | Customer entropy, discovery |
| SE / SA | Customer trust | Production ownership, code bar |
| Support / success + coding | Domain empathy | Systems design, platform discipline |
| Consulting | Delivery under chaos | Productization, refuse snowflake stacks |
| Research / ML eng | Model judgment | Production systems + customer surface |

### If you are a founder hiring your first FDE

You still need the same two filters from FDE 101 pedagogy:

1. Do you **need** the motion (technical product × non-technical buyer)?  
2. Do you have a platform—or a funded plan to invest in one?  

Hiring a “rockstar” without primitives produces revenue that later becomes a liability.

## How jurniti helps you practice the hard part

[jurniti](/) lets you run agent harnesses on **Firecracker microVMs** with BYOK, persist volumes, and templates. That is closer to multi-customer deploy craft than a single laptop agent—useful for portfolio work and for real delivery teams.

You remain the hero: choose the harness, own the outcome, write the runbook. jurniti is the managed isolation and always-on floor so practice time does not turn into a second full-time job of host ops.

No free trial or free tier. First purchase has a **30-day money-back guarantee** if you evaluate a real plan while you skill up.

## 12-week skill plan (condensed)

| Weeks | Focus | Exit criteria |
| --- | --- | --- |
| 1–3 | Engineering floor | Production PR + design note you are proud of |
| 4–5 | Customer surface | One discovery write-up with a real stakeholder |
| 6–7 | Platform thinking | Two-tenant config project + reuse rules |
| 8–10 | Agent deploy craft | Isolation + BYOK + restore drill documented |
| 11–12 | Interview packaging | Résumé, portfolio page, mock customer scenario |

Adjust intensity. Do not skip the engineering floor.

## Get the free series

FDE 101 is a seven-day email sequence covering role, 2×2, primitives, agentic shift, and deploy craft.

[Pricing](/pricing) when you want a real isolated box—30-day money-back on first purchase, no free tier.

## Related reading

- [What is a forward deployed engineer?](/blog/what-is-a-forward-deployed-engineer)
- [Forward deployed engineer job](/blog/forward-deployed-engineer-job)
- [FDE vs software engineer](/blog/forward-deployed-engineer-vs-software-engineer)
- [Forward deployed engineer salary](/blog/forward-deployed-engineer-salary)
- [Forward deployed AI engineer](/blog/forward-deployed-ai-engineer)
- [AI agent sandbox for customer deployments](/blog/ai-agent-sandbox-for-customer-deployments)

## Frequently asked questions

### How do I become a forward deployed engineer?

Build production software skills, practice customer-facing delivery, learn to assemble on platform primitives, and add deploy craft for multi-customer systems—especially isolation and always-on runtimes for agents.

### Do I need prior consulting experience?

No. You need engineering depth plus the ability to earn trust with customers. Many strong FDEs come from product SWE backgrounds.

### What should my portfolio show?

Production handoffs, multi-tenant or multi-environment judgment, and systems you left operable—not only demos or notebooks.

### How long does the transition usually take?

If you already ship production software, you can become interview-ready in months by deliberately practicing discovery, handoffs, and multi-customer isolation. If you lack an engineering bar, close that first—there is no shortcut.

### What should I study for FDE interviews?

SWE-level coding and system design, multi-tenant isolation, messy stakeholder scenarios, security basics, and for agent roles: BYOK, always-on vs ephemeral runtimes, restore, and eval harnesses.

### How does jurniti help me practice?

You can run real agent harnesses on isolated microVMs with BYOK and templates—closer to multi-customer deploy craft than a laptop-only setup.

### Is there a free tier to learn on?

No free trial or free tier. First purchase has a 30-day money-back guarantee.

### Can I become an FDE without an AI background?

Yes for classic platform FDE roles. For AI-native FDE jobs, add model judgment and agent deploy craft, but the core remains customer-facing software engineering.