What’s Missing for FDE

A gap analysis across three layers: what the syllabus omits, what your bank omits, and what neither covers.

Layer 1 · What the syllabus omits (your bank already has it)

871 questions — 49% of your bank — cover ground the bootcamp does not touch. Most of that is interview breadth you do not need for the FDE job. But eight areas are genuinely FDE-critical and the syllabus simply has no module for them:

Action: none needed — you already have these written at 145w median. Just know that the bootcamp will not cover them, so do not assume its completion signals readiness.

Layer 2 · What your bank omits (the syllabus has it)

Already documented in the five notes files — tool fluency: LangGraph APIs, Cypher, ColPali, Zeep, Presidio, Colang, LiteLLM, Fargate. Plus the consulting lifecycle.

Layer 3 · What neither covers

This is the real answer to the question. Eight gaps, ordered by how often they kill FDE engagements.

1. The client environment is the actual constraint ⚠️ biggest gap

Nothing in either resource prepares you for the fact that you will not be able to work the way you work at home.

What you will actually meet:

• No admin rights on the machine you are given. No Docker Desktop. Possibly no pip install.
• VDI with 2 vCPU and clipboard restrictions between host and guest
• A firewall change takes three weeks and requires a named business justification
• Egress blocked by default — you cannot reach pypi.org, huggingface.co or a model API without a proxy exception per host
• Vendor security review before you may deploy anything — pen test, SBOM, questionnaire, 4–8 weeks
• CAB approval for production changes, meeting weekly
• Air-gapped environments in defence, some finance and healthcare — no internet at all, so hosted models are off the table entirely and self-hosting is mandatory

Why this matters more than any technical skill: an FDE who can architect brilliantly but cannot get a package installed delivers nothing. The engineers who succeed are the ones who front-load environment access in week one and treat it as the critical path.

Practical mitigations to know:

• Ask for environment access in the discovery workshop, not after design
• Get an internal package mirror (Artifactory/Nexus) named early — most enterprises have one
• Assume proxy configuration (HTTP_PROXY, NO_PROXY, corporate CA bundle) will consume a day
• Have an offline-capable fallback design for air-gapped clients
• Put “environment access by date” in the SOW assumptions with an owner and a stated timeline impact

2. Bespoke vs product — the defining FDE tension

The role exists because enterprise AI needs customisation. But every hour of bespoke work is an hour that does not scale, and your employer wants reusable product out of client engagements.

Neither resource addresses:

• What to generalise vs what to leave bespoke
• Configuration-driven deployment so client B is a config change, not a fork
• Extracting a reusable component from a delivered system without breaking client A
• The politics of telling a client “we will build this generically, which is slower for you”

The heuristic worth carrying: anything touching the client’s specific data model, identity system or workflow stays bespoke. Anything that is retrieval, evaluation, guardrails, gateway or observability should be product from day one — because you will build it at every client.

3. Commercial and contractual literacy

You will be asked to review or contribute to documents that determine whether the project is profitable and who owns what.

The one that catches AI engineers specifically: IP ownership of what you build. Many enterprise MSAs assign all work product to the client by default — including the reusable framework you were planning to productise. Read that clause, and raise it before you build.

4. Getting SME time for evaluation

The scarcest resource in every enterprise AI project is domain expert time, and you need it for the one thing that cannot be automated: deciding what “correct” means.

Neither resource covers how to actually extract it:

• Pre-label with a model, so the SME reviews and corrects rather than annotating from scratch — typically several-fold throughput
• Active learning so their attention goes to the informative cases, not a random sample
• Budget 2–4 hours total of SME time, not 40, and design the exercise around that ceiling
• Run a calibration session first: three experts label the same 20 items, measure agreement. Low agreement means your rubric is ambiguous, not that the experts are wrong — and it caps what any metric can achieve
• Get the golden set before you build, so acceptance criteria are agreed rather than negotiated after delivery

5. Capability handover — the most common failure

“We built it and they cannot run it.”

Six months after you leave, is the system still running? Neither resource treats this as a design constraint, but it determines whether the engagement is judged a success.

• Pair during the build, not a training session at the end
• Write the runbook as you hit each failure, not retrospectively
• Deliberately have their engineer fix one production issue while you are still there
• Document what to do when it is wrong, not only when it breaks
• Name an owner on the client side with a review date, and include how to turn it off prominently

6. Pre-sales and solution engineering

FDEs are frequently pulled into the sales motion, and nobody teaches it:

• Scoping calls where you must size effort with incomplete information
• Demo engineering — building something convincing in days, knowing it is not production
• The PoC-to-production chasm: PoC success criteria are almost never production criteria, and a successful PoC that cannot be productionised is a specific, common trap
• Estimating for a proposal, then living with the estimate

7. Organisational navigation at the client

Your bank’s Section 2 covers your organisation’s politics. The client’s are different and harder because you have no authority and no history.

• Whose job does this threaten? That person is your most important stakeholder and is rarely in the kickoff.
• The blocker who will not grant data access is usually protecting something legitimate — find out what
• Sponsor and practitioners will describe different processes; the documented one is not the real one
• Build a coalition before the steering committee, not during it

8. Multi-tenancy and productisation from day one

If what you build for client A is meant to become a product, tenancy cannot be retrofitted. Your bank covers multi-tenant serving (S15, S18, S30) but not the decision to build that way when the first client is singular — and the commercial pressure is always to ship faster for the one client in front of you.

What I would actually do

Do not add more technical study. Between the bank and the bootcamp you are well past the technical bar. Three concrete actions instead:

1. Build one thing under realistic constraint. Deploy a project with no admin rights, behind a proxy, with egress allowlisting. You will learn more about FDE reality in two days than in two weeks of tutorials.

2. Do an Azure version of Capstone 1. Entra ID instead of Cognito, Azure OpenAI instead of Bedrock, Azure AI Search instead of Pinecone. The syllabus’s AWS-only stance is its largest blind spot given enterprise reality.

3. Write the three consulting artefacts for real. Take a project you have actually done and produce a discovery memo, a SOW with a genuine out-of-scope section, and an ROI deck with the working-time sanity check applied. These are the deliverables you cannot fake in an interview, and they are the fastest thing on this list to complete.

The honest summary

The last three cannot be studied from documentation — which is precisely why they are the differentiator, and why the FDE role pays what it does.