Forward Deployed Engineer skills checklist (2026)

1. Core engineering skills

The engineering floor for an FDE is higher than most candidates expect, and it is measured differently than in standard IC SWE roles. The bar is not "knows the language" — it is "can debug a production incident in an unfamiliar codebase, in an unfamiliar stack, with a customer watching the clock." That requires genuine fluency in at least two languages and the discipline to ramp a third under time pressure.

Language fluency. Python is table stakes across every FDE employer — it is the language of data pipelines, quick integrations, LLM wrappers, and the exploratory scripts that become production systems. TypeScript is the practical second: most customer-facing surfaces run in the browser or on Node, and FDEs who cannot ship a functional interface without pairing with a frontend engineer are a deployment liability. Beyond those two, one systems language — Go, Rust, or Java — rounds out the stack for the performance-sensitive infrastructure you will encounter in enterprise customer environments. "Fluency" means you can read an error in the language, trace it to the root cause without a tutorial, and write a fix without asking for a syntax cheat sheet.

API integration depth. FDEs spend a disproportionate share of their time at the boundary between systems that were not designed to talk to each other. The skills that matter here are: reading API documentation fast enough to ship a working integration in hours rather than days, debugging authentication flows (OAuth 2.0, API key schemes, mutual TLS) without external help, handling pagination and rate limits correctly the first time, and designing retry and error-handling logic that survives the real-world failure modes of third-party APIs (504s, malformed responses, silently incorrect data). The integration skill that consistently separates strong FDE candidates from weak ones is the ability to read someone else's API and immediately understand its mental model — not just its endpoints.

Debugging unfamiliar production systems. You will routinely be handed production systems you did not build, running on infrastructure you do not control, exhibiting behavior you have never seen. The skill is a debugging methodology, not familiarity with specific tools: read the logs before forming a hypothesis, verify the hypothesis against actual values before writing a fix, understand what "working" looks like before touching anything. Strong FDEs narrate their debugging process to the customer in real time, converting a stressful incident into a demonstration of competence. Weak FDEs panic and thrash, making changes without understanding what the changes do.

Reading code fast. Before you can change anything in a customer codebase, you have to understand it. The practical skill is reading unfamiliar code at speed: tracing a data flow from entry point to storage, identifying where business logic lives versus where framework boilerplate lives, recognizing naming patterns that indicate assumptions the original author made. Practice reading large open-source codebases you have never contributed to and producing accurate one-paragraph summaries of how a given subsystem works within 20 minutes. This is a trainable skill that most engineers never deliberately practice.

Full-stack comfort. FDEs are not specialists. A data pipeline that runs perfectly but produces output no one can access has not solved the customer's problem. The required range is frontend (can ship a readable, functional UI — not beautiful, but usable), backend (can design an API, write database queries, manage authentication), and infrastructure (can containerize an application, deploy it, read its logs, and diagnose a failed deployment). The depth requirement at each layer is "not blocked by it" rather than "could lead a team doing only this." The specialist who is excellent at one layer and helpless at the others is less useful in the field than the generalist who is competent at all three.

2. AI/LLM-specific skills

This is the differentiator that separates FDE hiring in 2026 from what it looked like two years ago. At Palantir, where the FDSE model originated, the AI/LLM layer was historically thin — the work was data engineering and platform integration. At OpenAI, Anthropic, Scale AI, and Cohere, it is now the primary technical surface. Even at Palantir, the AIP platform has moved AI fluency from optional to expected for active listings. Candidates who treat this section as a future specialization to develop are behind.

Prompt engineering as an engineering discipline. Writing a prompt that works in a demo is not the same skill as writing a prompt that works reliably in production across the full distribution of customer inputs. Production prompt engineering involves: version-controlling prompts alongside code, A/B testing prompt variants against a representative sample of real inputs, isolating prompt changes from model version changes, and designing prompts that degrade gracefully when the input is malformed rather than silently producing wrong output. The mental model is software engineering applied to natural language: prompts are contracts with a probabilistic counterparty, and they require the same specification discipline as any other interface.

Evals design. An LLM feature without an evaluation set is a feature you cannot improve without breaking. FDEs are expected to design and maintain eval sets for the AI features they deploy: a ground-truth dataset of representative inputs and expected outputs, an automated scoring mechanism (model-graded, code-graded, or human-graded depending on the task), and a threshold below which the feature does not ship. The skill of writing a good eval set is underrated — it requires deeply understanding the customer's success criteria, which is a customer-facing skill as much as a technical one. FDEs who build eval sets collaboratively with the customer ("what does a correct answer look like to you?") produce better evals and build more customer trust than those who design evals unilaterally.

Retrieval pipelines. Retrieval-augmented generation (RAG) is the dominant architecture for grounding LLM outputs in customer-specific data, and FDEs are expected to build and debug these pipelines end-to-end: chunking and embedding documents, choosing and operating a vector store, designing retrieval queries, handling the cases where retrieved context is insufficient or contradictory, and tuning the pipeline to improve both recall and precision on the customer's real query distribution. The failure modes of RAG pipelines (hallucination from insufficient context, irrelevant retrieval from poor chunking, stale embeddings from infrequent re-indexing) are now standard FDE interview territory.

Fine-tuning vs. in-context decision-making. FDEs need a principled framework for deciding when to fine-tune a model versus when to solve the problem in-context. The practical heuristic: in-context first (faster, easier to debug, works for most customization tasks), fine-tuning only when the in-context approach hits a wall (insufficient context window, latency requirement below what long-context inference allows, consistent output format that is expensive to enforce via prompting). Fine-tuning is not a magic bullet and introduces its own maintenance burden (re-training on new data, tracking model drift, managing model versions in production). Most FDE deployments never need fine-tuning; knowing when they do is the skill.

Latency and cost at production scale. A pipeline that works for 10 requests per day with no budget constraint is not a production AI feature. FDEs are expected to reason about: token costs per request and per user, p50/p95 latency and how to reduce it (caching, streaming, model selection, parallel requests), cost at scale (what does this feature cost at 100k requests per month, and is that acceptable to the customer?), and the tradeoffs between model size, cost, and quality for a given task. These conversations happen with customers, not just internally — FDEs who cannot translate technical cost constraints into business terms cannot close the customer on the deployment plan.

Tool/function-calling architectures. Agentic AI features — where the model can call external tools, execute code, or query APIs — are now a standard part of FDE deployments. The FDE skill here is designing the tool interface (what the model can call, what parameters it receives, what it can and cannot do with the results), building and debugging function-calling loops, handling the failure modes (model calls the wrong tool, model calls the right tool with wrong parameters, tool returns an error the model does not handle gracefully), and implementing human-in-the-loop checkpoints for actions with real-world consequences. This is where prompt engineering and software engineering fully merge.

3. Customer-facing skills

FDE candidates consistently underestimate how much these skills are evaluated in the loop — not as soft skills assessed via behavioral questions, but as demonstrated competencies tested through case interviews, live customer simulations, and role-play scenarios. The customer-facing round at Palantir and OpenAI is weighted as heavily as the technical design round. Prepare accordingly.

Running technical discovery. The first meeting with a new customer is a diagnostic, not a demo. Effective technical discovery produces: a clear picture of the customer's actual problem (not the problem they think they have), an inventory of the technical environment (what data exists, where it lives, what format it is in, what systems touch it), the implicit constraints that the customer has not named (security requirements, integration limitations, the person who will veto the deployment if you don't surface them), and a shared definition of what success looks like in week 6. Discovery is an active skill — bad practitioners let customers monologue while taking notes; good practitioners use targeted questions to build a mental model of the system in real time and surface the constraints the customer doesn't know are constraints yet.

Writing exec-readable status updates. Your deployment summary will be read by people who have three minutes and who need to make a decision. The skill is radically compressing technical reality into decision-ready language: what is working, what is blocked, what needs a decision from the customer, and what the consequence of no decision is. "We are making good progress" is not a status update. "Document extraction is complete and passing evals; we are blocked on customer security review for the API key; without sign-off by Friday the go-live date moves two weeks" is a status update. Strong FDEs write status updates that make it easy for the customer to act, not updates that make it easy for the FDE to look busy.

Scoping a POC without overpromising. The scope of a proof of concept is the single most common source of broken trust in FDE engagements. A POC that under-scopes fails to demonstrate value; a POC that over-scopes misses the deadline, which damages trust regardless of the quality of the work completed. The skill is: define success criteria before writing a line of code, get explicit agreement on what in-scope means and what out-of-scope means, build in explicit checkpoints where scope can be adjusted, and say "that is out of scope for this POC but here is how we would approach it in a production deployment" every time the customer adds a requirement. FDEs who say yes to everything and then miss the deadline are more damaging to the customer relationship than FDEs who held the line on scope from the start.

Saying "no" without losing the account. The FDE version of "no" is almost always a redirect: "That's not something we can deliver in this timeline, and here is why, and here is what we can deliver instead." The failure mode is either capitulating to every request (which kills timelines and creates technical debt) or saying no without offering an alternative (which reads as unhelpful and damages the relationship). Strong FDEs maintain a mental model of what the customer actually needs versus what they are asking for, and redirect asks toward outcomes rather than features when the ask is off-track.

Presenting to non-technical buyers. FDEs frequently present to audiences that include engineering leadership, business leadership, and end users simultaneously. The skill is adapting the level of technical detail in real time: enough depth for the engineering lead to feel confident, enough clarity for the business lead to see the ROI, enough accessibility for the end user to understand what they are agreeing to. This is not "dumbing it down" — it is precision engineering applied to communication, using exactly the right detail for each audience rather than the same presentation for everyone.

4. Domain depth that compounds

FDEs work across industries — an FDE at Palantir may have accounts in financial services, defense, and healthcare within the same year. The skill is not deep expertise in any one vertical at the start; it is the ability to absorb a new domain fast enough to be technically credible within the first two weeks of a new engagement.

The framework that works: before the first customer meeting, identify the three questions a knowledgeable industry practitioner would ask about the problem you are solving, and be able to answer them. Find the regulatory constraints that govern data handling in this vertical (HIPAA for healthcare, SOC 2 for enterprise software, FedRAMP for government, FINRA for financial services) and understand how they affect your deployment design before you are asked. Read the trade publications and analyst reports that the customer's leadership reads — you do not need to be an expert, but you need to demonstrate that you have done the work of understanding their world. The signal you are sending is: "I take your business seriously enough to prepare." The domain you are demonstrating is judgment, not industry knowledge.

Domain depth compounds over time. An FDE who has done three deployments in financial services begins to recognize patterns — the data architecture concerns, the compliance conversation, the stakeholder dynamics — that make each subsequent engagement faster and more effective. FDEs who rotate through domains without retaining anything from each engagement miss this compounding. The discipline is to write deployment postmortems that extract the transferable patterns from each engagement and store them in a personal playbook.

5. Project and delivery skills

Project management skills matter more in FDE roles than in standard IC SWE roles because FDEs hold the customer accountability and the engineering execution simultaneously. There is no PM buffer between the customer's expectations and the code — the FDE is responsible for both.

Scoping and sequencing. Break the deployment into phases with working software at the end of each phase rather than a single big-bang delivery. Define the minimum useful scope of each phase — what can the customer actually use after this phase is complete, not just what engineering milestone is hit. Sequence phases to derisk early: the thing that is most likely to fail or expand scope should be discovered in Phase 1, not Phase 3.

Unblocking yourself. FDEs do not have the luxury of waiting for a sprint planning meeting to surface blockers. If you need credentials you do not have, you get them. If a dependency is late, you find a workaround or escalate immediately. If the scope is unclear, you clarify it in the same day. The discipline is time-boxing attempts before escalating: spend one hour debugging a blocker before asking for help; resolve scope ambiguity the same day or escalate to the customer sponsor. Escalation is not failure — late escalation is.

Handoff back to product. The deployment ends when the customer can operate the system without you. A handoff is not documentation dropped in a shared drive; it is a knowledge transfer that results in the customer's team being able to debug, extend, and maintain the system. Strong FDEs build for handoff from day one: clean code, named functions, operational runbooks, and a documented decision log that explains why the system is shaped the way it is. The system's long-term success is part of your track record as an FDE, even after you have moved to the next account.

6. What to actively practice this week

These drills map directly to the skills above. Each one is completable in a single focused session and produces a concrete artifact you can cite in an interview or add to a portfolio.

Drill 1 — Rapid API integration. Pick a public API you have never used (Greenhouse, Lever, Stripe, GitHub, or Twilio all work). Set a two-hour timer. Build a complete end-to-end integration: authentication, a real data fetch, processing the response into a structured format, and a simple output that proves the integration works. Stop when the timer ends. Review what you completed and what you did not. This drill directly maps to the core engineering API integration skill and the "rapid integration from a standing start" pattern that FDE interviews test for. Run it three times with different APIs before your loop.

Drill 2 — Ship a Streamlit dashboard against public data. Choose a public dataset (Bureau of Labor Statistics, FRED, Census API, or any Kaggle dataset with an API). Build a Streamlit dashboard that lets a non-technical user explore the data with at least two interactive filters. Deploy it somewhere publicly accessible (Streamlit Community Cloud is fine). The artifact should be a clickable URL you can share — not a GitHub repo with instructions. This drill tests full-stack comfort (ingestion → processing → UI) and the discipline of building something actually usable rather than technically correct.

Drill 3 — Write a one-page deployment plan. Invent a hypothetical customer: a mid-size healthcare company that wants to use an LLM to extract structured information from physician notes. Write a one-page deployment plan covering: what you would build in the POC (scope), what data you need from the customer and why, what success looks like after the POC (the eval set and the threshold), what the production deployment would require (infrastructure, security, integration points), and what the biggest risks are and how you would mitigate them. This drill maps to project/delivery skills, scoping discipline, and the POC scoping skill under customer-facing work. Read it aloud to someone who is not technical and ask if they understand what you are proposing to build and why.

Drill 4 — Mock discovery call. Ask a friend, colleague, or partner to play the role of a customer stakeholder for 30 minutes. Give them a one-sentence briefing ("You are the VP of Engineering at a logistics company that wants to use AI to process inbound vendor invoices"). Run a technical discovery call: open with a clear agenda, ask targeted questions to understand the current process and pain points, surface the data and integration constraints, identify who else you need to talk to, and close with a clear next step. Record the session and watch it back. The artifacts you are assessing: did you build an accurate mental model of their actual problem? Did you surface the constraints they did not know were constraints? Did you close with a concrete next step? This is the skill that the customer scenario round in the FDE loop is testing.

Drill 5 — Build and evaluate a RAG pipeline. Choose a corpus of documents (a public SEC filing, a Wikipedia category, a set of product documentation). Build a RAG pipeline: chunk and embed the documents, store them in a vector database (ChromaDB or Pinecone both have free tiers), build a retrieval query interface, wrap a model call around the retrieval, and produce answers with source citations. Then build a 20-question eval set — questions with known correct answers grounded in the corpus — and measure your pipeline's accuracy against it. Tune one variable (chunk size, retrieval count, or prompt format) and measure whether accuracy improves. This drill maps directly to the retrieval pipeline and evals design skills in the AI/LLM section.

7. What you don't need

You don't need a CS degree. The FDE hiring loops at every employer tracked by FDE Jobs List evaluate skills, not credentials. A portfolio of production integrations, deployed customer-facing software, and demonstrable debugging ability is more convincing than a transcript. The resume filter at most FDE employers is "did this person build things that real users depended on?" — not "did this person study computer science formally." Self-taught engineers, bootcamp graduates, and career switchers from adjacent technical fields are consistently represented in FDE cohorts.

You don't need to have shipped ML research. Peer-reviewed publications, Kaggle competition placements, and model training experience are not requirements for FDE roles and are not predictive of FDE success. What is required is the ability to use models in production — calling APIs, building pipelines, designing evaluations, debugging model behavior in a customer environment. These are different skills from ML research, and conflating them leads candidates to disqualify themselves or spend time building the wrong portfolio. An engineer who has shipped three production LLM features is better prepared for an FDE interview than an engineer with a published paper and no deployment experience.

You don't need to be a 10x algorithmic coder. FDE interviews include a coding component, but they are not testing competitive programming ability. The standard is "can this engineer write clean, working, maintainable code in a customer-relevant scenario" — not "can this engineer solve a dynamic programming puzzle in 20 minutes under pressure." FDEs who have spent time practicing LeetCode hard-level problems at the expense of building actual integrations have misallocated their preparation. The coding that FDE interviews test for is the coding that FDE work actually requires: data processing, API clients, pipeline scripts, and quick prototypes.

You don't need to be an extrovert. The customer-facing dimension of FDE work does not require a particular personality type. What it requires is the ability to show up prepared, ask good questions, hold a position when warranted, and make the customer feel like their problem is being taken seriously. Introverted engineers who do thorough discovery, write precise status updates, and say what they will do and then do it are routinely more effective FDEs than extroverted engineers who are comfortable in the room but imprecise in their commitments. Preparation is the substitute for natural ease in customer interactions, and it is entirely within anyone's control.

Related resources

• How to become a Forward Deployed Engineer — backgrounds, paths, and portfolio moves that land FDE roles
• FDE interview questions (2026) — representative loop questions with signal notes for both sides
• FDE salary guide (2026) — employer-published comp bands from live ATS data
• Top companies hiring FDEs in 2026 — ranked by live ATS listing volume, with company profiles
• Browse live FDE job listings — all active FDE openings from Lever, Greenhouse, and Ashby