FDE Masterclass Certification

Syllabus

Every paper is drawn to this mix, so the weights are a promise rather than a guide. The bars show each area's share of the 65 questions.

• What an FDE does

  2 Q·3%

  The post-sale outcome contract, the embedded-in-the-customer-stack working mode, and the three jobs an FDE is most often confused with.

• The FDE hiring landscape

  2 Q·3%

  The companies hiring FDEs in 2025–26, what each one emphasises in its JD, and how the role differs across a frontier lab, an applied-AI startup, and Palantir.

• Tokens, context windows and cost

  3 Q·5%

  What a token actually is, how context budgets translate into latency and dollars, and the mental model a customer conversation needs rather than a benchmark.

• Model families and selection

  3 Q·5%

  Choosing between frontier, mid-tier and small models per task, routing by cost and latency, and the trade a customer should understand before signing off.

• Sampling and determinism

  2 Q·3%

  Temperature, top-p, seeds and the honest limits of reproducibility — and why 'it worked yesterday' is never evidence in an FDE's hands.

• What evaluation means

  2 Q·3%

  Evaluation framed as a measurement problem rather than a scoring one, and why the eval you can run cheaply is the one that actually changes decisions.

• Scoping a prompt

  3 Q·5%

  What belongs in a prompt and what belongs in retrieval, pointing at sources rather than pasting them, and the vague-prompt-on-purpose case.

• Structured output and tool schemas

  3 Q·5%

  Binding output to a JSON schema, tool-use schemas as the same mechanism, and the failure modes that a demo hides and production surfaces.

• Prompt caching

  2 Q·3%

  What prompt caching actually caches, the cost curve it changes, cache-key hygiene across customer tenants, and the latency wins and the misses it hides.

• RAG fundamentals

  3 Q·5%

  What retrieval is buying over a longer context, the retrieve-rank-ground pipeline, and the question 'is this a retrieval problem or a reasoning problem' as the first discipline.

• Chunking strategies

  2 Q·3%

  Chunking as the quietest source of regression in a RAG system — fixed-size versus semantic versus structural, overlap honestly, and what a bad chunk boundary does to a judge rubric.

• Hybrid search and reranking

  3 Q·5%

  Dense plus sparse (BM25) retrieval, score fusion (RRF and friends), cross-encoder rerankers, and the recall-versus-latency trade in an FDE's own numbers.

• Grounding and citation

  2 Q·3%

  Binding answers to passages the user can click, groundedness as a measurable property, and the compliance story it buys you in regulated verticals.

• The agentic loop

  3 Q·5%

  Gather-act-verify as an FDE deploys it on a customer surface, the difference between an agent and a chain, and the stopping conditions that keep one honest.

• Authoring MCP servers

  3 Q·5%

  The Model Context Protocol as a customer-facing boundary, tool schemas, transports, what to expose and what to refuse, and the review the server will fail if you do not run it yourself first.

• Sub-agents and skills

  2 Q·3%

  Context isolation through sub-agents, on-demand loading through skills, and the coordinator-plus-specialists shape of a small team.

• Agent teams

  2 Q·3%

  Fan-out and fan-in patterns, the cost curve of parallel agents, when a human is the right node in the graph, and the failure modes a single agent does not have.

• Why evals are the spine

  2 Q·3%

  Evals as the single investment that separates a POC that ships from a POC that stalls, and the reputation of the topic in the Anthropic and OpenAI loops.

• Judge rubrics and LLM-as-judge

  3 Q·5%

  Writing a rubric a second person can apply to the same output and agree, LLM-as-judge as a reliable practice rather than a shortcut, position bias, and what calibration against human raters actually looks like.

• Dataset curation and regression gates

  3 Q·5%

  Where eval sets come from honestly, the leakage failure mode, synthetic augmentation with its asterisks, and wiring a regression gate that blocks a bad release before it leaves CI.

• Offline vs online evals

  2 Q·3%

  Offline evals as a measurement, online evals and A/B tests as a different question, and the incidents that only the online kind surfaces.

• Auth, data residency and audit

  2 Q·3%

  SSO and SCIM as the baseline a customer security team expects, residency as a deployment constraint rather than a feature, and the audit trail an incident response needs.

• Deployment shapes

  2 Q·3%

  Hosted, VPC and on-prem as three different sales motions, the cost and support implications of each, and the question an FDE should ask before promising one.

• Observability and incident response

  2 Q·3%

  Tracing an agent with span-level context, the metrics and logs an FDE actually looks at on-call, and the runbook the customer should own.

• Customer discovery

  2 Q·3%

  The discovery call as a scoping instrument, questions that surface the real problem rather than the asked-for solution, and the discovery that disqualifies the opportunity.

• Scoping a POC

  2 Q·3%

  Scoping a POC that leads to production rather than a demo, the three commitments to insist on before building, and the exit criteria that let it end.

• Interview loops at top labs

  3 Q·5%

  The Anthropic, OpenAI and Palantir FDE loops as published, the rubric each one leans on, and the rounds candidates most reliably fail — with the signals an interviewer reads for.

Three questions from the bank

Representative of the mix and difficulty — answer visible, shown here to calibrate expectations rather than test you.

1. Sample 1·What an FDE does

   A sales engineer and an FDE both visit a customer in week one. What is the single clearest difference in what they are each on the hook for?

   • AThe sales engineer travels, and the FDE works remotely
   • BThe sales engineer writes code, and the FDE does not
   • CThe sales engineer works on multiple accounts, and the FDE only on one
   • The sales engineer is accountable up to the signed contract; the FDE is accountable for the outcome the contract promised

   Why: The dividing line is when each role's accountability ends. A sales engineer's job is finished when the contract is signed; the FDE's job starts there and ends when the outcome the contract described is actually running in production. Expecting the difference to be about code is a common misread — sales engineers write plenty of code in demos, and the FDE's distinctive work is as much customer-side scoping as it is implementation.

2. Sample 2·The FDE hiring landscape

   A candidate reads two JDs: one from a frontier lab ('build with our platform at a customer'), one from Palantir. What is the clearest structural difference in what the two roles are organised around?

   • APalantir pays more
   • The frontier lab's role is organised around deploying a known platform at a customer; Palantir's is organised around an ambiguous customer problem that the platform is then shaped around
   • COnly one of them writes code
   • DOnly Palantir does on-call

   Why: The two patterns differ in what is fixed and what is variable. At a frontier lab the platform (models, APIs, agents, MCP) is the fixed input and the customer problem gets translated into it. At Palantir the customer's ambiguous problem is the fixed input and Foundry is the configurable surface shaped to it. Candidates who prefer one pattern often do badly in the other and should notice the structural difference rather than treating them as the same role.

3. Sample 3·Tokens, context windows and cost

   A customer asks 'how many words of ours can your system read in one call?' What is the honest shape of the answer an FDE should give?

   • AA specific word count — words map 1:1 to tokens
   • B'It doesn't matter — the model handles any length'
   • A tokenised length, then a translation into roughly N words for English prose while naming that code, JSON, non-English text and long identifiers tokenise more expensively than prose
   • DThe literal context-window number from the datasheet, with no translation

   Why: Customers think in words; models count tokens, and the ratio moves with content. English prose runs around 0.75 words per token; code, JSON and non-English text are heavier. The honest answer is a translation plus the caveat about content type, because a customer promised '200,000 words' will come back furious when their JSON hits the ceiling at 120,000.

What sitting it is like