DEV Community: Armando Gonzalez

The 30-day plan to break into Forward Deployed Engineering (2026)

Armando Gonzalez — Tue, 21 Jul 2026 01:43:30 +0000

Can you actually break into Forward Deployed Engineering in 30 days? A viral answer to that question landed this week: Greg Isenberg published a 51-minute breakdown with Voss of Veric Agents called "FDE: The $1M/Year AI Job Explained", including a week-by-week roadmap for going from software engineer (or consultant) to working FDE. This post distills that plan, adds context from the rest of the FDE hiring market, and — because a plan only matters if you execute it — shows you how to pressure-test yourself at each checkpoint.

The core argument: intelligence is commoditized, deployment is the edge

The video's thesis matches what we've been writing here for months: every company can now buy the same frontier models, so intelligence itself is no longer a moat. The advantage moved to where, how, and why intelligence gets applied inside a specific business — and the person who owns that bridge is the Forward Deployed Engineer. Palantir coined the role; the AI wave made it the hottest title in tech. Comp discussed in the video ranges from $150K base with significant equity up to $1M/year for people who are genuinely elite at both halves of the job. (Our own market data on typical ranges is in how much FDEs make.)

The rare combination the role demands: consultant-grade communication and business judgment and production-grade engineering — models, evals, guardrails, harnesses, reliability. Not the average of both. The best of both.

The three-stage loop every FDE engagement follows

Audit — understand the business reality. Not the documented process — the real one. "An email arrives" actually means 40+ senders, no two formatted alike, half of them exceptions living in one person's head. You sit with the people who do the work until the real workflow, with all its exception paths, is mapped.
Eval — turn non-determinism into evidence. Build a golden dataset from historical data, define what correct looks like, run the system against it, and investigate every failure: missing data, wrong record pulled, bad routing. Route anything unsafe to a human.
Deploy — integrate with what already exists (never force a migration), run shadow mode, increase autonomy gradually, and monitor the KPIs and SLAs that matter. Then the loop runs again, because fixing one workflow exposes the next bottleneck.

One line from the video worth burning in: "There's only one way something can go right, but a thousand ways it can go wrong. If you're only building the happy path, you're worth nothing." Exception handling is where FDE value concentrates — in the audit, in the build, and in the interview that gets you the job.

The 30-day plan, week by week

Week 1 — build an agent that completes a real loop

Pick one real enterprise back-office workflow (finance, HR, procurement, logistics, sales) and get it in granular detail. Then build an agent for it: agent looping, tool usage, guardrails, context and memory, and a full audit trail — if you can't show a client exactly what the agent did, they will never trust it. Checkpoint: a working agent with tools, guardrails, deliberate memory, and logged traces for one task.

Week 2 — make it recover

Defined JSON schemas instead of free-form text, schema validation, and above all failure handling. Enumerate the unhappy paths — malformed inputs, missing records, ambiguous cases — and build the agent around them. Checkpoint: a system that degrades gracefully instead of a demo that breaks.

Week 3 — make it measurable and economically viable

Retry logic, a golden dataset for evals, and cost optimization: can a cheaper, faster model handle subtasks? Then measure the only three buckets a business cares about — revenue uplift, risk mitigation, cost savings. Checkpoint: an evaluated agent with known failure modes, measured costs, and a golden dataset.

Week 4 — defend the system like an FDE

Rehearse it twice. As an engineer: architecture, decisions, iterations, how accuracy went from 70% to 95%. As a VP: the problem, the outcome, the evidence, the risk, the economics. Then pitch it to real businesses and let them tell you what you got wrong. Checkpoint: on day 30 you have evidence you can do the job, not just the vocabulary — you did the job before you had the title.

Where most people fail this plan

We run timed FDE case studies and grade the transcripts, and the pattern is consistent: people are far stronger at building than at defending under time pressure. The week-4 skill — decomposing a messy customer scenario live, stating scope, architecture, eval plan, rollout, and asks, then surviving pushback — is the round that actually decides FDE interviews. It's also the one you can't practice by watching videos.

That's exactly what the free Case-Study Arena exists for: a realistic customer scenario with hidden traps, a running clock, and an AI grader that scores you against the rubric top labs use. Run it on day 1 of your 30 days to get your baseline, and again in week 4 to see if your defense actually improved. It's free and takes about 10 minutes.

The honest caveats

Thirty days gets you evidence and fluency, not seniority. Voss's own version took a year; the 30-day frame is the compressed, highest-signal path.
The role is crowded with new entrants exactly because videos like this one are pulling attention to it. The differentiator is proof-of-work: a system with an audit trail, an eval report, and economics you can defend beats any certificate.
If you're starting from zero engineering background, budget longer. The plan assumes you can already ship software.

The full breakdown is worth your 51 minutes: watch the episode. Then stop watching and start the clock — literally: try the free case.

Cross-posted from a10x.dev. If you want to pressure-test yourself on the case-study round — the one that decides FDE loops — the Case-Study Arena is free: a timed, realistic customer scenario graded against the rubric top labs use.

Forward Deployed Engineer interview questions (2026): every round, with real examples

Armando Gonzalez — Fri, 17 Jul 2026 22:31:59 +0000

Forward Deployed Engineer interview questions fall into five buckets that map to the five stages of the loop: motivation ("why FDE, not SWE?"), a take-home build, a technical deep-dive on production AI (RAG, evals, guardrails), the signature customer case study, and behavioral questions about ownership and ambiguity. The case study is the round that decides most offers, and it is the one candidates prepare for least. Below are the real questions asked at each stage, what the interviewer is actually scoring, and how to prepare.

What FDE interviews test that SWE interviews don't

A standard software interview scores algorithmic coding and system design. An FDE loop scores those too, but weights two things a SWE loop mostly ignores: production AI judgment (can you reason about token cost, latency, evals, and failure modes on a real deployment?) and customer judgment (can you take a vague, underspecified business problem and decompose it into a plan out loud, while asking the right clarifying questions?). Across Palantir, OpenAI, Anthropic, Google, and ElevenLabs the loop shape is consistent, and the case study carries the highest weight with the lowest pass rate (Exponent, DataInterview).

Round 1 — Recruiter screen: the "why FDE" questions

The screen is short and filters for motivation and communication. Expect:

"Why a Forward Deployed Engineer role and not a standard software engineering role?"
"Walk me through a time you worked directly with a customer or non-technical stakeholder."
"What's a system you took from nothing to running in production? What broke?"
"How comfortable are you spending half your week in front of customers?"

What they score: a crisp, non-generic answer to "why FDE." The failure mode is sounding like you want FDE because SWE roles were competitive. Have one sentence that ties your enjoyment of customer contact and end-to-end ownership to the role.

Round 2 — Take-home: build a small end-to-end system

Most loops include a take-home of roughly three to five hours. Typical prompts:

"Build an agent that answers questions over this set of documents, with retrieval and tool use. Include a short writeup of your design trade-offs."
"Given this messy dataset, build a small pipeline that extracts structured records and flags low-confidence outputs."
"Prototype a support-triage workflow: classify an incoming ticket, draft a response, and decide when to escalate to a human."

What they score: whether you ship something that runs, whether you handle errors and edge cases, and whether your writeup shows you thought about evaluation and cost. Candidates who build one realistic portfolio project in advance finish these fast, because the take-home is a variation on work they've already done.

Round 3 — Technical deep-dive: production AI questions

You defend the take-home, then go deep. The most common questions in 2026:

"How would you evaluate this agent? Walk me through your golden dataset, regression suite, and how you'd catch drift." (Evals are the single most common reason candidates fail final rounds at OpenAI and Anthropic.)
"When would you fine-tune versus prompt versus use RAG? Defend the trade-off for this use case."
"How do you keep a RAG pipeline from hallucinating? What guardrails do you add, and how do you test them?"
"This agent will run 100k times a day. Walk me through your token cost, latency budget, and where you'd cache."
"A customer says the agent 'sometimes gives wrong answers.' How do you turn that into a measurable, fixable problem?"

What they score: whether you think in terms of measurable production behavior rather than demos. The strongest answers always come back to evals and observability.

Round 4 — The case study: the round that decides the offer

This is the signature FDE round and it has the lowest pass rate (around 40%) and the highest weight (around 30% of the decision). An interviewer role-plays a customer with a vague problem, and you have 45-60 minutes to decompose it into a plan. Real examples:

"A hospital network gets 38,000 support tickets a month, many containing patient data. They want to automate triage. Where do you start?"
"A bank wants an internal assistant over ten years of policy documents, but compliance won't allow errors. How do you scope and stage this?"
"A logistics company wants to 'use AI to reduce delays.' Turn that into a concrete first project."

What they score is not the final answer. It is the process: do you ask clarifying questions before designing, do you name constraints (data access, PHI/PII, latency, eval gates, rollout risk), do you propose a shadow rollout instead of a big-bang launch, and do you communicate the plan clearly under ambiguity. Thinking out loud is the skill being measured. You can practice it: our free Case-Study Arena runs real cases like the hospital-triage one above against a hidden hiring rubric and grades your decomposition, so you get reps on this exact round before it counts.

Round 5 — Behavioral: ownership and ambiguity

Standard behavioral structure, FDE-flavored:

"Tell me about a project where the requirements were unclear and kept changing."
"Describe a time you disagreed with a customer or stakeholder. What did you do?"
"Tell me about something you shipped that failed in production. What did you learn?"
"When have you owned a problem end-to-end that wasn't technically your job?"

What they score: ownership, comfort with ambiguity, and honest reflection. Use concrete stories with a measurable outcome; avoid stories where you were only a small part of a large team.

How to prepare in the right order

The mistake is grinding LeetCode. The FDE loop rewards a different order of operations:

Build one realistic end-to-end project (an agent, its eval suite, and a shadow-rollout writeup). This single body of work is what you defend in Round 2 and Round 3.
Drill the case study out loud, ideally with mock interviews or a grader, because it is the highest-weight and least-practiced round.
Prepare four to five behavioral stories with measurable outcomes.
Write a one-sentence, specific answer to "why FDE."

The candidates who convert are not the ones who memorized trivia. They are the ones who built the artifacts and practiced reasoning through ambiguity out loud until it was automatic.

The round that fails the most candidates is the customer case study, and it is the one you can least practice alone. I built a free interactive version: take a real FDE case on a timer — no signup — and get an AI-graded review against the rubric hiring teams actually use.

This post was originally published on the A10X blog.

How do you become a Forward Deployed Engineer? (2026)

Armando Gonzalez — Thu, 16 Jul 2026 20:28:08 +0000

You become a Forward Deployed Engineer by developing production AI fluency, building a portfolio that proves you can ship agents into production, and passing an interview loop that tests technical depth, customer judgment, and reasoning through ambiguity in roughly equal measure. You do not need a PhD or an ML research background. You need to demonstrate that you can take a vague problem and turn it into a working, evaluated system. Here is the concrete path.

The skills that matter

Analysis of 1,000 FDE job postings shows the most-requested skills are Python (66%), AI agents (35%), TypeScript (35%), AWS (32%), and LLMs (31%). Group them into three layers:

Engineering foundation. Fluent Python is non-negotiable; TypeScript/JavaScript helps for full-stack work. Add SQL, data pipelines, and cloud deployment: Docker, one major cloud (AWS/GCP/Azure), and ideally Kubernetes and infrastructure-as-code (Terraform). FDEs write real production code, so this layer is table stakes.

Production AI fluency (the 2026 differentiator). This is where offers are won: agent orchestration (agent loops, tool use, frameworks like LangGraph), RAG pipelines, prompt engineering and versioning, and system design with new primitives — token cost, latency budgets, eval gates, and MCP servers. Most important of all is evals: golden datasets, regression suites, drift detection, and tracked failure modes. Evals engineering is the single most common reason candidates fail FDE final rounds at OpenAI and Anthropic.

Customer-facing judgment. FDEs are evaluated on a T-shaped profile: deep technical expertise plus the ability to reason out loud through an ambiguous customer problem and communicate clearly. This is a genuine skill you can practice, not a personality trait.

The portfolio artifacts that get you hired

Portfolio projects showing production deployments with real integration work outweigh academic projects. One well-executed end-to-end project beats ten toy demos. Build a single realistic system and produce three artifacts from it:

A production-style agent. Pick a real, narrow problem (for example, a support-triage agent or a document-processing workflow) and build it end-to-end: tool use, retrieval over real data, error handling, and an API or integration into an existing system. Deploy it, don't just run it in a notebook.
An eval suite for that agent. This is the artifact that separates you from the pack. Build a golden dataset, a regression suite that runs on every change, drift detection, and a documented catalog of failure modes with how you handle them. Show a before/after where evals caught a regression.
A shadow-rollout writeup. Demonstrate deployment judgment. Run the agent in shadow mode against real or realistic traffic, compare its outputs to the current process, quantify quality and cost/latency, and write up how you'd stage a safe rollout. This proves you think like someone who ships to customers, not just someone who builds.

Package all three with clear technical documentation. The documentation itself signals customer-facing communication skill.

The interview loop

The 2026 FDE interview process runs three to six weeks and typically has five stages, with a shape that is consistent across Palantir, OpenAI, Google, ElevenLabs, and others:

Recruiter screen (~30 min). Heavy on "why FDE, not SWE?" Have a crisp answer.
Take-home project (~5 hours). Build a small end-to-end system. Your portfolio work makes this fast.
Take-home walkthrough + technical deep-dive (~60 min). Defend your design, then go deep on RAG, prompting vs. fine-tuning trade-offs, guardrails, and evals.
The case study (45–60 min). The signature round: a hypothetical customer hands you a vague problem and you decompose it into a plan. It has the lowest pass rate (around 40%) and the highest weight (around 30%). Practice thinking out loud and asking clarifying questions.
Behavioral. Ownership, ambiguity, and customer stories.

A realistic timeline

Engineers with a solid backend or DevOps background typically need four to eight weeks of focused preparation to build a relevant portfolio and drill the FDE-specific formats. The gating factor is deliberate practice across all three round types, not raw hours. A workable two-week sprint if you already code: week one, build the agent and its eval suite; week two, run the shadow rollout, write everything up, and drill the case-study format with mock interviews. If you're coming from a less deployment-oriented role, expect the longer end of the range.

The fastest path is not memorizing trivia. It's building the one project that produces all three artifacts, because that same work is what you'll defend in the deep-dive, what proves your evals skill, and what demonstrates the deployment judgment the case study is testing for.

FAQ

What skills do you need to become a Forward Deployed Engineer?
Fluent Python (in 66% of postings), plus AI agents, TypeScript, and a cloud like AWS. The 2026 differentiators are production AI fluency, agent orchestration, RAG, prompt engineering, and especially evals, plus customer-facing judgment: the ability to reason out loud through an ambiguous problem and communicate clearly.

What portfolio gets you hired as an FDE?
One end-to-end project that produces three artifacts: a deployed production-style agent with real integrations, an eval suite for it (golden dataset, regression tests, drift detection, failure modes), and a shadow-rollout writeup comparing it to the existing process. Production deployments with real integration work outweigh academic projects.

What is the FDE interview process like?
It runs three to six weeks with about five stages: recruiter screen, a roughly five-hour take-home, a technical deep-dive defending your design, a behavioral round, and the signature customer case study. The case study carries the most weight (~30%) and the lowest pass rate (~40%), so practice decomposing vague problems out loud.

How long does it take to become a Forward Deployed Engineer?
For engineers with a solid backend or DevOps background, roughly four to eight weeks of focused preparation. If you already code proficiently, a concentrated two-week sprint can produce the core agent, eval suite, and shadow-rollout writeup. Less deployment-oriented backgrounds take longer.

I put together a free interactive way to practice the round that fails the most people — the customer case study. No signup: take a real FDE case on a timer and get an AI-graded review against the rubric hiring teams actually use.

This post was originally published on the A10X blog.