Blog
/
Career
September 1, 2026

How to become a forward deployed engineer: skills, portfolio, and the interview loops

19 min read
Table of contents
Section oneSection two

There has rarely been a better-lit path into a hot role. Forward deployed engineering is growing at rates that make the rest of tech hiring look flat, with Indeed's index of postings up 5,230 percent over its January 2025 baseline by April 2026 and Bloomberry's count at 1,165 percent year over year. The pay clears most engineering ladders, from Indeed's $170,000 to $200,000+ broad market to $300,000 to $550,000 total compensation at mid-to-senior levels and beyond at the labs. And because the role is young, the competitive field is shallow: almost nobody has five years of FDE experience, which means the door is open to converts in a way established specialties never allow.

This guide is the conversion manual: what to build in yourself, what to build in public, where to aim, and how the interviews actually run. It assumes you know what the role is; if not, start with the full definition and the honest comparison against product engineering, then come back.

Step zero: check the fit before investing the year

The role rewards a specific temperament: energy from ambiguous rooms, curiosity about other people's businesses, and comfort owning things end to end with your name on them. It punishes engineers who experience customers as interruptions, however brilliant. Run yourself through the six-question fit check in the comparison article honestly. A "no" is not a failure; it is a year of misdirected effort avoided. A "yes" makes everything below worth doing properly.

The three skill buckets, and how to build each

The market has told us exactly what it screens for. Perspective AI's analysis of 1,000 FDE job posts found three buckets with remarkably stable frequencies: core engineering in 95 percent or more of posts, AI-application skills in 80 percent or more, and customer-facing discovery skills in 70 percent or more, the last bucket rising fastest. Your preparation is those three buckets, weighted by your starting point.

Core engineering: Python and/or TypeScript, SQL, cloud. If you are already a working engineer, this bucket is done; do not over-invest in it. If you are earlier in your career, the bar is end-to-end shipping rather than algorithmic brilliance: you should be able to take a problem from empty repo to running system alone, including the unglamorous parts, auth, deployment, error handling, that team environments usually absorb for you. FDE work has no team absorbing them.

AI application: LLM integration and retrieval. Not model training, application: calling models well, grounding them on real data, building the agent logic between calls, and evaluating whether the result actually works. The good news is that this bucket is learnable in weeks of building rather than years of study, and the field is young enough that three serious projects put you in its upper half. Build against real, messy data sources, because "worked on clean sample data" is precisely the failure mode enterprises are hiring FDEs to escape. The AI-weighted variant of the seat is covered separately in forward deployed AI engineer.

Customer-facing discovery: the differentiator. This is the bucket that decides offers, because it is the one most engineers never trained. Requirements discovery means extracting a buildable spec from people who cannot articulate their problem. The practice is available everywhere once you look: volunteer to scope a project for a nonprofit or a friend's business, run the discovery conversation, write the spec, build the thing, and notice what you got wrong. Do that three times and you have more real discovery experience than most engineering applicants ever bring. Inside a current job, the equivalent move is volunteering for every customer call, deployment escalation, and solutions conversation your team will give you; per Perspective, citing Stack Overflow's 2026 survey, 41 percent of AI engineers already spend serious time customer-facing, so the exposure is usually one raised hand away.

The portfolio: deployment stories, not repos

FDE hiring managers are not impressed by stars on a framework demo. The portfolio that converts is two or three deployment stories: complete narratives of taking a real organization's real problem to a running system in their environment.

The recipe for one story: find a real operation, a small business, a nonprofit, a team inside your current company, with a genuine integration-shaped problem, the kind where two systems do not talk and a human currently copies data between them. Run the discovery properly. Build the connection end to end, including credential handling you would defend to a security reviewer. Ship it where it actually runs, operate it for a month, and then write the story: the environment as you found it, what the discovery surfaced that the first conversation missed, what you built, what broke, and what the operation looks like now. That write-up, honest about the mess, is the single strongest artifact an FDE candidate can carry, because it is the job in miniature.

Note what this portfolio deliberately proves: not just that you can build, but that you can operate what you build. Familiarity with the operational side, how customer-specific code gets deployed, hosted, vaulted, versioned, and handed off, reads as seniority in interviews, and the fastest way to acquire it is to run your portfolio projects on real infrastructure. The FDE ops platform guide maps that landscape. You do not need a particular vendor to become an FDE; you do need to have operated something real. Archway's free tier is one way to do that at this scale: two bridges free, then $45 per bridge per month, credentials in an AES-256 vault, versions owned by the org, which is enough to ship a portfolio project the way a professional team would ship it and to speak from experience when the interviewer asks how you would manage customer credentials.

One deployment story, sketched

To make the recipe concrete, here is the shape of a real portfolio story, compressed. A candidate finds a regional nonprofit whose donations arrive through one platform while their CRM lives in another; a volunteer retypes every donation weekly. Discovery reveals the actual requirement is not the sync everyone assumed but deduplication, because donors give through three channels and the thank-you letters keep double-counting. The candidate builds the connector with dedup logic, stores the platform credentials properly instead of pasting them into the script, ships it, and operates it through one month-end. The write-up covers the wrong first assumption, the credential decision, the Tuesday it broke when the donation platform changed a field name, and the fix from version history. Total elapsed time: three weekends. That story beats five polished demo repos in every FDE loop it enters, because the interviewer has lived every beat of it.

The six-month conversion plan

For a working engineer converting deliberately, the timeline compresses to roughly six months at eight to ten focused hours a week.

Months one and two: the AI-application bucket. Build three small systems against real, messy data: a retrieval assistant over an actual document pile, an agent that reads and writes to two real services, an evaluation harness that measures one of them honestly. Stop when you can discuss grounding, tool use, and failure modes from experience rather than reading.

Months three and four: deployment story one. Find the real operation, run the discovery, build, ship, operate. Keep a build journal from day one; it becomes the write-up. Start raising your hand for every customer-adjacent moment your current job offers, because interview stories need recency.

Month five: deployment story two, and applications. The second story goes faster and rounds out the first (different environment, different integration shape). Rewrite the resume with the translation rules below, and open applications at two companies per tier while the second story is still in flight; loops take weeks to schedule, and operating a live project during interviews is a feature, not a risk.

Month six: loops. Two mock customer-scenario sessions with a friend playing the difficult stakeholder, out-loud practice on two system-design prompts, and STAR-with-code passes over both stories. Then interviews, with the current-month story as your freshest material. Schedule the loops closest-to-favorite last: your customer-scenario performance improves measurably between the first live loop and the third, and it is the round where practice against real interviewers compounds fastest.

The plan's quiet advantage: every artifact it produces is real. Nothing in it is interview theater, which is why it survives interviewers who probe.

Where to aim, by starting point

The market sorts into three tiers, mapped fully in our living list of companies hiring FDEs.

Structured programs (Salesforce and the large-company cohort) run leveled paths from new grad to principal, with real onboarding; Salesforce's program includes a six-week bootcamp. Aim here as a new grad, an early-career engineer, or a first-time convert who wants the craft with a support system.

The established frontier (Palantir, OpenAI, Anthropic, Stripe, the data platforms) wants engineers who already ship end to end and thrive unsupervised. Aim here with five-plus years and at least one strong deployment story; the brand and the intensity both compound fastest.

The vertical-AI cohort (Sierra, Harvey, Glean, Decagon, and peers) offers maximum ownership and variance. Aim here if you want your individual work visible in company outcomes and can price startup risk.

Apply two per tier rather than twenty scattershot, and tailor per tier: programs want evidence you operate well inside process, the frontier wants evidence you need none, and startups want evidence you can be the process.

The conversion also runs differently by background, and knowing your path's specific gap saves months. From product engineering, the common path: your gap is buckets two and three, and your risk is underselling customer moments you already had; mine your history for every escalation and deployment before writing new stories. From sales or solutions engineering: your discovery skills are ahead of most engineers, and the screen doubts your code; the fix is deployment stories where the build is unambiguously yours, and a resume that leads with shipped systems rather than won deals. From data science: your AI bucket is strong and your gap is production shipping; one story that takes a model from notebook to operated system in a real environment answers the doubt directly. From consulting: you have run discovery for years and the doubt is whether you build or delegate; same fix as the SE path, with special attention to operating what you built past delivery day. From a bootcamp or new grad: aim at the structured programs, where the leveled path exists on purpose, and know that one genuinely operated deployment story moves you further than any credential, because almost no early-career applicant has one.

Questions to ask them

The interview runs both ways, and four questions protect you from the bad version of this job. Does customer work ship through its own lane, or through the product backlog? Where do customer credentials live, and who can read them? Is there a qualification gate on FDE time, or does every AE command it? What happened the last time an FDE left, in detail? Strong answers describe a run function: a lane, a vault, a gate, and a handoff that was an operation rather than a crisis. Weak answers describe the fire brigade, and the compensation premium at fire brigades is hazard pay wearing a recruiting deck. Ask in the hiring-manager round; the reaction to being asked is itself data.

A note on the offer itself: at the frontier, equity carries 55 to 70 percent of top-tier packages, so negotiate the instrument you actually value, and remember that scarcity premiums favor candidates precisely while the field stays shallow, which is now.

How the interviews actually run

Loops are converging across the market, and Exponent's cross-company FDE interview guide documents the pattern. The canonical shape, visible in Salesforce's published four-stage process, runs: recruiter screen, a hiring-manager round on your AI and project experience, a technical round on system and agent design with coding, and a panel built around a customer scenario plus behavioral depth.

Three stages deserve specific preparation. The technical round tests design under realistic constraints rather than algorithm trivia: expect a prompt like wiring an AI capability into a legacy environment, and practice narrating tradeoffs, what you would ask the customer, what you would build first, where the credentials live, out loud. The customer scenario is the differentiator round: a mock discovery call or an unhappy-stakeholder roleplay. The winning behavior is asking questions before proposing solutions, translating jargon in both directions, and committing to something concrete at the end. Engineers lose this round by solutioneering in minute two; reformed consultants lose it by never landing on a buildable answer. The behavioral panel wants deployment stories in STAR shape with real code underneath, which is exactly what the portfolio above manufactures.

Palantir's loop, the oldest in the category, is famous for problem decomposition under ambiguity, messy real-world prompts where the evaluation is how you carve the problem, not whether you finish. The preparation is the same discovery practice as everything else in this guide, which is the pleasant secret of FDE interviewing: unlike leetcode seasons, the prep is the job.

Translating your resume

Most converts undersell themselves by describing product work in product terms. The translation rules: lead every bullet with the outcome in the customer's terms, then the system; surface every moment you owned something end to end; and promote to headline status anything involving ambiguity, integration with external systems, or direct stakeholder contact. "Built order-sync service" becomes "took a retail customer's order-reconciliation from a 6-hour manual process to real time, from discovery through production, integrating their ERP." Same work, correct frame. Sales engineers converting in should do the reverse translation: lead with what you built and shipped, because the FDE screen is watching for proof you produce code, not just demos.

Your first 90 days in the seat

Getting hired is the midpoint; the first quarter decides your trajectory. Three habits separate fast starters. Ship something real in week one, however small: the role's currency is deployed value, and early velocity buys patience for everything else. Learn the estate before you add to it: read your team's existing customer builds the way you would read a codebase you joined. And build custody habits from day one, credentials vaulted, builds on the sanctioned platform, decisions noted in one sentence, because the engineer who operates cleanly from the start becomes the one trusted with the accounts that matter. If your new team runs on a real operational backbone, these habits are the default path; if it does not, being the person who knows what one looks like is how new hires end up leading infrastructure decisions in month three.

The internal route: become your company's first FDE

One path skips the interview loop entirely: create the seat where you already work. If your company sells software that keeps needing custom integration at customer sites, and those requests currently die in the product backlog or burn out whoever is closest, the FDE function already exists unstaffed. The pitch to leadership writes itself from this article's sources: the deals stalling on technical objections, the industry failure rates your customers are living, and the fact that every serious competitor is hiring the role by name. Volunteer to take two stalled customer requests end to end as a pilot, run them with proper custody from day one, and present the outcome in deal terms. Employee zero of a function gets scope no lateral hire ever starts with, and you skip the one thing external candidates cannot fake: you already know the product. The risk is the fire-brigade trap, inheriting the work without the lane, so bring the operating model to the same meeting where you propose the role.

Reading that repays the hours

The canon is short, which is an advantage. Nabeel Qureshi's Reflections on Palantir is the culture document: read it to understand what the role feels like at full intensity and why the model works. The Lenny's Newsletter conversation with Qureshi covers where the seat leads. Exponent's interview guide is the loop manual. And the operational literacy that separates candidates lives in the FDE ops corpus: the platform landscape, the team operating model, and the handoff discipline. An afternoon across those six pieces puts you in the top decile of applicants on context alone, because most candidates prepare for the engineering and improvise the rest.

If you are starting from zero engineering

One honest addendum for readers without a software background at all: this role is not the entry point into engineering, because it presumes the very independence that junior engineers go to teams to learn. The realistic sequence is engineering first, forwardness second: build the core bucket through whatever route fits your life, then run this guide's conversion plan from a first engineering seat, deliberately choosing early roles with customer exposure. Two accelerants shorten the road. Adjacent professional experience, sales, support, operations, consulting, counts for more in this field than anywhere else in engineering, because the third bucket is half the job and you may already own it; the gap analysis in the paths section above applies to you in reverse. And AI-assisted development has genuinely lowered the floor for shipping real systems solo, which means the deployment-story portfolio is reachable earlier in a career than it used to be, provided you can debug and operate what you ship rather than only generate it. Plan on the sequence taking a couple of years rather than six months, and know that the destination role will still be young and undersupplied when you arrive.

The mistakes that cost offers

Applying only to the labs, where competition is fiercest, instead of tiering. Leading interviews with technology instead of customer outcomes. Treating the customer-scenario round as soft-skills theater instead of the actual differentiator. Having no answer for the operational questions, where does customer code run, who holds the keys, because nothing in product engineering ever asked. And waiting to be ready: the field is eighteen months old for almost everyone in it, the demand curve is a 5,230 percent index slope, and the candidates getting hired this quarter are the ones who built two deployment stories and applied, not the ones finishing a curriculum. Build one real thing for one real operation, run it like a professional would, and go. Eighteen months from now the field will have its first deep bench of experienced FDEs and its first standardized interview prep industry; the window where preparation this simple clears the bar is exactly as wide as the shortage, and shortages in tech have never once waited politely.

Sources and notes

A long list of live bridges: approval rules, usage reports, data migrations, SLA alerts, reconciliation, provisioning and compliance exports

Deliver hyper-personalized software at scale

Start free

Product

ProductSecurityPricing

Legal

Terms of UsePrivacy PolicyPurchase Terms

© 2026 Archway. All rights reserved.