Forward Deployed Engineer Interview Guide

The first thing to know about FDE interviews is that there is no single FDE interview.

“Forward Deployed Engineer” is now used for several fairly different jobs. Some companies want engineers who can build production AI agents. Some want strong full-stack engineers who can sit with customers, integrate messy systems, and ship quickly. Others use FDE for highly technical infrastructure work around inference, data, or developer platforms.

If you prepare for the wrong version of the role, you can spend a lot of time studying the wrong things.

I find it useful to divide FDE roles into three broad types.

Type 1: AI application and agent-heavy FDE

This is the category that has grown the fastest with the rise of generative AI.

The job is usually not about training foundation models. It is about building applications around them and making those applications work reliably for real customers.

Typical work might include:

• RAG
• agents and tool calling
• structured outputs
• evals
• tracing and observability
• prompt and context design
• guardrails
• production debugging

Imagine a customer wants an internal support agent that can answer questions, look up account information, and take certain actions.

The prototype is easy.

The real work starts after that.

What information should the model receive? Which tools should it have access to? Which actions need approval? How do you know whether it chose the correct tool? What happens when retrieval gives bad context? How do you debug an incorrect answer that came after four tool calls?

That is the kind of problem this FDE works on.

What companies usually look for

You should be able to build normal software, but you also need to understand the behavior of LLM systems in production.

The important topics are not just “RAG” or “agents” as concepts. You should be able to reason about:

• why a system failed
• what you would measure
• what you would trace
• what should be deterministic instead of left to the model
• how you would reduce the blast radius of bad model behavior

A strong project for this category is a real AI workflow that has users, tools, state, failure handling, evals, and observability.

A chatbot with one model call is usually not enough to give you much to talk about.

Type 2: Integration and deployment-heavy FDE

This is closer to the original idea of forward-deployed engineering.

You work closely with a customer, understand what they are trying to accomplish, and then build the software required to make it happen inside their environment.

The customer may already have a CRM, billing system, data warehouse, internal APIs, identity provider, and a collection of processes held together by spreadsheets and manual work.

Your job is not to redesign the entire company.

Your job is to make your product work inside that reality.

Typical work includes:

• APIs
• webhooks
• authentication
• data transformation
• customer-specific workflows
• backend or full-stack development
• rapid prototypes
• production deployment
• debugging integrations

Suppose a customer wants records from Salesforce to create corresponding objects in your product.

That sounds simple until you start asking real questions.

What is the source of truth? How do you map records between systems? What if Salesforce sends the same webhook twice? What if your API succeeds but Salesforce times out before receiving the response? What happens when one system is down for two hours?

Those details are the job.

What companies usually look for

This type of FDE rewards engineers who can move comfortably between a customer conversation and an implementation.

You need enough system design knowledge to handle distributed state and failures, but you also need practical judgment.

A complicated architecture is not automatically better.

Often the strongest answer is the simplest system that handles the important failure cases and can be shipped quickly.

For this category, I would prepare heavily around:

• APIs and HTTP
• webhooks
• retries
• idempotency
• queues
• authentication
• data modeling
• external IDs
• reconciliation
• observability

And I would practice turning vague customer requests into concrete requirements.

Type 3: Platform and infrastructure-heavy FDE

The third category sits much closer to backend, infrastructure, or ML systems engineering.

These roles are common at companies selling infrastructure products: model serving, AI gateways, data platforms, vector systems, observability tools, databases, or developer infrastructure.

The customer may still be central to the job, but the technical problems are lower in the stack.

Typical work might involve:

• inference
• model routing
• distributed systems
• data pipelines
• concurrency
• caching
• observability
• throughput
• latency
• reliability
• cost optimization

A customer might have several models running across different providers and want lower latency and better reliability.

Now the conversation is less about prompt design and more about routing, fallback behavior, caching, throughput, failure handling, and cost.

What companies usually look for

For these roles, traditional backend and system design preparation matters much more.

You should be comfortable reasoning about:

• scale
• queues
• storage
• concurrency
• caching
• consistency
• load
• failure domains
• latency
• reliability

You may still get customer-facing scenarios, but the technical bar is often deeper than in a typical application FDE role.

Most FDE roles are hybrids

The categories are not clean boxes.

A lot of current FDE roles are somewhere between Type 1 and Type 2.

For example, you might build an AI agent, connect it to the customer's CRM and internal APIs, deploy it into their environment, and then monitor how it performs.

That requires both AI application knowledge and normal integration engineering.

Other roles combine Type 2 and Type 3: you work closely with enterprise customers, but the product itself is infrastructure-heavy.

The point of the classification is not to perfectly label the job.

It is to answer one question:

Where will this interview go deep?

That should determine how you prepare.

How to identify the type from the job description

The easiest signal is the language in the JD.

If you repeatedly see:

agents, RAG, evals, LLM workflows, tool calling, prompt engineering

the role probably leans toward Type 1.

If you see:

customer deployment, integrations, implementation, APIs, prototyping, solutions

it probably leans toward Type 2.

If you see:

inference, infrastructure, distributed systems, serving, performance, throughput

it probably leans toward Type 3.

Also look at what the company actually sells.

An FDE at an AI application company and an FDE at a model-serving infrastructure company may have the same title but completely different interviews.

Once you know which type you are interviewing for, the rest of the preparation becomes much easier.

What does an FDE actually do?

At a high level, an FDE is still a software engineer.

The difference is that you are usually closer to the problem and closer to the customer.

Instead of receiving a fully defined requirement, you may start with:

“We want to automate this workflow.”

You then have to figure out what that actually means, what systems are involved, what should be built first, and how to get it into production.

That is why FDE interviews tend to test more than coding.

They want evidence that you can deal with ambiguity, build quickly, make reasonable trade-offs, and stay involved after the first version ships.

What the interview loop usually looks like

Companies organize the loop differently, but most interviews cover some version of:

• coding
• system design
• AI or technical depth
• customer problem solving
• project deep dive or behavioral

The weighting depends heavily on the type of FDE role.

Coding

Some companies use a normal SWE coding round.

Others use more practical tasks: APIs, data transformation, SQL, debugging, or building a small service.

I would still practice basic algorithms, but for FDE roles I would also make sure I can comfortably work with JSON, HTTP, APIs, SQL, and async workflows.

Practice FDE coding →

System design

FDE system design often starts from a real workflow rather than a generic product.

You may be asked to sync two systems, automate a support process, or build something around a customer's existing data.

The important habit is to understand the workflow before designing the architecture.

For Type 2 roles, expect more integration and failure-handling questions.

For Type 3 roles, expect deeper distributed systems questions.

Practice FDE system design →

AI and GenAI

This matters most for Type 1 roles.

You should understand when to use direct generation, RAG, tools, or an agent, and be able to talk about evals, observability, failure modes, and guardrails.

The interview is usually more interested in whether you can operate an AI system than whether you know the newest framework.

Learn GenAI architecture →

Customer case

A customer case usually begins with an intentionally vague request.

For example:

“We want to automate support with AI.”

Do not jump straight into architecture.

Ask who the users are, what they do today, what is expensive or slow, what data exists, what is safe to automate, and what success would look like.

The goal is to show that you can find the real problem behind the initial request.

Practice customer-facing cases →

Project deep dive and behavioral

Prepare two or three projects you know very well.

You should be able to explain what was unclear, what you personally owned, why you made certain decisions, what went wrong, how the system reached production, and how you knew it worked.

Common questions include:

Tell me about something you built end to end.

Tell me about a vague ask you turned into a working solution.

What did you get wrong the first time?

Tell me about a production issue you had to debug.

FDE interviewers care a lot about ownership because the job often gives you less structure than a normal product engineering role.

Build your behavioral story bank →

What should you build to prepare?

If you are targeting Type 1, build one real AI workflow rather than several demos.

Give it real tools, persistence, error handling, traces, and a small evaluation set.

If you are targeting Type 2, build an integration between real systems. Handle webhooks, retries, duplicate events, failures, and reconciliation.

If you are targeting Type 3, build something that forces you to reason about infrastructure: concurrency, queues, caching, throughput, or reliability.

The project does not need to be huge.

It needs to give you real engineering decisions to talk about.

How I would prepare

I would split preparation into four areas:

Coding — enough algorithms to pass a normal screen, plus practical API and data work.

System design — core system design, with extra attention to integrations and failure modes.

Role-specific depth — AI systems for Type 1, deployment and integrations for Type 2, infrastructure for Type 3.

Project stories — two or three examples that show ownership, ambiguity, production work, and measurable outcomes.

The most important step comes before all of that:

figure out which FDE the company is actually hiring.

Once you know that, the preparation becomes much more focused.