How to become a Forward Deployed Engineer — the path nobody has written down yet

In May 2026, Aaron Levie — Box CEO, someone who has watched enterprise software hiring for two decades — posted that career counselors should quickly figure out how to help students get forward deployed engineer jobs. The hiring explosion is real, the compensation is real ($180K–$700K+ total comp), and career infrastructure hasn't caught up.

The path exists. It's just not written down anywhere useful. Until now.

---

The reality check before anything else

What makes an FDE different from a senior engineer isn't just technical skills. It's a specific combination that most engineers have only part of:

1. Technical depth — You have to be able to build production systems quickly, in unfamiliar codebases, against undocumented constraints. This is table stakes.

2. Business acumen — You have to understand what the client actually needs, not just what they said. This means understanding how a company makes money, what their data actually represents, and what the stakeholder asking you for something actually cares about. Not an MBA. Operational intelligence.

3. Communication under pressure — You're in the room when decisions get made. You explain architecture decisions to executives who don't code. You translate between the engineering reality and the business expectation, in real time, when both sides are frustrated.

4. High agency under ambiguity — This phrase is in every FDE job description. What it actually means: you can identify what needs to be done, decide what to build, and start building it before anyone has given you the full spec — because the full spec will never exist.

Most engineers are strong on #1. Some have #4 instinctively. The combination of all four is what's genuinely rare, and what drives the compensation.

The honest question before you pursue this path: do you have #3 and #4, or do you need to build them? The answer changes what preparation looks like.

---

The 4-part skill stack

1. Technical depth

The Anthropic FDE job listing specifies the exact technical requirements. They are not vague:

• Python proficiency — Not "familiarity." Production Python. You should be able to read a 3,000-line codebase you've never seen, understand what it does, and add to it within hours.
• TypeScript and/or Java — Many enterprise environments run Java. TypeScript is everywhere in modern web infrastructure. Pick one to be strong in alongside Python.
• Agent development — Not just prompting. Building agent loops with tool use, multi-step reasoning, fallback handling. The internal MCP server article covers the architectural patterns you need to understand.
• MCP servers — Model Context Protocol is how Claude connects to external data. Every FDE at Anthropic is building these. Learn the spec. Build one. Then build one that connects three data sources.
• Evaluation frameworks — Evals are the thing most junior developers skip and most production systems desperately need. If you can't write an eval suite that catches regressions, you can't maintain a production AI system.
• Production deployment — Auth, observability, rate limiting, error handling. The difference between "it works on my machine" and "it works at 1am when the client's biggest customer is using it."

Specific things to build to prove this stack:

• A working MCP server connecting 3 real APIs (not toy examples)
• An agent with tool use that handles failure gracefully
• An eval suite with 20+ test cases for a specific task
• Something deployed — even a small Heroku or Fly.io app that other people can use

2. Business acumen

This is the skill most engineers underestimate. An FDE isn't embedded in the client to build what they ask for. They're embedded to figure out what needs to be built, which is often different.

Concretely, this means:

• Understanding how the company makes money — what's the revenue model, what are the constraints
• Understanding what the data means — a CRM "opportunity" means something different at a pharma company than at a SaaS startup
• Understanding stakeholder incentives — the VP asking for this feature has a quarterly review. What are they trying to show? What would make them look bad?
• Understanding organizational dynamics — who has the technical credibility, who has the budget authority, who will block this at the last minute

You don't need an MBA. You need to have worked inside enough businesses that you develop an instinct for how they operate. Internships at real companies — especially in industries you'd want to work in as an FDE — are more valuable than side projects here.

Reading to do: anything that explains how enterprises actually make decisions. Clayton Christensen on jobs-to-be-done. Patrick Lencioni on organizational dynamics. Reading case studies from McKinsey or BCG on enterprise transformation — not to become a consultant, but to understand what problems enterprises pay to solve.

3. Communication under pressure

The failure mode here is not "can't talk to non-technical people." Most engineers can explain things. The failure mode is: can you explain things under pressure, in a room where someone is skeptical, when the answer is "this is more complicated than you think"?

This skill is built through practice, not reading. Ways to develop it:

• Teaching — TA a course. Lead a workshop. Explain technical concepts to people who don't code. The feedback is immediate.
• Engineering writing — Write architecture decision records (ADRs). Write post-mortems. Write technical documentation for non-technical audiences. This is also portfolio gold — more on that in the portfolio article.
• Cross-functional work — Deliberately take on projects that require you to work with non-engineers. The student who leads a hackathon team that includes non-CS people. The SWE who volunteers to present the eng team's work to the sales org.

The specific pattern FDE interviewers look for: "Tell me about a time you had to explain a technical decision to a non-technical executive." If you don't have an answer to this, you need one before you interview.

4. High agency under ambiguity

This is the hardest to fake and the hardest to develop without the right environment.

Signs you have it:

• You've completed a significant project without being told exactly what to do
• You've made architecture decisions without consensus from a team
• You've shipped something when the requirements were incomplete
• You've worked in an environment where "figure it out" was a real instruction, not a complaint

Signs you need to build it:

• Every project you've worked on had clear specs before you started
• You've never shipped something without multiple rounds of review
• You wait for direction before moving

How to build it: take on projects with genuine ambiguity. This might mean: picking a client-facing internship over a structured program. Starting a side project where no one tells you what to build. Contributing to an open-source project where the right approach isn't obvious. The goal is to accumulate decisions — many small ones, building the muscle for making them quickly under uncertainty.

---

The three transition paths

Path 1: CS student → FDE

Timeline: 18–24 months from junior year to first FDE role

What to do in school:

• Pick internships based on technical+client exposure, not brand name. A smaller company where you ship code that real users touch is better FDE preparation than a structured rotation at a big tech company.
• Build the technical stack: Python fluency, agent development, MCP servers. The portfolio projects article has the exact list.
• Practice cross-functional communication: TA, workshop, hackathon leadership with non-CS people.
• Apply directly to Anthropic's Forward Deployed Engineer, Applied AI role after graduation — it's the gold standard, and new grads with strong portfolios are competitive.

Where to look first:
Scale AI, Cohere, Anthropic, OpenAI have junior/associate FDE tracks. So does EY's new FDE practice. fwddeploy.com lists open roles. Palantir hires aggressively from universities — their Forward Deployed Software Engineer role is the classic entry point into this model.

Path 2: SWE → FDE

Timeline: 6–12 months of focused preparation

Who this works best for: Engineers with 2–5 years of experience who have shipped production systems, but in internal-facing roles (no client exposure) or without the AI/agent development stack.

What 6 months of focused prep looks like:

Months 1–2: Build the AI stack you're missing. If you've never built a production agent, build one. If you've never built an MCP server, build one. Do this in public — real GitHub repos with READMEs that explain your decisions.

Months 3–4: Build the portfolio projects. The five portfolio projects are designed to show FDE-specific capabilities: enterprise integration experience, eval frameworks, architecture decision records, post-mortems. If you've never written an ADR or a post-mortem for a real failure, write them now from past experiences.

Months 5–6: Apply and prepare for interviews. The FDE interview is different from standard SWE interviews. See the interview section below.

What transfers directly from SWE experience: Production thinking (error handling, observability, performance), systems design, shipping under pressure.

What you still need to build: Client communication stories, ambiguity navigation stories, AI-specific technical skills if you haven't worked on LLM applications.

Path 3: Consultant/analyst → FDE

Timeline: 12–18 months to technical proficiency

Who this works best for: People coming from business consulting, product management, or data analysis who have strong client and business skills but need to build the technical depth.

What transfers: Business acumen (you already understand what clients actually care about), stakeholder communication (you've been in those rooms), ambiguity tolerance (consulting is inherently ambiguous).

What you need to build: The technical depth is the hard part. Python proficiency at production level. Agent development. MCP servers. This is genuinely 12–18 months of focused learning if you're starting from scratch on the engineering side.

The honest advice: this path works, but don't underestimate how much engineering depth is required. FDE is not "consultant who knows some AI." It's an engineer who also happens to be good at client work. If you can't build the system yourself, you're a solutions engineer at best.

---

Where to apply

Direct:

• Anthropic FDE listing — the gold standard
• Palantir Forward Deployed Software Engineer (university and experienced hires)
• OpenAI (via DeployCo — new roles being added monthly)
• Scale AI (FDE team)

Consulting firms:

• EY (April 2026 launch, actively hiring)
• Accenture (Microsoft and ServiceNow FDE practices)
• Deloitte AI Center of Excellence

Job boards:

• fwddeploy.com — dedicated FDE job board, the best single resource for open roles

Enterprise internal roles:
Large banks, pharma companies, and logistics firms are building internal FDE functions. JPMorgan, Goldman Sachs, Pfizer, and UPS all have roles that are functionally FDE work under different titles. Search for "Applied AI Engineer," "AI Implementation Engineer," or "Enterprise AI Engineer" at these companies.

---

The interview

FDE interviews are different from standard software engineering interviews. What to expect:

Live system design for enterprise AI — Not "design Twitter." More like: "A retail company has sales data in Salesforce, inventory in an ERP, and customer service tickets in Zendesk. They want AI to help their regional managers make better inventory decisions. How do you build it?" You're being evaluated on your ability to decompose a real enterprise problem, not just your knowledge of distributed systems patterns.

Behavioral on ambiguity and client communication — Questions like:

• "Tell me about a time you had to deliver something when the requirements weren't clear."
• "Tell me about a time you had to explain a technical decision to a non-technical executive."
• "Tell me about something you shipped that broke in production and how you handled it."

These are not soft questions. They're evaluating specific capabilities that determine whether you can actually do the job.

Architecture decomposition case study — Take a real enterprise problem and whiteboard the architecture. The evaluation criteria: Did you ask the right clarifying questions? Did you identify the right constraints? Did you make defensible design decisions or just go with the most obvious answer?

Preparation advice: Have specific stories ready for all three behavioral categories. Practice explaining technical architecture decisions in plain English — out loud, not just in your head. Review the portfolio projects article and make sure you can speak fluently about every decision you made in each project.

---

The honest filter

You'll thrive as an FDE if:

• You've always felt like engineering roles are too internally focused — you want to see your work actually land with real users and real organizations
• You're comfortable being in meetings that engineers normally don't attend
• You can make decisions without full information without it paralyzing you
• You find messy real-world environments more interesting than clean greenfield projects

You should look elsewhere if:

• You need clear specs before you can start building
• Client work sounds exhausting rather than energizing
• You prefer going deep on one codebase for years rather than rotating through different environments
• You want a predictable engineering role with stable requirements

This is a genuine filter. The role is high-stakes, high-autonomy, and high-reward. Being clear-eyed about whether it fits you is useful information, not a failure.

The path is real. The demand is real. The compensation reflects the scarcity. If the filter passes, the next step is the portfolio.