Forward Deployed Engineer at Baseten: what the job ad asks for and how to prepare

You are reading Baseten’s job ad for a Forward Deployed Engineer and come across an odd line: the candidate must be an engineer, a project manager and a product manager all at once. The easy reflex is to fill your CV with phrases like “strong communicator” and “customer-facing experience”. That misses the point.

Baseten is very clear about where this role sits. According to a post about the FDE team on the company’s blog, FDEs sit in the engineering organisation and contribute to the product regularly. The job ad for an engineering manager on the team goes further: FDE at Baseten is not a sales function.

So preparing for this role is not about polishing your presentation skills. You need to prove you are an engineer who can take a hazy business goal and hand back a service that runs in production, is measurable, and is general enough for the company to turn into a feature.

What is the job ad really testing?

The team’s mission, in Baseten’s own words, has two halves: help customers see real value early, and build products and tools that push the Baseten platform further. The second half is what separates an FDE here from an ordinary integration engineer.

The most concrete number sits in the team’s long-term goal: 70% of what is built in FDE should be integrated into the product. In day-to-day terms, if you write a latency benchmark script for customer A, the team will want that script to work later for customers B and C, and eventually to become a tool in the product.

The first hiring criterion the blog lists is an exceptionally strong software engineering foundation. The post argues that empathy and communication can be trained in a technically strong engineer. The sensible reading: the technical part is what you have to bring with you.

The second criterion, also from the blog, is curiosity at every layer of the stack, from ML down to infrastructure and networking.

The listing on Built In adds more specifics: writing production-quality code in a general-purpose language, and familiarity with AI/ML pipelines and the model development and deployment lifecycle.

The US version asks for at least two years of experience in a fast-growing environment; the London (EMEA) version asks for at least one. The door is not closed to early-career engineers, provided the application proves the right things.

From “faster, cheaper” to a spec with numbers

If you read only one line of the job ad closely, make it this one: FDEs work directly with customers, turning ambiguous business goals into reliable, observable services with clear outcomes on quality, latency and cost.

The responsibilities section lays out the whole process: from ambiguous goals to clear specs and tightly scoped PoCs, then on to deployment. FDEs are also brought in at the earliest stage of the customer journey, which means you usually receive a request when it is at its vaguest.

Picture a hypothetical case. A customer support company using an LLM to summarise tickets tells you: “The system is too slow, and the bill is too high.” That is not yet a technical requirement. Your first job is to break it down along the three axes the job ad names.

Axis	Discovery question	Metric for the spec (hypothetical example)
Quality	“What does a good summary look like? Who is grading it?”	A set of 200 tickets with reference summaries; score no lower than the current system
Latency	“Which screen are users waiting on? How long before they give up?”	p95 below a threshold agreed with the customer, measured at peak-hour traffic
Cost	“Is the budget per request or per month?”	Cost per 1,000 requests, compared with the current level

Once you have this table, the PoC becomes clear: try a smaller model or a different serving configuration, run it on the same 200 tickets, and report three numbers. If quality drops, you have evidence to take back to the customer and negotiate, rather than arguing on gut feeling.

This is also where the project manager and product manager roles come in. You decide the order of experiments, agree with the customer what “done” means, and ask yourself which parts of the work should become shared tools. The script that runs the eval on 200 tickets, if parameterised from the start, is a prime candidate for that 70%.

How to prepare in a few weeks

Start with Baseten’s own tooling. Truss is an open-source CLI for deploying and serving ML models on Baseten. A small project with it gives you two things at once: an understanding of the model lifecycle the way the company does it, and something concrete to talk about in interviews.

A good portfolio project should repeat the exercise above. Pick a real problem, write a one-page spec covering the three axes, package and deploy a model with Truss, measure latency at several load levels, estimate cost, then write a README explaining the trade-offs you made.

The README should end with a paragraph on which parts you would extract into a reusable tool if this were work for a real customer.

Do not skip the lower layers: Baseten’s blog explicitly mentions infrastructure and networking. Imagine a slow endpoint: the culprit could be the model, a cold start, the infrastructure configuration or the network path. Train yourself to ask “where is it slow?” and measure each hop instead of guessing.

Four CV lines that send an application off course

Each bullet on your CV should follow a pattern: the vague initial request, the metrics you agreed, the measured result, and what became shared. The four mistakes below all stray from that pattern, each with a rewrite (all examples are hypothetical).

The most common mistake is positioning yourself as presales, a role Baseten has made clear its FDEs are not. Weak line: “Demoed the product to prospective customers and supported the sales team in closing deals.” Rewrite: “Built a text summarisation PoC for a customer, wrote a spec with latency and per-request cost thresholds, then took the service to production.”

The second is knowing only one layer, when the criterion is curiosity at every layer of the stack. Weak line: “Fine-tuned a text classification model to high accuracy.” Rewrite: “Fine-tuned a classification model, packaged and deployed it as an endpoint myself, measured latency at each hop and identified cold start as the cause of slowness.”

The third is harder to spot: describing a “successful” PoC without a single number. Weak line: “Built a successful chatbot PoC; the customer was satisfied.” Rewrite: “Built a chatbot PoC, reporting quality scores on a sample ticket set, p95 latency and cost per 1,000 requests against the old system.”

The last is describing one-off work for a single customer and stopping there, when the team aims for 70% of what FDEs build to go into the product.

Weak line: “Wrote a benchmark script for customer A’s project.” Rewrite: “Turned an internal team’s ‘cut costs’ request into a spec with latency and per-request cost thresholds, then packaged the measurement tool as a library for three other teams.”

Put the four rewrites next to the job ad and you will see they answer exactly the question Baseten is asking: can this engineer turn a vague goal into a measured service, and leave something behind for the product?