# From data scientist to FDE: keep the debugging mindset, learn to own the whole system

> Your model is already good enough. What is missing is everything that happens after it runs: the API, auth, monitoring, and a customer waiting for results.

Original: https://fdetimes.net/en/guides/data-scientist-to-forward-deployed-engineer/

Picture this. You finish training a churn prediction model: the AUC looks good, the notebook is tidy, and you hand it over to the platform team. Three weeks later the model is still sitting there, because nobody has connected it to the customer's login system.

As an FDE, the person who has to connect it is you. The good news is that this path is real: FDE Academy's career guidance names ML engineer as a viable route into Forward Deployed Engineering at AI companies.

A 2026 analysis of job postings on Cloud Authority also found that many FDE roles mention machine learning or agent development experience directly.

The harder news: according to Sundeep Teki's 2026 FDE interview guide, the interview loop tests four things at once that are usually assessed separately. They are problem decomposition, coding, customer empathy and ownership. Modelling skill is merely the price of entry. The real question is what to keep and what to learn.

## What you bring is worth more than you think

An ML foundation is a direct advantage, especially when AI companies need people who understand how models, pipelines and LLM applications are deployed and integrated. You know why a model degrades, what leakage looks like, how to read a data distribution. These are reflexes you already have, not things to learn from scratch.

The second thing worth keeping is the debugging mindset. FDE Academy's guide to moving from data engineer to FDE says plainly that debugging skills transfer. When you track down why a feature has suddenly gone all null, you are doing exactly what an FDE does when integrating with a broken customer system: form a hypothesis, narrow it down, verify.

But the same guide points to the core difference: data people usually work internally, while FDEs work directly with customers. The debugging mindset stays the same, but the number of systems you need to understand grows many times over.

## The gap is around the model, not in it

Cloud Authority, citing The Pragmatic Engineer, draws a neat distinction between the two roles. A developer builds one capability for many customers; an FDE goes deep with one customer across many capabilities. When you stand on a single customer's side like that, training the model becomes just one of many jobs you do yourself.

Palantir's Forward Deployed Software Engineer posting in Warsaw describes the work as being done in small teams, with little supervision, owning high-stakes projects end to end. The same posting asks for a strong coder, proficient in languages such as Python, Java and C++. Statistical skill does not substitute for that requirement.

## One ambiguous problem, layer by layer

Teki ranks problem decomposition as the most important skill in FDE interviews. The technical deep dive lasts about 60 minutes, involves no coding, and centres on a real-world problem stated very loosely. This is exactly where ML people tend to stumble, because their first reflex is usually to pick a model.

Take a hypothetical prompt: "A chain of clinics wants to use AI so patients wait less." A data scientist will want to jump straight into predicting wait times with gradient boosting. An FDE breaks the problem down in a different order:

```text
1. Users: who feels the wait? Patients, receptionists or doctors?
2. Decisions: who would act differently with better information? (receptionists rescheduling? the clinic adding shifts?)
3. Data: where do appointments, check-in times and consultation times live? Who is allowed to access them?
4. Constraints: medical data -> HIPAA, runs inside the customer's VPC,
   login via existing SSO
5. Week one: a dashboard of wait times by time slot, no model needed yet
6. Only then ML: hourly load forecasting to suggest scheduling
```

Note that the model appears in the last step. The fourth layer is no accident either: Teki notes that the FDE system design round is tied to each customer's circumstances, with topics such as VPC, SSO and HIPAA/SOC2.

If in an interview you can say that this data must not leave the customer's infrastructure, you are answering exactly the kind of question this system design round targets, rather than just sketching a model architecture.

**Key point:** In an FDE interview, the model is the answer to the sixth question, not the first.

## When a deployment breaks at 2am

Teki illustrates ownership with a very concrete scene: a deployment breaks at 2am, and you do not open a ticket. For someone used to handing models over to another team, this is the biggest shift in mindset.

Continuing the clinic example, imagine the forecasting endpoint suddenly returns a 401 error. The old reflex is to alert the platform team. The FDE reflex is to trace it yourself: has the SSO token just been rotated, does the service account still have read access to the appointments table? Once it is fixed, you write up the root cause and add an alert so it is caught earlier next time.

The debugging mindset is still yours; only now its scope is the whole system.

## A practice plan: algorithms, one real project, a new CV

First, algorithms. Teki describes the coding round as LeetCode medium but framed as a customer scenario, and some candidates report getting BFS and graph problems at Palantir. Notebooks do not build this reflex, so you need to solve problems regularly and practise thinking out loud.

Second, an end-to-end project. FDE Academy recommends building a project with cloud, an API, authentication, a database and monitoring. The fastest route for ML people is to take one of your own old models, wrap it in a service with login, log predictions to a database, and build a dashboard tracking latency and drift.

Adding a small RAG layer is also worthwhile, since Teki's skills list includes Python, LLM/RAG, cloud, SQL/pipelines and full-stack.

Third, your CV. According to Teki, the ability to ship end to end matters more than company names. For developers who have never worked at a big-name company, including many in Vietnam, this is good news: each line of experience should say what problem you solved for whom, what system you shipped, and how it performed in production.

When reading job descriptions, look for phrases such as "end-to-end", "customer-facing" and "minimal supervision" to tell whether a role needs exactly the skills you have just added.

## Familiar traps for ML people

The most common trap is opening your answer with the name of a model. The interviewer wants to hear you ask about the users and the decisions, not compare XGBoost with transformers.

The second trap is a portfolio made entirely of notebooks. Notebooks prove you analyse well, but not that you can deploy, authenticate users or monitor a system. The third is underrating the algorithms round because you "do AI". The coding round is still LeetCode medium, and Palantir's posting still asks for a strong coder.

The last trap is talking about accuracy instead of customer outcomes. The clinic is not buying AUC; it is buying mornings when patients wait less.

This week's exercise: pick a model you have worked on, write out the six layers of decomposition, as in the clinic example, for an imaginary customer, then ask yourself which layer you have never handled yourself. That layer is what to learn next.

**Try this week:**

- Take a model you have trained, wrap it in an authenticated API that writes to a database with a minimal monitoring dashboard, then deploy it to the cloud.
- Solve one LeetCode medium graph or BFS problem a day, and rewrite the problem statement as a real customer scenario.
- Rewrite three lines of experience on your CV using the formula: the user's problem, the system you shipped, the result once it ran in production.

## Sources

- [The Definitive Guide to Forward Deployed Engineer Interviews in 2026](https://www.sundeepteki.org/advice/the-definitive-guide-to-forward-deployed-engineer-interviews-in-2026)

- [How to Become a Forward Deployed Engineer: Career Paths, Required Experience and Training Options](https://fde.academy/blog/how-to-become-a-forward-deployed-engineer)

- [Data Engineer to Forward Deployed Engineer: Skills, Gaps, and Transition Guide](https://fde.academy/blog/data-engineer-to-forward-deployed-engineer)

- [Forward Deployed Software Engineer (Palantir, Warsaw)](https://jobs.lever.co/palantir/bf718bd3-b2ef-451e-8033-cb4d2d9c094b)

- [The Rise of the Forward Deployed Engineer: History, Myths, and Why It's Back](https://cloud-authority.com/the-rise-of-the-forward-deployed-engineer-history-myths-and-why-it-s-back.md)