What the job is
One customer, many capabilities
A product engineer owns one feature for every customer. An FDE owns one customer across every capability: discovery, scoping, system design, build, rollout, and the hand-over that lets the customer run it without you. The title comes from Palantir, which still calls its Forward Deployed Software Engineer role "the blueprint"; the phrase itself is borrowed from the military.
Software engineer
Owns the product for every customer. Done at the next release.
Solutions engineer
Owns demos and proofs of concept. Done when the deal closes.
Consultant
Owns recommendations. Done when the report is delivered.
Forward Deployed Engineer
Owns production code in the customer's systems, plus feedback to the core product. Done when the system is in use and the customer can run it.
Where 100 FDE postings go deepest
38% of the same postings are hybrids. 94% mention AI or ML, but only a third are primarily AI-application roles: AI is the environment the job runs in, not always its centre. Platform and infrastructure roles are 3%. FDE Handbook, 4 Sep 2026
Role comparison drawn from Swiftwater, Paraform and the McKinsey explainer.
"Own discovery, technical scoping, system design, build, and production rollout… measure success through production adoption, measurable workflow impact, and eval-driven feedback."
OpenAI, Forward Deployed Engineer posting, San FranciscoWho it is for
Built for engineers who already ship, and want to own the outcome
Every posting we read asks for production engineering first and customer skills second. The role is a step sideways for a working engineer, not an entry point into engineering.
✓A fit if you
- Have 3+ years building and running production software as a backend, full-stack or data engineer
- Have worked with customers or stakeholders: consulting, solutions, implementation, or as a founder or early startup engineer
- Are comfortable starting from a vague business problem and scoping a first version yourself
- Can explain a system to an engineer in the morning and to an executive in the afternoon
- Have hands-on time with LLM APIs, agents or RAG, even from side projects (Anthropic's posting says prototypes count)
- Can travel to customer sites: 25% at Palantir and Anthropic, up to 50% at OpenAI, 30–80% at DevRev depending on location
…Not yet if you
- Are a fresher: none of the India FDE postings we found are entry level. Build 2–3 years in a backend, full-stack, AI application or solutions role first
- Want to build one product deeply without customer contact
- Prefer fully specified tickets to ambiguous problems
- Have only tutorial projects or work that never left your laptop
DevRev's own split for the job: 80% customer-facing, 70–80% hands-on coding. The two overlap because most of the coding happens with the customer in the room. DevRev, Mumbai
Experience bars in current postings
| Employer | Location | Years required | Also asks for |
|---|---|---|---|
| Cursor | Bengaluru, New Delhi, Mumbai | none stated | Built and owned AI-native workflows in production; debugged real model failures |
| DevRev | Bengaluru, Delhi NCR, Mumbai, Chennai | 3+ to 5+ | Software development, systems integration or platform engineering |
| Cartesia | Bengaluru | 4+ | Building and operating production systems |
| MongoDB | Gurugram | 5+ | Backend engineering |
| Databricks | Bengaluru, remote India | 6+ | Data engineering, AI and data platforms; deep Apache Spark |
| Palantir | US, UK, Europe, Japan, Korea | 1+ | New-grad and intern tracks abroad; no India role |
| Anthropic | US, UK, Europe | 4+ | Technical customer-facing role; no India FDE role |
| OpenAI | US, Europe, Asia, UAE | 5+ (FDE), 7+ (FDSWE) | Deployed LLM-powered systems; no India FDE role |
Careers pages and postings as of late Oct 2026. OpenAI and Anthropic list Applied AI Architect roles in India instead, which are pre-sales roles with a higher experience bar.
Skills to learn
Four skill sets, tested together
Postings ask for production software engineering, systems integration, applied LLM work and customer judgment in the same person. No single tool dominates. Python and TypeScript are the languages named most often; the rest is about connecting models and products to a company's real systems.
How often 100 FDE postings name each signal
Share of 100 active FDE postings that explicitly mention the signal. FDE Handbook, 4 Sep 2026
Specific tools in ~1,000 postings
Mostly US postings, updated 25 Jan 2026. Bloomberry, via Masai. Indeed's India report lists the same families: Python or Java, data engineering, GenAI, RAG, agents, cloud, APIs, integrations, full-stack.
Software engineering fundamentals
Build the thing properly
- Data structures and algorithms; still screened in coding rounds
- One strong language, Python most often, with TypeScript/JavaScript, Java, Scala or Go as a second
- Relational databases (Postgres, MySQL), SQL, data modelling
- Full-stack delivery. Cursor's wording: "if it needs frontend, backend, infra, or prompt iteration, you'll own it"
Integration and deployment
Make it work inside someone else's systems
- REST and GraphQL APIs, webhooks, event-driven and pub/sub architectures
- Retries, idempotency, duplicate and out-of-order events, reconciliation
- Authentication and identity; enterprise constraints like networking, security reviews, compliance and procurement
- Cloud (AWS, GCP, Azure), containers and Kubernetes, serverless, CI/CD
- Observability: logging, telemetry, alerts, safe rollouts, incident response
Applied AI
Operate LLM systems, not just call them
- LLM APIs, prompt and context design, structured outputs
- RAG, function and tool calling, agents and multi-agent workflows, Model Context Protocol (MCP)
- Evals to validate agentic systems, guardrails, tracing; knowing when to fine-tune, retrieve, or just prompt
- Daily use of AI coding tools with the judgment to review and steer the output
For data-platform FDE roles (Databricks), add pipelines, Apache Spark, MLOps and two or more clouds.
Customer and delivery
Turn a vague ask into a shipped first version
- Discovery and scoping from a business problem, before any architecture
- Sequencing delivery, removing blockers, trading off scope, speed and quality
- Demos and communication with VPs and C-level as well as engineers
- Handing over systems the customer can run; writing playbooks and reusable tools from what you built
Skill groups compiled from postings by Palantir, OpenAI, Anthropic, Databricks, Cursor, DevRev, Cartesia and Scale AI.
Projects to build
One deployed system beats eight demos
Interviewers probe engineering decisions, so build something that forces real ones: integrations that fail, users who do unexpected things, a rollout that had to be measured. Match the project to the kind of FDE role you are targeting.
Integration-heavy roles · 63%
Sync two real systems
Keep records in sync between a CRM or ticketing tool and a product or data warehouse.
Must include: webhooks, authentication, retries, idempotency, duplicate and out-of-order events, reconciliation, external IDs, observability, a rollout plan.
AI-application roles · 34%
One real AI workflow with users
A support-triage agent, a document-processing workflow, an invoice or claims agent over real documents.
Must include: tool calls against real systems, retrieval, state and persistence, error handling and approval gates, traces, a golden dataset with regression evals, a catalogue of failure modes.
Platform roles · 3%
Something that forces infrastructure reasoning
A model router with fallback, a rate limiter with per-user and global limits, a queue-backed pipeline.
Must include: concurrency, caching, measured throughput and latency, failure domains, cost.
The three artefacts to walk into an interview with
- A deployed, production-style system with real integrations. Not a notebook, not localhost. Deploy it where someone else could use it.
- An eval suite for it: a golden dataset, regression tests that run on every change, drift detection, documented failure modes, and one before/after showing the evals catching a regression.
- A written case study: what the existing process was, what you changed, what you measured, what broke and how you diagnosed it. A real debugging write-up is the single strongest portfolio item.
A project that mirrors the job: find a small business, nonprofit or internal team doing something by hand (sorting requests, reviewing documents, qualifying leads). Map how the work happens today, promise one narrow improvement, ship it with logins and monitoring, measure whether people use it, and write handoff notes so someone else can run it.
From FDE Handbook, a10x, fde.academy, Zarif Automates.
What does not count
- Tutorial projects followed step by step
- Anything never deployed beyond your own machine
- Undocumented repositories with no evidence of real use
- A chatbot with one model call and no tools, state or evals
- Long technology lists with no project behind them
Hiring managers screen for depth: one strong deployed project with a written case study, not a wall of demos.
The interview loop
A software engineering loop, plus the rounds that test judgment
Most FDE loops run three to six weeks and add rounds a normal SWE process lacks: a customer case or decomposition, and a deep dive into something you shipped. The projects above are what those rounds are built to examine.
Recruiter or hiring-manager screen
Motivation and evidence of shipped systems. "Why FDE specifically, and not a regular SWE role?" "What do you think an FDE does day to day?"
Coding
Algorithms plus practical work with APIs, JSON transformation, SQL or debugging. Seen at OpenAI: alien dictionary ordering, number of islands, topological sort with cycle detection. Seen at Anthropic: a rate limiter with per-user and global limits, with follow-ups on distributed coordination.
System design around a real workflow
"Design a RAG pipeline for a customer with millions of internal documents." "Design a reliable sync between a customer's CRM and your product." "Design an ingestion layer for 12 data sources with no clean schema."
AI or technical depth
"When would you fine-tune, use RAG, or rely on prompting?" "How does chunking affect retrieval quality?" "How do you know your AI system is actually working?" "Hosted or self-hosted LLM for a regulated customer?"
Customer case, decomposition or live demo
A deliberately vague request, such as "we want to automate support with AI", that you must clarify, scope to a first version and explain with trade-offs. Palantir's decomposition round is 60 minutes with little or no code; its FDSE loop adds a learning round and a Foundry-based take-home.
Project deep dive and behavioural
"Tell me about something you built end to end." "A production incident you personally diagnosed." "A deployment that went badly." "A time you disagreed with what the customer wanted to build."
What strong answers do
- Start with users, workflows, constraints and success criteria before architecture
- Make failure handling explicit: duplicates, timeouts, partial success, a dependency down for two hours
- Separate what the model decides from what the application controls, and say what gets measured and traced
- Lead project stories with the business problem, then the technical choice, the trade-off, and the measured result
How to prepare
- Classify the target role as integration-heavy, AI-application-heavy or platform-heavy from the JD before you study
- One conventional coding problem and one practical API or data problem each week
- System design practice with authentication, retries, idempotency, queues, observability and rollout
- Two or three project stories showing ambiguity, ownership, production work, failure and measurable impact
Rounds and questions from FDE Handbook, Aced (Exponent), IGotAnOffer, Exponent on Palantir, Perspective AI.