AI / Forward Deployed Engineer (FDE) Interview questions

A Forward Deployed Engineer is a software engineer who works directly with customers, often inside their environment, to turn a product into a working solution for that customer's real problem. "Forward" means you sit close to the customer instead of behind the product team.

You write code, configure integrations and ship working systems, but you also run discovery, present to stakeholders and carry customer feedback back to product.

Think of it as part engineer, part consultant and part product manager, all focused on one deployment at a time.

The work shifts between customer-facing and hands-on engineering. A typical week mixes the following:

1. Meeting users and stakeholders to understand the workflow that needs fixing.
2. Pulling data from the customer's systems and cleaning it so the product can use it.
3. Building integrations, dashboards, agents or workflows on top of the platform.
4. Testing with real users, fixing what breaks and documenting what you shipped.
5. Writing up customer feedback and feature gaps for the product team.

The ratio of coding to meetings depends on the company, but a pure heads-down coding week is rare.

The role was popularized by Palantir, whose early engineers were embedded with government and enterprise customers to get complex data platforms working on messy real-world data. Internally these engineers were called Deltas.

The model worked because the product alone was never enough. Someone had to connect it to legacy systems, understand the customer's mission and adapt it on site.

Since then, AI labs, data platforms and enterprise software companies have adopted similar roles, sometimes under names like Customer Engineer or Applied AI Engineer, with the same embedded, outcome-driven approach.

An FDE needs a mix of engineering depth and customer-facing judgment. Missing either side makes the job hard.

Comfort with ambiguity matters more than knowing any single tool.

The purpose is to close the gap between what the product does out of the box and what the customer needs to get value from it. The FDE owns that gap until the customer is running the solution in production.

That means integrating with existing systems, adapting workflows, training users and making sure success is measured against something the customer cares about, not just a feature checklist.

A second purpose, easy to forget, is feeding what you learn back to product so the next customer needs less custom work.

A proof of concept is a small, time-boxed build that shows the product can solve one specific customer problem on a slice of real data. It answers one question: "does this approach work here?"

Good POCs have a narrow scope, a clear success criterion agreed in advance, and a fixed end date, typically two to six weeks.

A POC is not production software. It usually skips hardening, full security review and scale testing, which is why teams must plan the jump from POC to pilot deliberately.

A statement of work is the document that defines what will be delivered, by when, for how much, and what the customer must provide in return. FDEs read it closely because it sets the boundaries of the engagement.

It usually covers scope, deliverables, timeline, assumptions, acceptance criteria and responsibilities on both sides.

When a customer asks for something new mid-project, the SOW is the reference for deciding whether it is in scope or needs a change request.

Time-to-value is how long it takes from kickoff until the customer gets a measurable benefit from the product, such as hours saved or errors reduced. It is one of the best signals of whether a deployment is going well.

FDEs shorten it by starting with a narrow, high-impact use case, getting data access early and shipping something usable in weeks rather than months.

A long time-to-value usually points to blocked data access, unclear ownership or too much scope at the start.

A stakeholder map lists everyone who can influence or is affected by the project, with their role, interests and level of support. It usually sits on a simple grid of influence versus interest.

FDEs use it to find the champion who wants the project to succeed, the economic buyer who controls budget, the end users who decide adoption, and the blockers such as security or IT who can stall it.

Knowing who needs what, and when, prevents late surprises like a security team first hearing about the project a week before launch.

Which pattern fits depends on how fresh the data must be and what the customer's systems allow.

In practice many deployments start with file drops or batch pulls because they ask the least of the customer's IT team.

Start by reading the customer's API docs and getting a sandbox key. Then confirm authentication, rate limits and pagination before writing any real logic.

A basic client should handle pagination, retries on transient errors and timeouts:

import requests, time

def fetch_all(url, token):
    items, page = [], 1
    while True:
        r = requests.get(url, params={"page": page},
                         headers={"Authorization": f"Bearer {token}"},
                         timeout=30)
        if r.status_code == 429:
            time.sleep(int(r.headers.get("Retry-After", 5)))
            continue
        r.raise_for_status()
        data = r.json()
        if not data["results"]:
            return items
        items.extend(data["results"])
        page += 1

Log every failure with the request ID so the customer's team can trace it on their side.

Single sign-on (SSO) lets users log in once through the company's identity provider, such as Okta or Entra ID, and access many apps without separate passwords. The common protocols are SAML and OpenID Connect.

Enterprises require it because IT can enforce MFA centrally, disable access in one place when someone leaves, and audit logins across all tools.

For an FDE this often becomes a gating item. A deployment without SSO frequently cannot pass security review, so it should be planned early.

Role-based access control (RBAC) grants permissions to roles, not to individual users. Users are then assigned a role such as Viewer, Analyst or Admin and inherit its permissions.

It keeps access manageable at scale. When someone changes teams you change their role instead of editing dozens of individual permissions.

In deployments, RBAC matters because customers often have strict rules about who can see sensitive records, like HR or finance data, and the FDE has to map those rules onto the product's roles.

A service level agreement is a written commitment about service quality, such as uptime, response time to incidents and resolution targets. It often includes remedies, such as credits, if the commitment is missed.

For example, 99.9% monthly uptime allows roughly 43 minutes of downtime a month.

FDEs need to know the SLA because it defines how fast they must respond when something breaks in production, and it shapes what they can promise in meetings.

A runbook is a step-by-step guide for operating and troubleshooting a system. It covers routine tasks like restarting a job and known failures like an expired credential, with exact commands and who to contact.

FDEs write them because the customer's team will own the system after handover. If the knowledge stays in your head, the deployment breaks the first time you are unavailable.

A useful runbook states symptoms, likely causes, the fix, how to verify the fix, and when to escalate.

Retrieval-augmented generation (RAG) gives a language model relevant documents at question time instead of relying only on what it learned in training. The system searches the customer's content, picks the best passages and includes them in the prompt.

FDEs favor it because customer knowledge is private, changes often and cannot be baked into a model cheaply. Updating a document index is far easier than retraining.

It also makes answers traceable, since the system can cite the source passages it used.

Evals are repeatable tests that measure how well an LLM-based system performs on tasks that matter to the customer. Each case has an input and either an expected answer or a scoring rubric.

They let you compare prompt changes, models or retrieval settings with numbers instead of gut feeling. They also catch regressions when something is updated.

The best eval sets come from real customer examples, including tricky edge cases, reviewed by someone who knows the domain.

A change request is a formal way to add, remove or alter something that was not in the agreed scope. It records what is changing, the effort involved and the impact on timeline or cost, and it needs approval from both sides.

It protects the project from quiet scope growth. Without it, "can you also add one small thing" repeated ten times pushes the deadline out with nobody having decided to.

An FDE usually estimates the effort, explains the trade-off and lets the customer choose between adding it, swapping it for something else or deferring it.

A solutions engineer usually works before the sale, running demos and technical evaluations. An FDE works after or alongside the sale, building and running the real deployment.

Some companies blur the two titles, so always check what the job description actually asks you to build.

Both work closely with clients, but an FDE builds on a product the company owns, while a consultant typically delivers advice or bespoke work using whatever tools fit.

That has two effects. FDEs have a stake in improving the product, since lessons from each deployment go back into it. They are also expected to write real code, not just slides.

A consultant's output often ends at a recommendation or a report. An FDE's output is a running system that the customer uses.

They are three stages of increasing commitment, and mixing them up is a common cause of failed projects.

The jump from pilot to production is where most effort hides: hardening, access controls, monitoring, training and support ownership.

Start by asking what outcome the customer wants, not what feature they asked for. "We need a dashboard" often means "we cannot see which orders are late."

1. Write the problem as one sentence with a measurable result.
2. Find the smallest slice that proves value, usually one team or one workflow.
3. List assumptions and unknowns, especially data access.
4. Agree on what is explicitly out of scope.
5. Confirm the plan in writing and get a named decision-maker to sign off.

If the scope still feels fuzzy, run a short discovery sprint before committing to a delivery date.

Go in with questions, not a pitch. Your goal is to understand how work happens today, where it hurts and what a good result looks like.

Useful questions are concrete: "Walk me through the last time this went wrong," "Which spreadsheet do you rely on?" and "Who else touches this process?" Ask users, not just managers, since they know the workarounds.

Close by playing back what you heard and naming the next steps with owners and dates. Send a written summary the same day so misunderstandings surface early.

Anchor on the outcome the customer signed up for. Each request gets measured against how much it moves that outcome and how much effort it takes.

A simple impact versus effort grid is enough. Do high-impact, low-effort items first, schedule high-impact, high-effort items deliberately, and push back on low-impact requests.

When two stakeholders disagree, don't pick a winner yourself. Put the trade-off in front of the project sponsor and let them decide. That keeps you neutral and the decision visible.

Build custom when the need is unique to one customer, urgent, or still unproven. Push it into the product when you've seen it from multiple customers or it clearly belongs in the core platform.

A useful rule is the "rule of three": if you build the same thing for a third customer, it probably deserves product investment.

Custom code has a hidden cost. You own it, you maintain it, and it can block upgrades. Keep it isolated behind clear interfaces so it can be replaced when the product catches up.

Don't say "no" first. Ask what problem the feature is meant to solve, because there is often another way to reach the same outcome.

If it truly can't be done soon, be direct and give the reason: it conflicts with the product direction, it affects other customers or the effort is too high for now. Then offer an alternative, such as a workaround, a custom build with clear ownership, or a place in the product feedback queue.

Never promise roadmap dates you don't control. Customers remember a broken promise much longer than an honest no.

First profile it. Count nulls, check formats, look for duplicates and find out which fields are actually trusted. Most surprises show up in the first hour of profiling.

Then agree rules with the customer for each issue, such as which record wins in a duplicate, how to treat missing values and how to standardize dates and names. Write those rules down.

Build cleaning as a repeatable pipeline, not a one-time script, and keep a log of rejected rows so the customer can fix problems at the source. Never silently drop or guess values.

Because the data usually sits in systems owned by people outside the project. Getting access means finding the owner, passing a security review, setting up credentials and sometimes opening network paths, and each step has its own queue.

Teams often underestimate this and plan the build first. The result is an engineer waiting three weeks for a database login.

The fix is to request access on day one, ask for a small sample while the full approval runs, and name an owner on the customer side who can chase it.

You often can't log in to their servers, so you need evidence you can collect safely. Start by reproducing the failure with the smallest request possible and capturing the exact error, timestamp and request ID.

Work from the outside in:

1. Check connectivity: DNS, firewall rules and allow-listed IPs.
2. Check authentication: expired tokens, wrong scopes, clock drift.
3. Check payloads: schema changes, encoding, unexpected nulls.

Add verbose logging on your side and ask the customer's admin to share the matching logs, redacting sensitive fields. A screen-share where they run the commands often saves days of back and forth.

In an air-gapped site there is no internet, so everything must be carried in and verified: container images, packages, models and documentation. Plan for it from the start.

Typical steps are building a versioned offline bundle, scanning it for vulnerabilities, transferring it through the customer's approved media process and installing it from an internal registry.

Updates are slow and manual, so keep releases infrequent and well tested. Logs and metrics stay inside the network too, which means you may need to debug through screen shares or exported log files rather than live access.

A security review decides whether your solution is allowed to run at all, so it directly controls your timeline. The customer's team typically asks for architecture diagrams, data flow descriptions, a security questionnaire and evidence like penetration test summaries or SOC 2 reports.

It can change the design. They may require data to stay in a region, forbid outbound calls, demand SSO and encryption settings or limit what a service account can read.

Start the review early, give them clear diagrams and answer questions quickly. Treat the reviewers as partners, since they often become your best internal advocates once they trust the design.

Begin by finding out what data is actually in scope. Often you can avoid touching personal data at all by masking, hashing or removing fields before they reach your system.

When you must handle it, apply the basics: collect the minimum, encrypt in transit and at rest, restrict access by role and keep audit logs. Confirm where the data is stored, since GDPR limits transfers outside certain regions and HIPAA requires a business associate agreement for health data.

Check with your legal and security teams before promising anything, and never copy production PII to a laptop for convenience.

Rarely because the technology failed. The common causes are organizational.

• No clear success metric, so nobody can say the pilot worked.
• No budget owner once the pilot ends.
• Weak adoption, since users kept using their old tools.
• Hidden production work like security review, integration and support that nobody planned for.
• A champion who left or lost interest.

Prevent this by agreeing on success criteria and the production path at the start, tracking usage weekly and keeping the executive sponsor informed with real numbers.

Skepticism usually comes from past tools that added work. Show up, listen and fix a small annoyance for them first.

Sit with users while they do their real work, ask what slows them down and ship a quick improvement within days. Visible early wins do more than any presentation.

Be honest about limits. If the system is wrong sometimes, say so and show how to spot and correct errors. Collect feedback in a simple channel, respond fast and credit users when their suggestions ship.

Pilots invite scope creep because everyone suddenly sees what could be added. The defense is a written scope and a visible backlog.

When a new ask arrives, log it, estimate it and ask the sponsor whether it replaces something or moves the end date. Keep a "parking lot" list for good ideas that come after the pilot succeeds.

Review the scope against the success metric every week. If a request doesn't help prove the pilot's goal, defer it politely and say when it will be reconsidered.

Tell them early, as soon as you know. A delay announced two weeks ahead is a problem. A delay announced on the due date is a breach of trust.

Keep the message short and structured: what is late, why, the new date, what you are doing to protect it and what you need from them, if anything. Own the cause even if part of it was theirs.

Follow with a call for important projects, so they can ask questions. Then hit the new date. A revised date you meet rebuilds credibility faster than any apology.

Most engagements follow the same arc, though the length varies. Each phase ends with a clear decision before the next begins.

flowchart LR
    A[Discovery] --> B["Scoping and SOW"]
    B --> C["Data access and setup"]
    C --> D["Build POC"]
    D --> E["Pilot with real users"]
    E --> F{Success metric met?}
    F -- Yes --> G["Production rollout"]
    F -- No --> D
    G --> H["Handover and runbook"]
    H --> I["Feedback to product"]

Discovery and scoping pin down the problem. Data access often takes longer than expected. The POC and pilot loop continues until the agreed metric is met. After rollout, the FDE hands over with documentation and passes learnings to product.

A RAG system has an offline indexing path and an online query path.

sequenceDiagram
    participant U as User
    participant A as App
    participant V as Vector Index
    participant L as LLM
    Note over A,V: Offline: chunk docs, embed, store
    U->>A: Ask question
    A->>V: Embed query and search
    V-->>A: Top matching chunks
    A->>L: Prompt with question and chunks
    L-->>A: Grounded answer with citations
    A-->>U: Answer

1. Ingest: split documents into chunks, embed each chunk and store it with metadata.
2. Retrieve: embed the user's question and fetch the closest chunks, often re-ranked.
3. Generate: pass the chunks and question to the model with instructions to answer only from them.
4. Return: show the answer with citations.

Most quality problems come from the retrieve step, so inspect which chunks were returned before blaming the model.

Build an eval set from real customer examples, around 50 to 200 cases to start, with expected answers or clear grading rubrics. Include normal cases, edge cases and questions the system should refuse.

Score it three ways:

1. Automatic checks for format, required fields and exact facts.
2. LLM-as-judge for tone and completeness, spot-checked by humans.
3. Domain expert review of a sample, since only they catch subtle errors.

Agree on a pass threshold with the customer before you run it, such as 90% correct on critical questions. After go-live, keep sampling real traffic so quality is monitored, not assumed.

You can't eliminate them, but you can cut them sharply by constraining what the model is allowed to say.

• Ground the answer with retrieved documents and tell the model to use only that context.
• Require citations and verify that the cited passage really supports the claim.
• Allow "I don't know" in the prompt and test that it is used.
• Use structured outputs for fields that must match known values.
• Add guardrails that check numbers or entities against the source system.

Measure the rate on your eval set after each change. If you can't measure it, you can't claim it improved.

Pick RAG when the problem is missing or changing knowledge. Pick fine-tuning when the problem is behavior, such as a fixed output format, a specific tone, domain terminology or a classification task with many labeled examples.

They aren't exclusive. Many production systems use a fine-tuned model for behavior plus RAG for facts. Try prompting and RAG first, since they're faster and cheaper to iterate on.

Legacy ERPs rarely offer clean APIs, so protect both their stability and your data quality.

flowchart LR
    A["Legacy ERP"] --> B["Nightly export or read replica"]
    B --> C["Landing zone raw files"]
    C --> D["Validate and clean"]
    D --> E["Transform to target schema"]
    E --> F["Product data store"]
    D --> G["Rejected rows report"]

Never query the live ERP database directly during business hours. Use a nightly export, a read replica or change data capture. Land raw data untouched first so you can replay it, then validate, transform and load.

Make loads idempotent using stable keys, so a rerun after failure doesn't create duplicates. Send the rejected-rows report to the data owner, and alert when row counts deviate sharply from the previous run.

Pick metrics with the customer before you build, and tie them to a business outcome, not a technical one. "The model is 92% accurate" matters less than "analysts close tickets 30% faster."

Use three layers:

1. Adoption: weekly active users, share of target team using it.
2. Quality: accuracy, error rates, escalations.
3. Business impact: hours saved, cost reduced, revenue or risk improved.

Capture a baseline before launch. Without the "before" number you can't prove the improvement, and executives will ask for exactly that during renewal.

Start by checking that the need is real beyond one customer. Talk to the product manager and look for the same request elsewhere.

Then refactor in steps:

1. Strip out customer names, hard-coded IDs and credentials.
2. Move customer-specific values into configuration.
3. Define a clean interface and add tests that don't depend on the customer's data.
4. Write short docs and a migration path for the original customer.

Hand over a working prototype and a written use case to product, not just code. Product teams adopt ideas faster when the problem, evidence and customer impact are clear.

Stabilize first, investigate second. The customer cares about getting back to normal, not about the root cause yet.

1. Acknowledge quickly and name one person who owns communication.
2. Contain the impact: roll back, disable the failing feature or switch to a fallback.
3. Update the customer on a fixed schedule, even if the update is "no change."
4. Fix and verify with the customer's team.
5. Review: write a blameless post-incident report with cause, timeline and prevention steps.

Honest, regular updates keep trust intact during an outage, and a clear postmortem often strengthens it.

Measure before changing anything. Find out where the time goes: network, database, your code or a downstream service.

1. Define slow: which action, how long, how often, since when.
2. Check what changed recently, like data volume, a release or a config update.
3. Trace a slow request end to end with timing at each hop.
4. Look at the usual suspects: missing database indexes, N+1 queries, large payloads, unbounded loops, cold caches and rate limits.
5. Fix the biggest contributor, re-measure and repeat.

Changing several things at once makes it impossible to know what helped.

Security policy wins, but the conversation shouldn't end at "no." Find the risk the policy is guarding against and offer another way to meet the customer's goal.

For example, if the customer wants to email raw data extracts, you might propose a secure transfer folder with access logging that gives the same convenience with less risk.

If no alternative works, escalate to your security lead and the customer's sponsor together and document the decision. If an exception is granted, it needs a named approver, an expiry date and compensating controls. Never work around the policy quietly.

Run old and new side by side for a period instead of switching in one night.

1. Migrate data in bulk, then keep it in sync with incremental changes.
2. Shadow run: send real traffic to both systems and compare outputs without exposing the new one.
3. Canary: move a small share of users, watch error rates and widen gradually.
4. Cut over in a quiet window with a tested rollback plan.
5. Keep the old system read-only for a defined period before decommissioning.

Agree on go and no-go criteria with the customer in advance, so the call in the moment is based on numbers, not nerves.

Assume there is a reason before assuming bad intent. Blockers are usually protecting something: security, workload, reputation or budget.

Meet them one on one and ask what worries them. Often a small change, like an extra access control or a phased rollout, resolves it. Involve them early in design so they feel ownership instead of surprise.

If they still block without a valid concern, bring it to your champion or sponsor with facts: impact on the timeline and business goals. Escalate calmly and never go around them behind their back.

Neither wins every time. It depends on the customer, the data and the stage of the project.

Onsite works best at kickoff, during discovery and around go-live, and where data is restricted to the customer's network. Remote works for steady build phases. Many teams use a hybrid: onsite for key moments, remote for the rest.