A practical, independent learning guide
A curated learning library for Forward Deployed Engineers and Special Projects Engineers. Build the foundations, sharpen your judgment, and learn to deliver systems that keep creating value after the pilot.
Three routes through the same curated library
Build the foundation
For a software engineer new to customer delivery. Start with the gaps in your knowledge, then follow the 12-week project.
Your evidenceA working customer workflow, an evaluation report, and a handoff another person can use.
Improve a real deployment
Use the current failure or bottleneck to choose a short reading sequence. Skip the role introductions.
Your evidenceA before/after comparison with failure slices, operating cost, and a rollout decision.
Build durable capability
Study the boundaries where local success can create shared risk, maintenance cost, or organizational dependence.
Your evidenceA reusable delivery package, explicit ownership, and a measured reduction in second-deployment effort.
Already delivering in the field? Go straight to advanced fieldcraft for permission consistency, uncertain writes, evaluation failures, economics, and reuse. Use the library filters for books, podcasts, talks, or advanced material. Reading and case reviews save locally alongside your roadmap progress.
What does the work feel like? Read 8 firsthand FDE stories about career changes, daily delivery, team building, and moving on from the role. Each explains the context, tradeoff, and limits of the account.
THE DELIVERY LOOP / 01
Start with a person, a recurring task, and an observable problem. Watch how work happens today.
Example: a support team asks for a chatbot. First establish which customer tasks fail and why.
The loop and role comparison are editorial learning models. Titles vary by company; SPE means Special Projects Engineer here. Neither role is a universal seniority level.
01 / FDE
Work close to customers across discovery, integration, production delivery, and adoption. Feed repeated problems back into the product.
02 / SPE
The Cognition example illustrates broad problem ownership, including internal infrastructure and new product opportunities. Use it as one concrete model.
03 / SHARED CRAFT
Engineering, domain learning, communication, and maintenance all matter. A useful system needs users, evidence, and someone who can run it after you leave.
A pilot gets excellent demo feedback. Which evidence would best support expanding it?
Use this guide: follow the roadmap, discuss one case each week, and answer interview questions before opening the response guide. Completion records effort; your project evidence shows capability.
FIELD GUIDE / 04
For engineers who can already build a small application. Plan for 5–8 focused hours per week, plus user access. Stretch the schedule if software or data foundations are new to you. This is a suggested sequence, not a credential.
The FDE Academy method article describes parallel technical and consulting tracks, repeated application, and a reviewed portfolio. Use that lens each week: pair a technical artifact with evidence of a customer decision.
Commercial provider self-description. Program effectiveness and certification claims are not independently assessed. This guide is unaffiliated with FDE Academy / Futurense.
Plank’s about page describes a training-and-embedded-team model; it is provider context only. Its specific Day 37 lesson adds an observed runbook test and a record of usability findings. The published example uses simulated participants.
Use a real peer for your handoff review; simulated users do not establish customer usability.
Vinoo Ganesh’s Next Play essay contributes a personal transition and rotation-program story. It belongs in Stories, where its lessons and limits are annotated, rather than another mandatory role introduction.
Editorial suggestion: record one assumption that field evidence changed, then have a reviewer challenge the resulting design decision.
Define the customer, the workflow, and your decision rights.
Go deeper when needed
Evidence to move onA charter with one outcome, one owner, and an explicit out-of-scope list.
Observe a recurring workflow before proposing a solution.
Go deeper when needed
Evidence to move onA workflow map and evidence of repeated pain; avoid hypothetical willingness-to-use claims.
Choose the smallest valuable change you can evaluate.
Go deeper when needed
Evidence to move onA scoped proposal with a baseline, an acceptance test, and a stop condition.
Turn permissions, schemas, and dirty records into explicit constraints.
Go deeper when needed
Evidence to move onA reproducible data sample and an integration contract another engineer can understand.
Deliver one complete user action through the system.
Go deeper when needed
Evidence to move onA working path from input to outcome, with assumptions and limitations written down.
Make failures visible and reproducible.
Go deeper when needed
Evidence to move onA versioned evaluation report with failure categories and release criteria.
Handle partial failure and make operations understandable.
Go deeper when needed
Evidence to move onA runbook demonstrating how to detect, contain, and recover from failure.
Put the system into a real workflow with a named owner.
Go deeper when needed
Evidence to move onA pilot review with usage, failures, user feedback, and an explicit go/no-go decision.
Connect usage to outcomes and account for ongoing work.
Go deeper when needed
Evidence to move onAn impact memo with denominators, a comparison period, and uncertainty.
Convert corrections into durable improvements.
Go deeper when needed
Evidence to move onA traceable chain from user feedback to a tested change.
Make the next deployment cheaper to deliver and maintain.
Go deeper when needed
Evidence to move onA maintainable package, an accountable owner, and a measured second-deployment cost.
Show judgment, evidence, and an honest account of limits.
Go deeper when needed
Evidence to move onA portfolio case study, demo, evaluation report, and candid retrospective.
FIELD GUIDE / 08
Practitioners, team builders, and adjacent experts. Company affiliations describe the linked publication, not a live employment directory. A blank talk or article means no suitable item was verified for this edition.
X identity check: Nabeel Qureshi’s indexed profile matched his name and personal domain. Other listed handles remain explicitly unverified; X blocked direct inspection. No handle is guessed for people without a reliable candidate. Articles and talks are the learning sources, not profile pages.
No matches. Try another search or clear the filter.
| Company / context | Person & learning value | X handle | Talk / podcast | Article / book |
|---|---|---|---|---|
| Cognition | Nick Wong SPE practitioner Unowned problems → useful infrastructure → product opportunities. | Not verified — no link supplied | No verified talk in this edition | Nick Wong, Special Projects Engineer |
| Cognition | Jia Wu FDE practitioner / speaker Customer outcomes, engineering adoption, and product feedback. | Not verified — no link supplied | How Forward Deployed Engineering is Done at Cognition | See the linked talk |
| Ramp (at publication) | Leo Mehr FDE team builder How to scope work and decide when to generalize. | @LeoMehr ↗ Unverified handle | How Forward Deployed Engineering is done at Ramp | Forward Deployed Engineering |
| Palantir (former) | Nabeel S. Qureshi Former FDE Field context, enterprise data, and product development. | @nabeelqu ↗ Identity corroborated | No verified talk in this edition | Reflections on Palantir |
| OpenAI | Colin Jarvis FDE leader / author Turn delivery experience into reusable capabilities. | Not verified — no link supplied | No verified talk in this edition | What FDE means at OpenAI |
| Sierra | Natalie Meurer Agent engineering practitioner Domain expertise and production agent delivery. | @natalie_meurer ↗ Unverified handle | No verified talk in this edition | Meet the AI agent engineer |
| DeepLearning.AI | Andrew Ng Educator / industry perspective Where customer-embedded engineering fits in applied AI. | @AndrewYNg ↗ Unverified handle | No verified talk in this edition | The Batch, Issue 355 — opening letter on AI FDEs |
| Latent Space / AI Engineer | swyx Educator / community builder Broader AI engineering concepts and communities. | @swyx ↗ Unverified handle | No verified talk in this edition | The Rise of the AI Engineer |
| Y Combinator (at publication) | Eric Migicovsky Founder / educator Discover real user problems through concrete past behavior. | Not verified — no link supplied | How to Talk to Users | See the linked talk |
| Morgan Stanley (at publication) | Jeff McMillan AI business leader Enterprise adoption and the role of evaluation. | Not verified — no link supplied | No verified talk in this edition | Morgan Stanley uses AI evals to shape the future of financial services |
| Morgan Stanley (at publication) | David Wu AI architecture leader Retrieval quality and expert review at enterprise scale. | Not verified — no link supplied | No verified talk in this edition | Morgan Stanley uses AI evals to shape the future of financial services |
| Sierra | Vijay Iyengar Engineering author A published interview format that tests building and judgment. | Not verified — no link supplied | No verified talk in this edition | The AI-native interview |
| AWS (at publication) | Marc Brooker Systems engineering author Reliable integrations under partial failure. | Not verified — no link supplied | No verified talk in this edition | Timeouts, retries, and backoff with jitter |
| Independent / AI evaluation | Hamel Husain Practitioner / educator Error analysis and trustworthy automated judges. | Not verified — no link supplied | No verified talk in this edition | AI Evals: Everything You Need to Know |
| UC Berkeley (at episode publication) | Shreya Shankar Researcher / educator Data validation, reproducibility, and evaluation. | Not verified — no link supplied | Grounded Research: From Google Brain to MLOps to LLMOps | AI Evals: Everything You Need to Know |
| Independent author | Chip Huyen AI engineering author Choose adaptation and serving approaches from measured constraints. | Not verified — no link supplied | No verified talk in this edition | AI Engineering |
| Honeycomb (at episode publication) | Charity Majors Operations practitioner Connect production behavior to useful telemetry. | Not verified — no link supplied | Observability for AI with Charity Majors | See the linked talk |
| HumanLayer | Dex Horthy Agent engineering author Control workflow state and understand framework tradeoffs. | Not verified — no link supplied | 12-Factor Agents · AI Engineer talk | 12-Factor Agents · Unify execution state and business state |
| Independent author | Will Larson Technical leadership author Choose consequential work across organizational boundaries. | Not verified — no link supplied | No verified talk in this edition | Work on what matters |
FIELD GUIDE / 07
Answer aloud, explain assumptions, then open the response guide. Use the notes to record your reasoning and the evidence you missed. The guides and follow-up questions are editorial suggestions, not official answer keys.
What is real? Q01–Q06 paraphrase first-person candidate reports. Q07–Q08 summarize an employer-published format. Q09–Q15 are original questions derived from documented cases or architecture; Q16 applies an operations framework to a hypothetical scenario. These latter questions are not reported employer questions.
Reports are uncorroborated and process details vary. The two Palantir posts provide limited, concentrated evidence; there is no verified public SPE question bank here. Ask your recruiter about the current format and AI-tool rules.
No matches. Try another search or clear the filter.
Q01 / Decomposition
Design an application that lets users share their interests.
The candidate reports this specific design prompt. Wording is paraphrased; no official confirmation.
Source: Palantir FDSE Interview Experience (REJECTION~)
Clarify who shares with whom, visibility, matching behavior, and success. Model users, interests, and interactions. Walk through one user journey before discussing scale.
Mock follow-up: What changes if interest visibility is private by default? How would you test matching quality?
Q02 / Coding
Implement search(user_id, users) for the interest-sharing application.
The function name is reported, but the full schema and requirements are not public. Agree on them with your mock interviewer first.
Source: Palantir FDSE Interview Experience (REJECTION~)
Ask what results mean, whether order matters, and how prior interactions affect eligibility. Start with a correct implementation; test empty data, duplicates, missing users, and ties.
Mock follow-up: Explain the time and space costs. Which lookup would you index, and why?
Q03 / Coding
How would you make meeting-history lookups faster?
Reported as a follow-up to the same interview; the original data model is incomplete.
Source: Palantir FDSE Interview Experience (REJECTION~)
Identify the lookup key and read/write pattern. Compare a scan with a keyed index, explain memory and update costs, and preserve the original matching semantics.
Mock follow-up: How do cancellations, duplicate records, or stale indexes affect correctness?
Q04 / Coding
How would you speed up searching interests if the data must remain an array?
Reported follow-up; the post suggests sorting and binary search. The correct design depends on the requested matching semantics.
Source: Palantir FDSE Interview Experience (REJECTION~)
Clarify exact, prefix, or substring matching. Consider sorted ranges for compatible queries; account for sorting and mutation costs. Explain why prefix indexing does not solve arbitrary substring search.
Mock follow-up: When is a simple scan better than maintaining sorted order?
Q05 / Motivation
Why this company, why the government domain, and why the FDSE role?
The author reports repeated motivation questions in one government-track process. This is not a universal interview sequence.
Source: Palantir FDSE Full Interview Loop Process
Connect a specific mission or workflow to your past work. Describe the role accurately and discuss genuine fit, including work you would decline.
Mock follow-up: What would you need to learn about the customer before accepting the role?
Q06 / Ownership
Walk through your internship project in detail. What did you enjoy most and least?
A paraphrase of the reported hiring-manager project discussion.
Source: Palantir FDSE Full Interview Loop Process
Distinguish your contribution from the team’s. Explain a decision, an obstacle, a result, and what you would change. Be precise about whether outcomes were measured.
Mock follow-up: What evidence changed your mind during the project?
Q07 / Product & build
Define a product in a domain you know, build it using your chosen AI tools, then demonstrate and defend it.
Sierra describes a plan/build/review onsite with a two-hour build. This is a published format, not a fixed question; the current recruiting process may differ.
Source: The AI-native interview
Choose a narrow user problem, show the main flow, explain scope cuts, inspect generated code, and describe what must change before production.
Mock follow-up: Which model-generated change did you reject, and what evidence led you there?
Q08 / Debugging
Review and improve a draft change that introduces a cross-cutting feature in an existing codebase.
Sierra describes this as a debugging-interview pilot, not a confirmed universal stage. No original codebase is provided.
Source: The AI-native interview
Reproduce the behavior, trace affected boundaries, find the smallest responsible fix, and check regressions. Explain both the code change and its user impact.
Mock follow-up: What would you inspect before trusting an AI-generated patch?
Q09 / Scope & customers
A customer asks for a feature that will take three days. How do you decide whether to build it?
An original interview-style question derived from a published delivery example; not reported as an actual hiring question.
Source: Forward Deployed Engineering
Ask about the underlying blocker, deadline, existing alternatives, and acceptance criteria. Compare a workaround with a reusable feature and include maintenance cost.
Mock follow-up: When would a workaround create unacceptable long-term risk?
Q10 / SPE ownership
Employees are rapidly building internal apps, but no team owns a safe deployment environment. What do you do first?
An original question based on Nick Wong’s published account; not a reported Cognition interview question.
Source: Nick Wong, Special Projects Engineer
Identify the workflows, sensitive data, users, and ownership gap. Build a paved path with clear permissions, maintenance ownership, and a narrow first use case.
Mock follow-up: What evidence would justify turning the internal capability into a customer product?
Q11 / Evaluation
Experts keep correcting your AI output. How would you turn those corrections into a reliable improvement process?
An original question derived from the published Tax AI engineering case.
Source: Building self-improving tax agents with Codex
Capture context and traces, distinguish genuine errors from policy changes, create representative held-out cases, and test fixes against regressions before rollout.
Mock follow-up: How do you keep the improvement loop from overfitting to the latest corrections?
Q12 / Adoption & value
Your support agent resolves chats quickly, but customers still struggle to use the product. What should you measure next?
An original question grounded in the published time-to-music and customer-effort discussion.
Source: How Sonos elevates the listener experience with Sierra
Follow the full customer journey. Examine repeat contacts, actual task completion, cohort differences, and time to first value. Validate the data with users.
Mock follow-up: How would you distinguish genuine resolution from a customer giving up?
Q13 / Security & data
A user loses access to a folder, then new content is added. How do you stop stale permission checks from exposing it?
An original design question based on the paper’s new-enemy problem; not a reported hiring question.
Source: Zanzibar: Google’s Consistent, Global Authorization System
Model content and ACL versions, inherited permissions, and read consistency. Include caches and exports. State the revocation guarantee and test forbidden reads after changes.
Mock follow-up: Where is an authorization check too stale to be acceptable?
Q14 / Migration
Move live customer subscriptions into a new data model without losing updates. How do you stage and reverse the change?
An original question derived from the published online migration; not a Stripe interview report.
Source: Online migrations at scale
Separate write duplication, backfill, validation, read cutover, and retirement. Inspect concurrent updates, parity failures, load, and the conditions under which rollback remains possible.
Mock follow-up: A backfill races with a newer write. Which version wins and how would you detect a regression?
Q15 / Incident judgment
Failover has produced writes in two locations and increased application latency. What do you protect first?
An original incident discussion based on the 2018 postmortem; not a GitHub interview report.
Source: October 21 post-incident analysis
State the data-integrity invariant, freeze unrelated changes, inspect replication, and choose a containment path. Explain the consequences of degraded service versus unsafe failback.
Mock follow-up: Which queued jobs can be replayed safely, and which require reconciliation?
Q16 / Unit economics
The model bill falls, but review and support increase. How do you decide whether the deployment improved?
An original synthesis applying the published toil framework to FDE delivery; the scenario is hypothetical.
Source: Eliminating Toil · The Site Reliability Workbook
Use total cost per accepted task, include failures and human work, and hold task mix and quality constant. Separate realized savings from theoretical capacity.
Mock follow-up: What changes if usage doubles but the support team cannot grow?
FIELD GUIDE / 05
17 cases across customer delivery and adjacent production engineering. The newer architecture, migration, and incident cases show implementation decisions and failure mechanisms. Each links to a specific publication; discussion questions are original teaching prompts.
No matches. Try another search or clear the filter.
C01 / SPE
ProblemInternal app creation outpaced clear ownership of a protected deployment environment.
ApproachNick Wong describes building a shared environment, then exploring security products.
Reported resultA public account connects the internal project to Devin for Security; no quantified business effect is supplied.
Evidence limitA company-hosted personal account, not an independent evaluation.
Which ownership gap matters enough to justify a shared capability?
Identify the user, baseline, intervention, measurement window, ongoing cost, and evidence you would need before repeating the claim.
C02 / Discovery
ProblemA requested feature appeared to require roughly three engineering days.
ApproachThe team spoke directly with the customer and found a workaround during the call.
Reported resultThe article reports avoiding the implementation.
Evidence limitOne anecdote; it does not quantify sustained adoption or maintenance cost.
What did the customer need to accomplish, and which requirement was negotiable?
Identify the user, baseline, intervention, measurement window, ongoing cost, and evidence you would need before repeating the claim.
C03 / Delivery
ProblemManufacturing work depended on fragmented information.
ApproachQureshi describes connecting work orders, parts, quality issues, and schedules in one workflow.
Reported resultHe reports the work contributed to a fourfold manufacturing ramp-up.
Evidence limitA former practitioner’s retrospective. The software’s isolated causal contribution is not established.
How would you validate that a workflow improvement reduces a production bottleneck?
Identify the user, baseline, intervention, measurement window, ongoing cost, and evidence you would need before repeating the claim.
C04 / Delivery
ProblemVerification workflows needed useful AI under real engineering constraints.
ApproachFDEs learned the domain, built evaluations, and later consolidated custom implementations.
Reported resultOpenAI reports about 48% time savings for directed test generation and roughly 90% less custom code.
Evidence limitAn unnamed customer; independent methodology and cost accounting are not public.
Which domain-specific evaluation would block an unsafe launch?
Identify the user, baseline, intervention, measurement window, ongoing cost, and evidence you would need before repeating the claim.
C05 / Evaluation
ProblemVoice support exposed gaps in function calling and instruction following.
ApproachFDEs and researchers iterated against customer-defined evaluations.
Reported resultOpenAI reports key evaluation scores rising from about 60% to over 90% in six months.
Evidence limitThe evaluation set is not public; this is not an overall customer-satisfaction measure.
When should you reduce scope, involve research, or stop the deployment?
Identify the user, baseline, intervention, measurement window, ongoing cost, and evidence you would need before repeating the claim.
C06 / Evaluation
ProblemPractitioner corrections were difficult to convert into durable system improvements.
ApproachCapture corrections with production traces and turn failure patterns into evaluation targets.
Reported resultThe article reports 7,000 pilot returns and about 50% higher throughput, with practitioner review.
Evidence limitProvider-reported pilot results; field-completion accuracy is not the same as error-free returns.
How would you preserve expert review while reducing total handling time?
Identify the user, baseline, intervention, measurement window, ongoing cost, and evidence you would need before repeating the claim.
C07 / Adoption
ProblemAdvisors needed dependable access to a large internal knowledge base.
ApproachExpert-scored evaluations guided retrieval and response improvements.
Reported resultThe source reports active use by more than 98% of advisor teams.
Evidence limitTeam-level adoption does not establish individual usage intensity or financial impact.
What usage denominator and quality thresholds would make adoption meaningful?
Identify the user, baseline, intervention, measurement window, ongoing cost, and evidence you would need before repeating the claim.
Morgan Stanley uses AI evals to shape the future of financial services
C08 / Delivery
ProblemTurning client conversations into usable notes and follow-ups required manual effort.
ApproachMeeting summaries enter the advisor workflow with consent and human review.
Reported resultThe case describes CRM-integrated notes and draft follow-ups.
Evidence limitA qualitative deployment account; no isolated ROI estimate is provided.
How do you evaluate omissions, incorrect action items, and review workload?
Identify the user, baseline, intervention, measurement window, ongoing cost, and evidence you would need before repeating the claim.
Morgan Stanley uses AI evals to shape the future of financial services
C09 / Adoption
ProblemLarge development teams wanted shorter feature-delivery cycles.
ApproachTeams adopted coding agents for development and refactoring work.
Reported resultThe customer story reports feature time-to-market moving from 24 to 5 days.
Evidence limitVendor-hosted results; scope and counterfactual are limited. Do not generalize this improvement to every task.
How would you compare similar work and account for review time?
Identify the user, baseline, intervention, measurement window, ongoing cost, and evidence you would need before repeating the claim.
C10 / Discovery
ProblemFast support interactions did not fully represent the customer’s goal: hearing music.
ApproachThe case connects AI support to time-to-music and broader customer-effort signals.
Reported resultA documented operating approach; no universal improvement percentage is claimed here.
Evidence limitA customer story, with limited controlled measurement evidence.
What is the end-to-end customer outcome beyond containment rate?
Identify the user, baseline, intervention, measurement window, ongoing cost, and evidence you would need before repeating the claim.
C11 / Adoption
ProblemCustomer care needed domain-specific language and policy-aware assistance.
ApproachThe team integrated business knowledge and systems, then started with a small set of use cases.
Reported resultThe source displays approximately 70% resolution and a 4.6 CSAT.
Evidence limitPublisher-reported measures; the visible headline does not establish sampling, scale, or causal lift.
Which cases should always escalate, and how will you detect silent failures?
Identify the user, baseline, intervention, measurement window, ongoing cost, and evidence you would need before repeating the claim.
How WeightWatchers embraces AI to engage members with empathy, at scale
C12 / Delivery
ProblemA large monolith migration would consume substantial engineering capacity.
ApproachCognition describes applying Devin to the migration.
Reported resultThe article claims years-to-weeks delivery and more than 20× lower cost.
Evidence limitAn announcement with sparse methodology; no independent cost model or complete scope is disclosed.
What would you request before using that claim in a business case?
Identify the user, baseline, intervention, measurement window, ongoing cost, and evidence you would need before repeating the claim.
Building the Future of Software Engineering in Latin America
C13 / Adoption
ProblemA bank needed to modernize and maintain a broad software estate.
ApproachThe announcement describes repository documentation, migration, and vulnerability work.
Reported resultCognition reports use by over 75% of technology teams and a 20–30% throughput increase.
Evidence limitVendor-reported adoption and throughput are different measures; neither proves causation alone.
How would you define accepted output and prevent quality from falling?
Identify the user, baseline, intervention, measurement window, ongoing cost, and evidence you would need before repeating the claim.
Building the Future of Software Engineering in Latin America
C14 / Architecture
ProblemBroad research tasks needed effective parallel exploration and synthesis.
ApproachThe engineering team describes an orchestrator with specialist subagents, evaluation, and reliability work.
Reported resultA published production-system account with architecture and evaluation lessons.
Evidence limitAn internal product-engineering case, included as adjacent learning rather than evidence of an FDE engagement.
When does parallel work justify coordination cost and extra token usage?
Identify the user, baseline, intervention, measurement window, ongoing cost, and evidence you would need before repeating the claim.
C15 / Integration
ProblemSubscriptions outgrew their original customer-record representation.
ApproachStage duplicate writes and backfill, validate the new representation, switch reads, then retire the old path.
Reported resultThe engineering account describes a staged live migration and verification strategy.
Evidence limitAn adjacent software-engineering case, not an identified FDE engagement. The 2017 stack is historical.
What must be true at every phase before you can advance or roll back?
Identify the user, baseline, intervention, measurement window, ongoing cost, and evidence you would need before repeating the claim.
C16 / Reliability
ProblemA short network partition triggered database failover into a topology the application could not tolerate.
ApproachThe team preserved writes, degraded parts of the service, restored replication, and recovered queued work.
Reported resultGitHub reports 24 hours and 11 minutes of degradation after a 43-second connectivity loss.
Evidence limitA company postmortem from 2018; included for recovery judgment, not as an FDE project or a current architecture description.
Which application assumptions should a disaster-recovery exercise test beyond database health?
Identify the user, baseline, intervention, measurement window, ongoing cost, and evidence you would need before repeating the claim.
C17 / Security
ProblemA stale access decision can expose newly changed content after a user’s permission is removed.
ApproachZanzibar couples authorization reads to causal ordering and content-version consistency tokens.
Reported resultThe paper describes a deployed authorization system and its production properties.
Evidence limitA research paper about Google’s infrastructure, not an FDE customer engagement. Its scale is not a requirement for applying the invariant.
How would the same invariant appear in an enterprise search cache or a generated summary?
Identify the user, baseline, intervention, measurement window, ongoing cost, and evidence you would need before repeating the claim.
FIELD GUIDE / 06
8 firsthand accounts of becoming an FDE, doing the work, building teams, and choosing what comes next. Read for the change in judgment and the tradeoff, then follow the linked learning material for technical depth.
No matches. Try another search or clear the filter.
S01 / Career transitions
Vinoo Ganesh · Palantir · retrospective
Product engineering ↔ customer deployments → Frontline rotations
Personal retrospectiveWhat happenedGanesh describes an empty date field triggering runaway Cassandra keyspace creation in a customer deployment. Alternating between product work and the field changed the failures he anticipated. He later helped build Frontline, a program that put product engineers into customer deployments.
The tradeoffHe describes both overengineering a one-off cleanup and underengineering a script that stayed in use. Urgency alone did not reveal the right lifespan for a solution.
Read the original: The Definitive Guide to Forward Deployed Engineering
2026-02-05
Firsthand recollection. The essay’s forecasts and program impact claims are not independently validated here.
Focus: Read “My Transformation” and “Building Frontline,” then compare the two scoping mistakes.
Editorial reflection: What assumption would you test on site before building? Who decides whether a temporary fix is retired or becomes a supported capability?
Related learning
Source content checked 2026-10-31. Personal claims are attributed, not independently verified.
S02 / Career transitions
Chinemerem E. · Palantir · joined from Nigerian fintech
Fintech backend engineer → Forward Deployed Software Engineer
Employer-hosted essayWhat happenedAfter building APIs and payment infrastructure, Chinemerem joined Palantir in 2020. Initially, using an existing platform felt less like engineering than writing the tooling. The role expanded to discovering the problem, scoping it, delivering a solution, and enabling the customer’s IT team.
The tradeoffAn identity built around writing code had to accommodate work that made existing capabilities useful. The account connects data work to operational action.
Read the original: Who Wants to be a Delta?
2021-10-21
Recruiting context and a Foundry-specific experience from 2020–21. Reuse is a judgment call, not a rule against building.
Focus: Read the sections on becoming a Delta, redefining engineering, and taking ownership.
Editorial reflection: Which part of your last delivery needed new code, and which needed a better workflow, clearer ownership, or customer enablement?
Related learning
Source content checked 2026-10-31. Personal claims are attributed, not independently verified.
S03 / Career transitions
Het Trivedi · Baseten
Startup founder → AI projects and writing → inference FDE
Employer-hosted essayWhat happenedAfter a startup failed to find product–market fit, Trivedi built AI projects and wrote about them. A post using Baseten’s Truss reached a cofounder and led toward the role. His early work involved customer requirements, inference benchmarks, production hardening, and support handoff.
The tradeoffSeveral technically demanding projects competed for attention. Losing a customer also carried an emotional cost after investing in the deployment.
Read the original: What I learned as a forward deployed engineer working at an AI startup
2024-05-31 · updated 2025-05-17
One early-career account hosted by the employer. A visible project can show ability; it does not guarantee an offer.
Focus: Follow the path into the job and the sections on customer work and challenges.
Editorial reflection: What public artifact would demonstrate your engineering reasoning and understanding of a customer constraint, beyond showing a polished demo?
Related learning
Source content checked 2026-10-31. Personal claims are attributed, not independently verified.
S04 / Career transitions
Hiro Hayami · AI Shift · Japan
Systems integrator / project lead → first two months as an FDE
Translated personal essayWhat happenedHayami moved from years of structured systems delivery into AI Shift. Showing working agents surfaced requirements earlier than completing specifications. Integration setup, demos, and feedback became central to the work; colleagues helped challenge the expectation of working alone.
The tradeoffUnstable model behavior challenged habits built around fixed specifications. At publication, the project was released for customer verification; sustained operational use was still ahead.
Read the original: Hiro Hayami: the first two months at AI Shift · English translation
2026-07-08
Japanese original, platform AI translation; names and nuance may differ. Prompt instructions described in the story are not a guarantee of tool ordering or safety.
Focus: Read the background, development, and team-collaboration sections in the English view.
Editorial reflection: Where would a prototype clarify uncertainty? Which action still needs deterministic checks and human approval before it can run?
Related learning
Source content checked 2026-10-31. Personal claims are attributed, not independently verified.
S05 / Life in the field
Milos Mandic · Lleverage · AI startup
Experienced software engineer → parallel customer deployments
First-person work diaryWhat happenedMandic follows a week of simultaneous deployments: an insurance document pipeline needed better edge-case coverage, a shared infrastructure outage interrupted plans, and communication scattered across customer tools. Repeated onboarding explanations became a playbook; recurring implementation needs fed product discussions.
The tradeoffProtected building time competed with support, presales, and status calls. His reported workload is one startup arrangement, not a universal FDE schedule.
Read the original: What FDEs Actually Do All Week
2025-12-09
Self-reported diary. Customer examples and time allocation were not independently audited.
Focus: Read the active builds, outage, communication, and Friday product-feedback sections.
Editorial reflection: Which interruptions need an immediate response, which can be batched, and which recurring requests should change the product or onboarding process?
Related learning
Source content checked 2026-10-31. Personal claims are attributed, not independently verified.
S06 / Life in the field
Henry Chang · Palantir · new graduate
UCLA graduate → first year as a Forward Deployed Software Engineer
Short public postWhat happenedChang describes work spanning utilities, construction, manufacturing, and historical documents, alongside product-team collaboration. He credits peers and a technical lead, and explicitly says that some projects had not reached production.
The tradeoffA broad project portfolio can contain both deployed services and unfinished experiments. A learning story needs to preserve that distinction.
Read the original: Henry Chang: reflections after a first year as a new-grad FDE
Exact date not exposed · edited public post
Personal recruiting post; exact publication date is not exposed. LinkedIn may require sign-in. Scale and impact claims are not independently verified.
Focus: A brief first-year reflection, useful for project variety and mentorship rather than architecture detail.
Editorial reflection: For each project on your résumé, can you separate your contribution, deployment status, and evidence of use or business impact?
Related learning
Source content checked 2026-10-31. Personal claims are attributed, not independently verified.
S07 / Building FDE teams
Vlad Shulman · Baseten
Founder and technical leader → leading an FDE function
Team leader’s accountWhat happenedShulman describes early engineers becoming Baseten’s first FDEs. Keeping the function in engineering preserved product contributions while adding coordination overhead. Hiring broadened after the team learned that strong software engineers could acquire the required ML knowledge.
The tradeoffA customer workaround can satisfy an immediate need while never reaching the product. Organizational placement alone does not close that loop.
Read the original: Forward deployed engineering on the frontier of AI
2025-06-10 · updated 2025-06-11
One leader’s account. Its preferred reporting line and product-integration target are contextual choices, not universal staffing rules.
Focus: Skip the role introduction; read establishing the function, hiring lessons, and the product-feedback loop.
Editorial reflection: Which recurring field problem has a product owner, adoption criterion, and maintenance budget? What customer work should another function handle?
Related learning
Source content checked 2026-10-31. Personal claims are attributed, not independently verified.
S08 / After FDE
Dongying Zhou · ActionIQ · 2021 role boundaries
Forward Deployed Engineer → product Software Engineer
Employer-hosted essayWhat happenedZhou moved internally from field engineering to the Execute team in July 2021. Broad platform knowledge had been valuable, but customer-specific configuration did not satisfy the desire to understand the codebase more deeply. The transition brought difficult learning in implementation, debugging, and testing.
The tradeoffField experience contributed a user perspective; deeper engineering work exposed system internals that had been hard to see from the field.
Read the original: Transitioning from Field to Engineering
2021-12-05
ActionIQ’s 2021 organization is not a definition of FDE everywhere. This is an individual internal transfer, not a promised career path.
Focus: Read “Making the Move” and “Bringing from and back to Field.”
Editorial reflection: Does your next role offer the depth, customer exposure, mentorship, and ownership you want? Ask about actual work rather than relying on the title.
Related learning
Source content checked 2026-10-31. Personal claims are attributed, not independently verified.
FIELD GUIDE / 02
37 selected resources across ten skill areas. Each has a distinct learning purpose, a reading pointer, an application, and a boundary. Cases, stories, and interview reports have their own sections; source citations are collected below.
Read selectively. Foundation = starting concepts; Practitioner = delivery skills; Advanced = tradeoffs across systems or teams. These are editorial reading levels, not job titles. Books are optional paid references; the free path remains usable. Media alternatives are grouped with the same learning objective instead of counted twice.
No matches. Use “All resources” to clear every filter.
FOUNDATIONS
Reason about data, protocols, and failure before choosing a framework.
Understand the actual boundary between a client, proxy, and server.
Content checked · Reviewed 2026-10-31
Diagnose slow customer queries with evidence instead of adding indexes blindly.
Content checked · Reviewed 2026-10-31
Build a vocabulary for correctness and performance tradeoffs across data systems.
Publisher description and contents checked; full paid text not reviewed · Reviewed 2026-10-31
Design message flows across systems with different schemas and failure semantics.
Publisher description and contents checked; selected author excerpts checked · Reviewed 2026-10-31
Expose ambiguity in the word consistency before it becomes an integration bug.
Publisher transcript sections checked; audio not played · Reviewed 2026-10-31
DISCOVERY
Find the workflow worth changing and agree on a bounded intervention.
Prepare conversations that uncover behavior and existing workarounds.
Video title checked; playback unverified · Reviewed 2026-10-30
Reduce leading questions and false enthusiasm during discovery.
Dedicated book page checked; full paid text not reviewed · Reviewed 2026-10-31
Learn when a customer request warrants a product change and when a smaller intervention works.
Indexed content checked · Reviewed 2026-10-30
Make expertise usable when the sponsor, operator, and engineer want different things.
Indexed publisher description checked; direct access blocked; full paid text not reviewed · Reviewed 2026-10-31
MINDSET
Choose consequential work, learn the domain, and influence without owning every team.
Study how direct exposure to messy enterprise work changes engineering judgment.
Content checked · Reviewed 2026-10-30
Move from solving visible tasks to choosing consequential work across team boundaries.
Author book page and linked free guide checked; full paid text not reviewed · Reviewed 2026-10-31
RETRIEVAL
Diagnose missing evidence, lost meaning, and overloaded context.
Distinguish missing chunk context from a weak embedding model.
Content checked · Reviewed 2026-10-31
Treat context selection as part of system design rather than an ever-longer prompt.
Content checked · Reviewed 2026-10-31
AGENTS
Control actions, state, and recovery in systems that use models.
Use one broad reference to connect evaluation, RAG, adaptation, and inference economics.
Publisher description and contents checked; full paid text not reviewed · Reviewed 2026-10-31
Choose the smallest amount of model-directed control the workflow needs.
Content checked · Reviewed 2026-10-30
Measure whether tool design helps the model choose and execute useful actions.
Content checked · Reviewed 2026-10-31
Reason about workflow state and recovery without adopting an opaque orchestration stack.
GitHub chapter and project README checked · Reviewed 2026-10-31
EVALUATION
Find failures, validate graders, and make release decisions defensible.
Discover failure types before selecting automated metrics.
Content and selected detailed answers checked · Reviewed 2026-10-31
Evaluate an agent’s resulting state and repeated reliability, not just plausible final text.
Content checked · Reviewed 2026-10-30
Connect ML data discipline to current AI application delivery.
Publisher transcript sections and timestamps checked; audio not played · Reviewed 2026-10-31
SECURITY
Preserve permissions across data, tools, caches, and changing access.
Separate who a user is from what that user may read or change.
Content checked · Reviewed 2026-10-31
Understand how stale authorization can expose new content after access is removed.
Paper and authorization-consistency section checked · Reviewed 2026-10-31
Inspect the authorization boundary when an agent connects through an MCP proxy.
Content checked; draft is not a pinned stable specification · Reviewed 2026-10-31
Limit what injected instructions can cause a system to do.
Content and defense limitations checked · Reviewed 2026-10-31
PRODUCTION
Operate under latency, reliability, capacity, and recovery constraints.
Prevent well-intended retries from multiplying an outage.
Content checked · Reviewed 2026-10-30
Give repeated requests a defined effect when a response is lost.
Content checked · Reviewed 2026-10-30
Make a reliability target drive an actual decision.
Content checked · Reviewed 2026-10-31
Distinguish a small deployment from a useful release experiment.
Content checked · Reviewed 2026-10-31
Find a safe operating range under the workload users will actually produce.
GitHub README checked; software not executed · Reviewed 2026-10-31
Design telemetry that can explain an unexpected customer failure.
Publisher notes and timestamps checked; audio not played · Reviewed 2026-10-31
VALUE
Connect use to a customer outcome and a credible comparison.
Challenge apparent impact with experiment design and data-quality checks.
Author page and paper checked · Reviewed 2026-10-31
Treat operator capability as part of the deployment deliverable.
Indexed content checked · Reviewed 2026-10-30
SCALE
Turn field learning into maintained capabilities and sustainable delivery.
Read the product feedback and consolidation lessons after the role overview.
Content checked · Reviewed 2026-10-30
Design a handoff that respects team capacity and cognitive load.
Author book page checked; full paid text not reviewed · Reviewed 2026-10-31
Count the work a successful deployment creates for its maintainers.
Content checked · Reviewed 2026-10-31
Inspect what a repeatable deployment package includes beyond agent code.
GitHub README checked; software not executed · Reviewed 2026-10-31
Treat the handoff as a usability study: can another person deploy and operate what you built?
Lesson and reference-run limitations checked; course and deployment not independently executed · Reviewed 2026-10-31
Reviewed October 30–31, 2026. This is an independent, AI-assisted curriculum. Selection favors concrete mechanisms, decision tradeoffs, primary engineering accounts, and reusable lessons. Repeated role introductions, generic company homepages, tool directories, and uncorroborated salary or ROI claims do not become core learning resources.
“Content checked” means text was retrieved and relevant sections inspected. Book checks cover publisher or author descriptions and contents, plus explicitly noted free chapters; they do not imply full paid-text review. Podcast checks use publisher notes or transcript sections, not full listening. Video playback was not verified. An accessible citation does not independently validate a company’s outcome claim.
Used its coverage of data systems, infrastructure, consulting, and communication to identify gaps in the old library.
Tool-specific instructions and headline business claims were not treated as universal guidance.
Selected chapters informed the progression from problem selection to activation, renewal, and repeatable delivery.
Chinese original. Brief original synthesis only; noncommercial sharing terms do not grant a blanket license to republish the book.
The authorization and productization chapters informed access-control reviews, handoff criteria, and routes for different experience levels.
Chinese original. Hypothetical exercises remain hypothetical; MCP advice is checked against protocol documentation.
Followed its leads into 12-Factor Agents, deployment lifecycle tooling, and GuideLLM rather than copying a long tool list.
Maintenance status was checked. Agent Starter Pack now points to agents-cli; framework labels do not certify production readiness.
Attribution and reuse. Source authors retain their work and their own license terms. This edition uses short original annotations and links; it does not republish the linked books, articles, or repository code. Chinese originals are optional background references; all learning content and UI here are English. Earlier editions also consulted Awesome-FDE — README , The Forward Deployed Engineer Roadmap , and AI Interview Atlas — README .
Source register (79 citations). Includes background and evidence links that are not additional library assignments. Original sources keep their earlier review date. Living pages may change; blocked or partial checks are labeled.
Colin Jarvis · OpenAI · 2026-10-22 · Article
Content checked · Reviewed 2026-10-30
Cognition · Nick Wong · Undated · Article
Content checked · Reviewed 2026-10-30
Leo Mehr · Ramp · 2025-08-05 · Article
Indexed content checked · Reviewed 2026-10-30
Nabeel S. Qureshi · 2024-10-15 · Article
Content checked · Reviewed 2026-10-30
Natalie Meurer · Sierra · 2024-07-11 · Article
Content checked · Reviewed 2026-10-30
Jia Wu · AI Engineer · 2026-07 · Video
Publisher link found; playback unverified · Reviewed 2026-10-30
Leo Mehr · AI Engineer · 2026 · Video
Video title checked; playback unverified · Reviewed 2026-10-30
Vijay Iyengar, Arya Asemanfar & Angie Wang · Sierra · 2026-04-22 · Article
Content checked · Reviewed 2026-10-30
Candidate report · Reddit r/csMajors · 2025 · Candidate account
Content checked; claim uncorroborated · Reviewed 2026-10-30
u/Not_the_Sauron · Reddit r/csMajors · 2025 · Candidate account
Content checked; claim uncorroborated · Reviewed 2026-10-30
Anthropic · 2026-01-09 · Article
Content checked · Reviewed 2026-10-30
Anthropic · 2025-06-13 · Article
Content checked · Reviewed 2026-10-30
Thrive Holdings & OpenAI engineering teams · 2026-05-27 · Article
Content checked · Reviewed 2026-10-30
OpenAI · Morgan Stanley · Undated · Case article
Content checked · Reviewed 2026-10-30
Anthropic · Rakuten · Undated · Case article
Indexed content checked · Reviewed 2026-10-30
Sierra · Sonos · Undated · Case article
Content checked · Reviewed 2026-10-30
Sierra · WeightWatchers · Undated · Case article
Content checked · Reviewed 2026-10-30
Cognition LATAM Team · 2026-09-22 · Article
Indexed content checked · Reviewed 2026-10-30
Cognition · 2025-11-14 · Article
Indexed content checked · Reviewed 2026-10-30
Marc Brooker · AWS · 2019-12-05 · Article
Content checked · Reviewed 2026-10-30
Brandur Leach · Stripe · 2017-02-22 · Article
Content checked · Reviewed 2026-10-30
Chris Jones, John Wilkes & Niall Murphy with Cody Smith · Google SRE · Book chapter · Article
Content checked · Reviewed 2026-10-30
Eric Migicovsky · Y Combinator · 2019 · Video
Video title checked; playback unverified · Reviewed 2026-10-30
Andrew Ng · DeepLearning.AI · 2026-05-29 · Article
Indexed content checked; direct access blocked · Reviewed 2026-10-30
swyx · Latent Space · 2023 · Article
Content checked · Reviewed 2026-10-30
Rosie Roca & Natalie Meurer · Sierra · 2025-11-03 · Article
Indexed content checked · Reviewed 2026-10-30
Milos Mandic · FDE Hub · 2026-05-28 · Interview article
Indexed content checked · Reviewed 2026-10-30
libaice & contributors · Living document · Repository document
GitHub content checked · Reviewed 2026-10-30
ritesh-18 & contributors · Living document · Repository document
GitHub content checked · Reviewed 2026-10-30
eiler2005 & contributors · Living document · Repository document
GitHub content checked · Reviewed 2026-10-30
AIE Talks / Kitaru · 2026-07 · Talk companion
Content checked · Reviewed 2026-10-30
MDN contributors · Living documentation · Documentation
Content checked · Reviewed 2026-10-31
PostgreSQL Global Development Group · Version 18 · Documentation
Content checked · Reviewed 2026-10-31
Martin Kleppmann & Chris Riccomini · 2026-02 · Book
Publisher description and contents checked; full paid text not reviewed · Reviewed 2026-10-31
Gregor Hohpe & Bobby Woolf · 2003-10 · Book
Publisher description and contents checked; selected author excerpts checked · Reviewed 2026-10-31
Rob Fitzpatrick · Author book page · Book
Dedicated book page checked; full paid text not reviewed · Reviewed 2026-10-31
Peter Block · 2023-05 · Book
Indexed publisher description checked; direct access blocked; full paid text not reviewed · Reviewed 2026-10-31
Will Larson · 2021 · Book
Author book page and linked free guide checked; full paid text not reviewed · Reviewed 2026-10-31
Chip Huyen · 2024-12 · copyright 2025 · Book
Publisher description and contents checked; full paid text not reviewed · Reviewed 2026-10-31
Matthew Skelton & Manuel Pais · 2025 · Book
Author book page checked; full paid text not reviewed · Reviewed 2026-10-31
Anthropic · 2025-09-29 · Article
Content checked · Reviewed 2026-10-31
Anthropic · 2025-09-11 · Article
Content checked · Reviewed 2026-10-31
Dex Horthy · HumanLayer · Living document · Repository document
GitHub chapter and project README checked · Reviewed 2026-10-31
Dex Horthy · AI Engineer · 2025 · Video
Linked by the author’s README; playback unverified · Reviewed 2026-10-31
Hamel Husain & Shreya Shankar · Living article · Article
Content and selected detailed answers checked · Reviewed 2026-10-31
OWASP contributors · Living documentation · Documentation
Content checked · Reviewed 2026-10-31
Model Context Protocol contributors · Draft · checked 2026-10-31 · Documentation
Content checked; draft is not a pinned stable specification · Reviewed 2026-10-31
Ruoming Pang et al. · Google · 2019 · Paper
Paper and authorization-consistency section checked · Reviewed 2026-10-31
OWASP contributors · Living documentation · Documentation
Content and defense limitations checked · Reviewed 2026-10-31
Google SRE contributors · 2018 · Book chapter
Content checked · Reviewed 2026-10-31
David Challoner et al. · Google SRE · 2018 · Book chapter
Content checked · Reviewed 2026-10-31
Alec Warner & Stepan Davidovic, with contributors · Google SRE · 2018 · Book chapter
Content checked · Reviewed 2026-10-31
vLLM / GuideLLM contributors · Living document · Repository document
GitHub README checked; software not executed · Reviewed 2026-10-31
Google · agents-cli contributors · Living document · Repository document
GitHub README checked; software not executed · Reviewed 2026-10-31
Google Cloud contributors · Living document · Repository document
GitHub README checked · Reviewed 2026-10-31
Ron Kohavi, Alex Deng, Brian Frasca, Toby Walker, Ya Xu & Nils Pohlmann · 2013 · KDD · Paper
Author page and paper checked · Reviewed 2026-10-31
Stripe engineering · 2017 · Case article
Content checked · Reviewed 2026-10-31
Jason Warner · GitHub · 2018-10-30 · updated 2021-12-19 · Case article
Content checked · Reviewed 2026-10-31
Ben Lorica & Charity Majors · O’Reilly · 2026-10-15 · Podcast
Publisher notes and timestamps checked; audio not played · Reviewed 2026-10-31
Shreya Shankar with swyx & Alessio Fanelli · Latent Space · 2023-03-29 · Podcast
Publisher transcript sections and timestamps checked; audio not played · Reviewed 2026-10-31
Pat Helland & Tim Berglund · Confluent Streaming Audio · 2021-05-20 · Podcast
Publisher transcript sections checked; audio not played · Reviewed 2026-10-31
Pier Paolo Ippolito & Paolo Perrone · Living document · Repository document
GitHub README checked · Reviewed 2026-10-31
Fan Bing / XDash · Living document · Chinese original · Repository document
README, selected chapters 2/4/5/7 and source appendix checked · Reviewed 2026-10-31
VanGong1999 & contributors · Living document · Chinese original · Repository document
README, SSO/authorization and productization chapters checked · Reviewed 2026-10-31
global-fde contributors · Living document · Repository document
GitHub README checked; selected downstream projects inspected · Reviewed 2026-10-31
Vinoo Ganesh · Next Play · 2026-02-05 · First-person essay
Content checked; personal retrospective and opinions, not independently audited outcomes · Reviewed 2026-10-31
Chinemerem E. · Palantir Blog · 2021-10-21 · Employer-hosted personal essay
Content checked; author uses an abbreviated surname · Reviewed 2026-10-31
Het Trivedi · Baseten · 2024-05-31 · updated 2025-05-17 · Employer-hosted personal essay
Content checked; early-tenure account, not a hiring guarantee · Reviewed 2026-10-31
Hiro Hayami · AI Shift on note · 2026-07-08 · Employer-hosted personal essay
Platform AI translation checked; Japanese original; English name follows that translation · Reviewed 2026-10-31
Milos Mandic · FDE Hub · 2025-12-09 · First-person work diary
Content checked; self-reported week at Lleverage, not a representative workload survey · Reviewed 2026-10-31
Henry Chang · LinkedIn · Exact date not exposed · edited public post · First-person public post
Public post text checked; project results not independently corroborated; access may require sign-in · Reviewed 2026-10-31
Vlad Shulman · Baseten · 2025-06-10 · updated 2025-06-11 · First-person team-building account
Content checked; employer-hosted account of one team’s organizational choices · Reviewed 2026-10-31
Dongying Zhou · ActionIQ Tech Blog · 2021-12-05 · Employer-hosted personal essay
Content checked; describes a 2021 internal move and company-specific role boundaries · Reviewed 2026-10-31
R&D · FDE Academy / Futurense · 2026-09-24 · Training-provider article
Content checked; provider self-description, not an independent assessment of training outcomes · Reviewed 2026-10-31
Plank · Undated · living page · Provider context only
Content checked; background only, not a learning assignment or independent endorsement · Reviewed 2026-10-31
Plank · AI FDE Course · Undated · living lesson · Hands-on lesson
Lesson and reference-run limitations checked; course and deployment not independently executed · Reviewed 2026-10-31
FIELD GUIDE / 03
Eight advanced discussion guides for working FDEs. These are original editorial syntheses grounded in the cited material; the scenarios are illustrative, not additional customer claims. Bring a current project and use the evidence prompt to test your reasoning.
F01 / Evaluation
A model change improves average success, but users report more incorrect actions.
A release table: baseline → candidate, task slice, sample size, uncertainty, severe failures, latency, and decision owner.
Common trap: Repeatedly tuning against the held-out set quietly turns it into development data.
F02 / Security
A removed user can still obtain a newly edited document through a search cache.
A regression sequence: grant → fetch → revoke → edit → fetch/export, across two users and two tenants.
Common trap: Testing only the initial retrieval misses caches, previews, and generated summaries.
F03 / Integration
A CRM update times out after the remote system commits it. An agent retries.
A state diagram covering not started, in flight, committed, failed, and unknown; test a lost response after commit.
Common trap: Persisting the conversation or retry counter does not make the external effect exactly-once.
F04 / Retrieval
A convincing answer cites the wrong policy despite an apparently strong language model.
A failure ledger that points each bad answer to the earliest failed stage and the correct source passage.
Common trap: Improving answer fluency can conceal that the evidence was never available to the model.
F05 / Economics
A cheaper model needs more retries and longer human review.
A sensitivity table for task volume, success rate, review minutes, and support hours; use ranges rather than an unsupported ROI point estimate.
Common trap: Multiplying every minute saved by a salary rate does not establish realized financial savings.
F06 / Adoption
The sponsor likes the demo, but operators return to spreadsheets after launch.
A cohort table from eligible users → first successful task → repeat success, alongside support load and reasons for abandonment.
Common trap: A signed-off demo, a login, and a successfully completed task are different events.
F07 / Productization
Three customers need similar integrations, each living on a different branch.
A second engineer deploys to a second environment; measure effort, exceptions, and the remaining dependency on the original author.
Common trap: Copying a repository creates another instance. It does not establish a supported product.
F08 / Reliability
Automated database failover restores connectivity but leaves divergent writes.
A recovery drill recording the protected invariant, data-loss exposure, restoration time, and safe replay conditions.
Common trap: A healthy infrastructure dashboard does not prove the recovered application is correct.
FIELD GUIDE / 09
588 open postings at 92 companies, grouped by employer. Snapshot checked October 31, 2026.
How this list is built: an automated pass over the public Greenhouse, Lever, and Ashby job boards of 317 AI, data, software, and defense companies, keeping titles that contain Forward Deployed, FDE, Deployment Strategist, Special Projects Engineer, or AI Deployment Engineer. Each link opens the employer’s own posting. Postings close without notice, titles vary by employer, and companies using other hiring systems (for example Workday) are not covered. A listing is not an endorsement, and this site is not affiliated with any employer.
No matches. Try another search or clear the filters.
113 open postings · Greenhouse
106 open postings · Lever
34 open postings · Ashby
$185K – $300K • Offers Equity
$185K – $300K • Offers Equity
$185K – $300K • Offers Equity
$185K – $300K • Offers Equity
$185K – $300K • Offers Equity
$185K – $300K • Offers Equity
$185K – $300K • Offers Equity
$185K – $300K • Offers Equity
$185K – $300K • Offers Equity
$266K – $445K • Offers Equity
$153K – $325K • Offers Equity
$153K – $325K • Offers Equity
$185K – $325K • Offers Equity
$145.8K – $280K • Offers Equity
$207K – $294K • Offers Equity
$230K – $294K • Offers Equity
$230K – $294K • Offers Equity
$302K – $385K • Offers Equity
17 open postings · Ashby
$115K – $180K • Offers Equity • Offers Bonus
$100K – $200K • Offers Equity • Offers Bonus
$115K – $200K • Offers Equity • Offers Bonus
$115K – $200K • Offers Equity • Offers Bonus
$100K – $200K • Offers Equity • Offers Bonus
$115K – $180K • Offers Equity • Offers Bonus
$115K – $200K • Offers Equity • Offers Bonus
$115K – $200K • Offers Equity • Offers Bonus
$115K – $180K • Offers Equity • Offers Bonus
15 open postings · Greenhouse
13 open postings · Ashby
CA$175K – CA$385K • Offers Equity • Multiple Ranges
₩230M – ₩315M • Offers Equity
$240K – $415K • Offers Equity • Multiple Ranges
CA$175K – CA$385K • Offers Equity • Multiple Ranges
CA$215K – CA$385K • Offers Equity
CA$175K – CA$385K • Offers Equity
CA$320K – CA$385K • Offers Equity • Multiple Ranges
CA$320K – CA$385K • Offers Equity • Multiple Ranges
12 open postings · Lever
11 open postings · Greenhouse
11 open postings · Ashby
$180K – $280K • Offers Equity • Offers Bonus
11 open postings · Ashby
11 open postings · Ashby
9 open postings · Greenhouse
9 open postings · Ashby
9 open postings · Ashby
9 open postings · Ashby
$264K – $379.5K
$304K – $437K
$200K – $270K
$236K – $339.2K
8 open postings · Greenhouse
$130K – $160K • Offers Equity
7 open postings · Greenhouse
7 open postings · Greenhouse
7 open postings · Greenhouse
6 open postings · Ashby
$150K – $190K • Offers Equity
$150K – $190K • Offers Equity
$210K – $240K • Offers Equity
$210K – $240K • Offers Equity
$190K – $210K • Offers Equity
6 open postings · Ashby
€56K – €83K • Offers Commission
$155K – $170K
$220K – $300K
6 open postings · Greenhouse
6 open postings · Greenhouse
5 open postings · Greenhouse
5 open postings · Greenhouse
5 open postings · Greenhouse
4 open postings · Ashby
$254.6K – $350K • Offers Equity
$254.6K – $350K • Offers Equity
$254.6K – $350K • Offers Equity
4 open postings · Ashby
4 open postings · Greenhouse
4 open postings · Ashby
$190K – $240K
3 open postings · Greenhouse
3 open postings · Greenhouse
3 open postings · Ashby
$155K – $210K • Offers Equity
$190K – $240K • Offers Equity
$210K – $300K • Offers Equity
3 open postings · Ashby
$165K – $330K • Offers Equity
$200K – $400K • Offers Equity
$165K – $330K • Offers Equity
3 open postings · Greenhouse
3 open postings · Ashby
$180K – $245K • Offers Equity • Offers Bonus
$155K – $193K • Offers Equity • Offers Bonus • 10% Annual Bonus
$197K – $246K • Offers Equity • Offers Bonus • 10% Annual Bonus
3 open postings · Greenhouse
3 open postings · Greenhouse
3 open postings · Greenhouse
3 open postings · Ashby
3 open postings · Greenhouse
3 open postings · Greenhouse
3 open postings · Ashby
$160K – $210K • Offers Equity • Multiple Ranges
$95K – $140K • Offers Equity • Offers Bonus • Multiple Ranges
£70K – £90K • Offers Equity • Offers Bonus
3 open postings · Greenhouse
3 open postings · Ashby
$132K – $184K • Offers Equity
$146K – $204K • Offers Equity
$146K – $204K • Offers Equity
2 open postings · Ashby
2 open postings · Ashby
$180K – $220K
$130K – $160K • Offers Equity
2 open postings · Greenhouse
2 open postings · Greenhouse
2 open postings · Greenhouse
2 open postings · Ashby
$130K – $190K • Offers Equity
$180K – $230K • Offers Equity
2 open postings · Ashby
$140K – $220K • 0.1% – 0.9% • Brooklyn housing subsidy offered!
$120K – $150K • 0.05% – 0.2%
2 open postings · Ashby
$165K – $220K • Offers Equity
2 open postings · Ashby
$175.1K – $245K • Offers Equity
$237,150 – $369,150 • Offers Equity
2 open postings · Greenhouse
2 open postings · Ashby
$180K – $250K • Offers Equity
$180K – $240K • Offers Equity
2 open postings · Greenhouse
2 open postings · Ashby
$90K – $100K • Offers Equity
2 open postings · Lever
2 open postings · Ashby
$168K – $285K • Offers Equity
$189K – $330K • Offers Equity
2 open postings · Greenhouse
2 open postings · Ashby
$125K – $175K • Offers Equity • Offers Benefits
2 open postings · Lever
2 open postings · Ashby
$170K – $190K
$160K – $180K • Offers Equity • $40K – $50K Bonus
2 open postings · Greenhouse
2 open postings · Greenhouse
2 open postings · Ashby
$100K – $200K • Offers Equity
$150K – $180K • Offers Equity
1 open posting · Ashby
$260K – $290K • Offers Equity
1 open posting · Greenhouse
1 open posting · Ashby
1 open posting · Ashby
$160K – $200K • Offers Equity
1 open posting · Greenhouse
1 open posting · Ashby
1 open posting · Greenhouse
1 open posting · Greenhouse
1 open posting · Ashby
1 open posting · Greenhouse
1 open posting · Ashby
1 open posting · Greenhouse
1 open posting · Greenhouse
1 open posting · Ashby
1 open posting · Ashby
$100K – $150K • Offers Equity
1 open posting · Ashby
1 open posting · Lever
1 open posting · Ashby
1 open posting · Ashby
$120K – $200K
1 open posting · Greenhouse
1 open posting · Ashby
$180K – $300K • Offers Equity
1 open posting · Ashby
$250K – $280K • Offers Equity • Offers Bonus
1 open posting · Greenhouse
1 open posting · Ashby
$120K – $200K
1 open posting · Greenhouse
FIELD GUIDE / 10
Progress, story reviews, interview notes, and self-assessments stay in this browser. Nothing is sent to a server. Export a backup before changing browsers, clearing storage, or moving this file.
COMPLETION
0 / 16 questions reviewed · 0 / 17 cases discussed
0 / 37 library resources applied
0 / 8 stories reflected on
A checked box records completion, not mastery. Use the evidence gates and a peer review to judge the quality of the work. Earlier v2 progress backups remain compatible.
Continue learning →YOUR BACKUP
The downloaded HTML is the clean public guide. Exported JSON contains your private notes and scores; share that only intentionally.
Editorial rubric · revisit after a real project
0 = no evidence yet · 1 = can explain · 2 = delivered with support · 3 = delivered independently with measured results. This is a reflection tool, not a certification.