Breaking into Forward Deployed Engineering

Measure where you stand

• Score yourself against the FDE skill set and find the specific gap between your current role and the role you want.
• Decide which parts of the course to go deep on and which to review quickly.

Refresh the engineering foundations

• Work fluently at the command line, because you deploy into environments that have no graphical tools.
• Use Git, package managers and environment managers without looking anything up.
• Build a REST service in Python with FastAPI, backed by a SQL database.
• Read logs and debug a running service.
• Build a working demo interface in React or Streamlit that you can put in front of a customer.

Choose your lane, and decide whether it is FDE

• Compare the actual day-to-day work of an AI engineer, an AI product manager, a machine learning engineer, a solutions engineer, a sales engineer and an FDE, rather than their job titles.
• Match your background to a lane, including the case for not choosing this one.
• Measure success as the return on investment the customer gets, not the number of sprints completed.
• Trace the role from its origins at Palantir to the current hiring wave at AI companies, and understand why demand is rising now.
• Understand what you own in the role: the engineering, the consulting and the technical decisions a customer's CTO would otherwise make.
• Understand the cycle an FDE runs repeatedly: build the system, deploy it, then get the customer's team to adopt it.

Discover, scope and price an engagement

• Watch the customer's users do the work before writing any code, so you see the real workflow rather than the description of it.
• Run a discovery call that separates the stated request from the underlying problem.
• Scope the smallest deployment that delivers value, and keep scoping as the engagement changes.
• Recognise deployments that are likely to fail, and raise the risk before you write code.
• Write a one-page scope document: what the system does, what it does not do, what access you need, and how both sides will know it worked.
• Turn the customer's business rules into a technical specification and a sequenced plan. Ship a rough working version first, then harden it.
• Trade off scope against speed against quality, and say which one you gave up.
• Price the engagement as fixed scope, time and materials, or value-based, and understand how each model changes your incentives.
• Write and defend a statement of work.

Build the integration stack

• Connect systems with Python and TypeScript, APIs, webhooks, SQL and ETL jobs.
• Process customer datasets that are too large for one machine with Spark, so data preparation does not stall on a laptop-sized tool.
• Build a first integration against a mock environment that has missing fields, inconsistent formats and undocumented endpoints.
• Add logging and make operations idempotent, so a retried request does not repeat a side effect.
• Track cost from the first day with prompt caching, model routing and token budgets.

Build a full-stack AI product

• Connect a React frontend, a Node.js or FastAPI backend and an AI backend as one product, with shared state, streaming responses and error handling across all three layers.
• Trace a single request from the browser to the model and back, so you can debug a failure at any layer.
• Store conversation history and application state in MongoDB, and decide when a relational database such as PostgreSQL is the better fit.
• Deploy the frontend to Vercel and the backend as a container, so a reviewer can use the product from a link.

Work with LLMs directly

• Run the agent loop by hand: the model reasons, calls a tool, reads the result, and decides the next step.
• Write system prompts and enforce structured outputs, so downstream code receives data in the shape it expects.
• Engineer the context the model sees, and design the harness around it.
• Prototype a prompt and its tool definitions in the Anthropic Console Playground, then move the version that works into code.
• Call the Claude Messages API directly with tool use, then rebuild the same agent with an agent SDK: the Claude Agent SDK, the OpenAI Agents SDK, or LangGraph.
• Build the same agent with LangChain, and know which parts the framework handles for you and which parts you still have to write.
• Define tool inputs and model outputs as Pydantic models, so malformed data is rejected where it enters the application rather than failing further in.
• Decide between a managed agent service and a self-hosted agent, based on the customer's data rules and operating budget.
• Diagnose why prompt caching is not taking effect, and measure what long contexts cost in accuracy and money.

Choose the agent architecture deliberately

• Choose between tools, skills, subagents, MCP servers and Code Mode, and defend the choice.
• Design tool schemas the model can call correctly.
• Build multi-agent systems with orchestrator, planner and executor roles, and add points where a human must approve before the agent continues.
• Connect agents to each other and to outside systems with MCP and A2A.
• Contain failures, so one agent's error does not spread through the whole workflow.
• Give long-running agents semantic, procedural and episodic memory.
• Use spec-driven development and loop patterns that hold up across a deployment that runs for several weeks.

Build voice agents

• Compare a cascaded pipeline (speech to text, then the model, then text to speech) against a speech-to-speech model on latency, cost and control.
• Transcribe speech with Whisper, or with faster-whisper when latency matters, and measure transcription errors before they reach the model.
• Build an open-source voice agent and deploy it.

Look after the customer's data and run your own models

• Understand why open-weight models are a practical answer to a customer's data rules, not a position on open source.
• Run Llama-class and Qwen-class models with vLLM or Ollama, sized to the hardware the customer has.
• Host an open-weight model with vLLM on RunPod GPUs, or route requests through OpenRouter, so you can change model or provider without rewriting the application.
• Generate synthetic data, so you can prototype and backtest before you are cleared to see the customer's real data.
• Fine-tune with LoRA or QLoRA when the domain requires it, replace a closed model with the result, and use evaluations to decide whether the fine-tune was worth the cost.
• Run the fine-tune on the Hugging Face stack: Transformers to load the model, PEFT to attach the adapter, TRL's SFTTrainer to train it, and BitsAndBytes to quantise the base model to 4 bits so it fits on one GPU.
• Publish the trained adapter to the Hugging Face Hub, and benchmark it against the base model on the same evaluation set.
• Handle voice and image input for customers whose workflow does not start with a text box.

Build retrieval you can defend

• Learn what classic RAG, GraphRAG, agentic search and multimodal retrieval are each suited to.
• Choose between them with a rubric based on corpus shape, data freshness, query pattern and cost per answer.
• Chunk documents, generate embeddings, and combine keyword and vector search with rank fusion.
• Store embeddings in FAISS or Chroma for local work, in Pinecone as a managed service, or in pgvector when the customer already runs PostgreSQL. Choose between them on scale, cost and who has to operate the store.
• Build the same retrieval pipeline with LangChain and with LlamaIndex, and compare how much of the indexing and querying each framework does for you.
• Add semantic caching so that repeated questions do not pay for retrieval and generation twice.
• Add a knowledge graph when answers depend on relationships between entities.
• Search inside audio and video, and return the moment that answers the question rather than the whole file.
• Scale a retrieval pipeline to millions of documents while keeping latency and cost within the customer's limits.
• Measure retrieval quality directly, and detect the retrieval drift that tends to appear months after launch.

Use evaluations as the shared language with the customer

• Start an evaluation set at the prototype stage and grow it as the deployment grows.
• Evaluate an agent on its trajectory, meaning the steps it took, and separately on its outcome, meaning the final result.
• Build LLM-as-judge evaluators and custom metrics such as faithfulness and relevance, and check that the judge agrees with human raters.
• Backtest against user feedback, and test agents by simulating users.
• Add evaluation gates to CI, so that a regression fails the build and does not reach the customer.
• Track experiments, model versions and evaluation runs in MLflow, so you can show which change moved which score.
• Tie each evaluation to a business metric the customer tracks, so you can present the results to their finance team as evidence of value.

Defend against adversaries and add guardrails

• Add guardrails in stages from prototype to production. An instruction in the prompt is not a control, because an attacker can write prompts too.
• Explain the difference between direct and indirect prompt injection, and which one matters more in an enterprise deployment.
• Build a prompt-injection attack against your own application, improve it, then close the vulnerability.
• Treat retrieved documents and tool descriptions as untrusted input, because anyone who can write to the document store can plant instructions.
• Limit what an agent can do in code, not in the prompt, when it can issue refunds, update records or call production systems.
• Add model-based safety classifiers such as Llama Guard, and write explicit policy rules for what the system may and may not do.
• Validate model output with Guardrails AI, starting with pattern checks and adding semantic checks as the risk of a wrong answer rises.
• Understand Constitutional AI, Anthropic's method of training a model against a written set of principles, and what it does and does not guarantee about a system you deploy on that model.
• Redact personal data at all four points where it enters the system: user input, retrieved context, tool results and model output.
• Red-team a customer's system before go-live, and state the finding that would make you block the launch.
• Answer a customer who asks whether you train on their data, and explain what zero data retention does and does not change.

Deploy in someone else's environment

• Use Docker, Kubernetes, Terraform, CI/CD and cloud primitives on AWS, GCP and Azure, which are the tools customers will hand you.
• Use managed AI services: AWS Bedrock, Azure AI Foundry and Google Vertex AI.
• Package the whole system with Docker Compose, so a reviewer or a customer can start every service with one command.
• Split a product into services (application, inference, retrieval and background workers) that scale independently, and connect them with message queues.
• Set up SSO and SAML, authentication, secrets management, data boundaries and isolation between tenants.
• Integrate with legacy systems that are older than the customer's current technical leadership.
• Add tracing and dashboards that report latency, cost and quality for every request.
• Set alerts and spending limits, so a usage spike does not produce a bill the customer did not budget for.

Pass the customer's security and compliance review

• Work with SOC 2, HIPAA, GDPR and FedRAMP requirements at the level an FDE needs to answer a reviewer.
• Design data handling for a customer whose data must stay in the EU, and prove it in an audit.
• Scope an agent's access to the customer's systems and keep an audit trail of every action it takes.
• Keep a security review moving when it blocks go-live a week before launch, without cutting a corner you will regret.

Work on two fronts: the customer and your own product team

• Turn edge cases from the field into evidence for the product roadmap.
• Decide whether a request needs a one-off fix or a product feature, so you protect the platform while unblocking the customer.
• Package work you built for one customer into a reusable tool your product team can own.
• Map the customer's stakeholders: who supports the project, who opposes it, and how to say no to either.

Run incidents and hand over

• Own an incident at 2 a.m.: what to do in the first minutes, how to communicate, and how to decide between rolling back and pushing a fix.
• Find the root cause of a failure with almost no information, by stating a hypothesis, asking for the one signal that would confirm it, and changing course when the evidence disagrees.
• Write a post-mortem that separates the trigger from the root cause and keeps the customer's trust.
• Write documentation, runbooks and training so the deployment keeps running after you leave.
• Deliver an executive readout: a value memo in the customer's own measures, the numbers behind it, and the handover document.

Target the right employers before you apply

• Understand the three types of employer and how their interview loops differ: frontier labs, AI-native startups, and enterprise, cloud and consulting firms. Most openings are not at the labs.
• Learn how much coding each seniority level faces, and which employers still ask data-structures-and-algorithms questions.
• Write a one-page target brief that names three companies across the three types and gives a reason for each.

Get through the screens

• Answer the question that filters more candidates than any other: why FDE and not a regular software engineering role.
• Describe your past projects in terms of your own decisions, so the interviewer can find your contribution.
• Rewrite your resume for FDE roles in the session, rather than reading advice about it.

Bring the roles to you

• Build in public, so recruiters and hiring managers find your work.
• Send outreach without a referral, using scripts written for specific recipients.
• Use a portfolio project as the reason a stranger replies.
• Show work your employer owns without breaking confidentiality.
• Run a portfolio project inside your current company, so it counts as work experience rather than as a side project.

Know the rounds before you face them

• Study the eleven types of round that FDE loops draw from. Any one employer uses between five and seven of them.
• Compare how seven companies run their loops: Palantir, OpenAI, Anthropic, Salesforce, Databricks, Apple and Cohere.
• Prepare for a frontier lab's mission or values round, including how to discuss the lab's published safety commitments, such as Anthropic's Constitutional AI.

Prepare for the technical rounds

• Recognise the formats in use: AI-assisted rounds where the interviewer reads your whole conversation with the model, agentic take-home assignments, and traditional coding loops.
• Solve the same problem twice, once with an AI assistant and once without, and explain your reasoning both times.
• Pair with an AI assistant in a live round, and explain why you accept or reject each suggestion.
• Write idiomatic Python, including generators and asyncio, and practise the coding patterns that recur in AI loops.
• Extend a working build one constraint at a time, for example making a rate limiter concurrent.
• Clean and reshape undocumented data with errors in it.
• Treat a take-home build as a customer deliverable: ask questions first, decide how you will show it works before you build, and record a video walkthrough that explains your decisions rather than reading out the code.

Prepare for the design and debugging rounds

• Run a 45-minute AI system design covering retrieval, agents, guardrails, evaluations, tracing and cost.
• Prepare for the failure modes interviewers probe deliberately: retrieval drift, agents that call tools in a loop, and cost that grows without anyone noticing.
• State latency and cost budgets out loud, with prompt caching and model routing as the levers.
• Debug a failing system from an architecture diagram and a vague report, by reasoning about likely causes rather than running through a checklist.

Prepare for the FDE rounds

• Break an ambiguous customer brief into a phased plan in 60 minutes with no code: clarify the goal, identify stakeholders and success measures, map the available data, split the work into sequenced parts, and propose the first version to ship. This round decides most offers.
• Build under time pressure in a live demo, and decide what to cut first when you run out of time.
• Hold a difficult conversation with an interviewer playing the customer: telling a CTO the deployment is three weeks late, refusing a promise of 100% accuracy, or getting production access from a security team that will not grant it.
• Explain a technical decision to someone who will never read the code.
• Repeat recorded reps, scored against the rubric, until these moves are automatic.

Practise on regulated-industry cases

• Work through three cases from start to finish: flagging loan documents at a regulated bank, a clinical scheduling assistant under HIPAA, and claims triage under insurance AI rules.
• For each case, run discovery and scoping, answer the technical round, answer the values round, and review your performance in a debrief.

Prepare for the behavioral round and the offer

• Prepare six stories tuned to each type of employer. Each story states the situation, your action, the result and the impact on the customer. One story must be about a deployment that stalled, because that is the FDE-specific question.
• Prepare a story about refusing a customer request that was technically unwise while keeping the relationship.
• Present a 30, 60 and 90-day plan for your first customer.
• Understand the career paths from FDE to founder and to VP, and how compensation is structured: base plus equity, or base plus commission.
• Negotiate: anchor on total compensation, raise equity first, and run several processes in parallel.
• Read an offer and tell equity you can value apart from equity you are asked to trust.

How you are assessed

• Get feedback on your resume and portfolio in the first week, not the last.
• Take timed mocks and recorded reps, scored against rubrics that match the ones companies use.
• Deliver a scored capstone readout: the scope memo, the working deployment, the value numbers and the handover.
• Leave with resume templates, an interview-prep checklist, outreach scripts and a starter evaluation set.

Hiring Manager's Keen Eye

• Splits "wrong" into distinct failure modes unprompted, not after being nudged.
• Proposes different eval strategies per mode (automated for numbers, human-eval for tone, classification for risk).
• Has a forcing function for stakeholder disagreement, such as inter-rater reliability, not "let's have a meeting."
• Sets per-dimension thresholds that pass independently. Averaging is a red flag.

Weak-hire Answer

• LLM-as-judge with a 1 to 5 scale, averages the three dimensions into one score.
• "Have a meeting and get everyone aligned" is the entire stakeholder strategy.
• Suggests confidence scores and thumbs-up/down feedback, no labeled corpus.
• Treats tone and risk alignment the same way as factual accuracy.

Strong-hire Answer

• Decomposes into three failure modes immediately, with a different eval strategy per mode.
• Computes inter-rater agreement among the advisors first and uses their own disagreement rate as a negotiation lever.
• Per-dimension thresholds that must each pass independently, never averaged.
• Names the compliance risk on risk-profile misalignment explicitly.
• Proposes a "rate 10 borderline summaries" exercise to surface stakeholders' actual priorities.

Hiring Manager's Keen Eye

• Asks diagnostic questions before offering a theory.
• Localizes the failure to a specific layer (retrieval, generation, source data) instead of saying "AI hallucinates."
• Offers a specific deliverable on a specific day, not vague reassurance.
• Owns the system instead of distancing from it.
• Addresses the trust question (should I pull the plug) alongside the technical one.

Weak-hire Answer

• Opens with "the AI hallucinated" before asking a single question.
• Suggests adding a disclaimer to all AI responses.
• Hand-waves confidence scores and guardrails, no specifics.
• Closes by managing expectations ("no AI is 100% accurate") instead of owning the fix.

Strong-hire Answer

• Asks pointed diagnostic questions first. Was the source data correct? Was it a lookup or a calculation? Can they pull the exact thread?
• Localizes to two concrete hypotheses (retrieval error vs. generation error) and says they need logs to tell which.
• Commits to a named deliverable on a named day ("one-page finding by Friday").
• Proposes an interim safety net (surface the raw source record alongside the AI answer) scoped to the investigation period.
• Owns the system. "A 10x error on a simple lookup is exactly what my test suite should catch."

Hiring Manager's Keen Eye

• Contains first, debugs second. The feature goes down before root-cause starts.
• Thinks in blast radius. "How many other queries leaked that I don't know about?"
• Identifies the correct failure layer: access control in retrieval, not a model or prompt problem.
• Knows who to notify and in what order (engineering, affected customer, legal).
• States concrete, testable reactivation criteria, not "once we've fixed it."

Weak-hire Answer

• Starts with "reproduce to confirm" instead of containment. The system stays live while they investigate.
• Never mentions notifying the exposed customer (Acme) or legal.
• Proposes a system-prompt instruction ("don't reveal other customers' pricing") as the fix.
• Turn-back-on criteria is "once the fix works on test queries." No blast-radius audit, no customer notification gate.

Strong-hire Answer

• Disables the feature immediately, investigates after.
• Audits retrieval logs for cross-tenant data leaks across the full deployment window, not just the one known case.
• Notifies Acme (the exposed party) and loops in legal for reportable-incident determination.
• Names the correct failure layer. The model answered correctly. The retrieval path should not have returned that data.
• Four concrete reactivation criteria: tenant filter at query level, cross-tenant test suite on every deploy, blast-radius audit complete, affected customers notified and not blocking.

What the hiring manager looks for

• Identifies that the request moves the system from scheduling into clinical advice, which changes the risk and the regulation that applies.
• Asks what problem the VP is trying to solve before refusing.
• Offers an alternative that solves the underlying problem within the boundary.
• Keeps the renewal conversation open without promising the original request.

Weak-hire answer

• Agrees to build it with a disclaimer added to every response.
• Refuses with "that's against policy" and offers nothing else.
• Treats it as a prompt-engineering task.

Strong-hire answer

• Asks what is driving the request: missed appointments, clinic capacity, or staff time spent on rescheduling.
• States plainly that deciding which appointments a patient can skip is a clinical decision, and that the assistant will not make it.
• Proposes an alternative inside the boundary: flag low-attendance patterns for clinical staff to review, or let patients request a reschedule that a clinician approves.
• Names who else must be involved (clinical leadership and compliance) and commits to a written proposal by a named date before the renewal.