The FDE CV: drop the framework list, state deployment results with a baseline

“Reduced deployment time from 6 weeks to 9 days.” The FDE CV guide from Aced (formerly Exponent) offers this line as a model, set against a generic phrase such as “improved efficiency”. Its advice is blunt: every bullet should end with a number.

It sounds like familiar CV advice. In fact it reveals how FDE recruiters read a résumé. They are not looking for the person who has touched the most tools. They are looking for someone who has put a system into operation at a customer site and can prove it made a difference.

Many developers, including plenty in Vietnam, still organise their CVs by stack: which project, Spring or FastAPI, Kafka or RabbitMQ. That works for the keyword filter on a backend role. Submitted for an FDE role, it hides exactly what the recruiter most needs to see.

Frameworks are the minimum requirement

Palantir’s posting for a Forward Deployed Software Engineer makes the priorities clear. Programming languages appear as a baseline requirement: strong coding skills and proficiency in languages such as Python, Java and C++.

The job description itself is about something else: working directly with customers and owning the execution of important projects from start to finish.

Palantir also lists Ownership as a value in its own right. It defines it as following a project from beginning to end and getting past every obstacle along the way. A list of frameworks cannot demonstrate that. It shows you have passed through those tools, not that you have carried any piece of work to completion.

Aced makes the same point: FDE recruiters put ownership and customer impact above pure technical complexity.

So the Skills section should include only role-relevant skills you can discuss credibly, not everything you have ever used.

Over-listing comes back to bite you in the interview, when the interviewer picks precisely the name you understand least.

Google’s formula still works

The FDE world did not invent this style. In 2015 Laszlo Bock, then head of people at Google, said in a Reddit AMA that every accomplishment should be written as “accomplished X, as measured by Y, by doing Z”. His general advice was to make the impact of your work clear.

Applied to FDE work, the three components become more specific. X is a change on the customer’s side: a faster process, fewer errors, or a decision made sooner. Y is the thing you personally built or led. Z is the number, and in FDE work it almost always has a before and an after.

Aced’s sample bullets follow this template. A line about a data pipeline says time to first insight fell from 3 months to 3 weeks. Others measure the latency of a RAG system or the hours saved by a reusable toolkit. None of them opens with the name of a library.

Rewriting a bullet, step by step

Picture a developer at an outsourcing firm in Hanoi who has just finished a project for a logistics customer. His current bullet reads:

“Built a RAG system with LangChain, Pinecone, FastAPI.”

Three tool names, no customer, no result. Now run it through Bock’s formula. X: the customer support team looks up shipping policies faster. Y: he sat with that team to collect real questions, built the retrieval pipeline and integrated it into the tool they use every day.

Z: suppose each lookup used to take 4 minutes and, after deployment, takes 40 seconds, measured over the first 30 days in production. Put the three parts together and the new bullet reads:

“Reduced the customer support team’s shipping-policy lookup time from 4 minutes to 40 seconds per query (measured over the first 30 days in production) by collecting real questions from the team, building a retrieval pipeline and integrating it into the tool they use daily.”

Set the two lines side by side and the difference lies in the subject. The old line is about tools; the new one is about the customer’s operations team. The figures here, 4 minutes, 40 seconds and 30 days, are purely illustrative; real numbers must come from the logs, tickets or reports of your own project.

LangChain or Pinecone can still stay in the Skills section, provided you can explain why you chose them. They are simply no longer the heart of the line.

The numbers will be questioned

This is where many people go wrong: they assume that adding numbers automatically strengthens a CV. A number helps you get the interview, but once you are in the room it becomes a claim you must defend. Paraform, the recruiting platform, states plainly that a CV does not tell the truth about FDE readiness, so interviewers will dig into every number.

Imagine the interviewer reading the logistics bullet above and stopping at “4 minutes”. The first question is almost certain to be: where was the baseline measured? Next: who confirmed the post-deployment figure? And finally: of all this work, which part did you do yourself?

A model answer might go like this: “The baseline came from the support team’s ticketing tool logs for the two weeks before deployment.

The post-deployment figure came from the same log source over the first 30 days in production, and the customer’s team lead signed off the report. I built the retrieval pipeline and the integration myself; a colleague handled the interface.”

That answer holds up because it contains exactly three things: the measurement source, the time period and the person who confirmed it, plus a clear boundary around the candidate’s own work. Christian & Timbers, the executive search firm, asks for exactly this: the bigger the claim, the more it needs a starting baseline and a measurement period.

The firm sets the bar one step higher: an FDE’s technical work must lead to a production workflow with measurable results, and companies should look for people who have deployed agentic AI repeatedly, tied to documented financial outcomes. So the next question may well be: have you done this again at a second customer?

Arranging the hiring criteria in a table shows what each bullet must answer, both on paper and in the interview:

Recruiter	What they check	What the bullet needs	Be ready to answer in the interview
Palantir	End-to-end project ownership	Which part you owned, how far you took it	Which obstacles you overcame yourself
Aced	Customer impact over complexity	A number on every line	Every skill listed in the Skills section
Christian & Timbers	Production workflows, repeatable results	A system that went into operation, not just a demo	Starting baseline and measurement period
Paraform	The CV is a weak signal	A story you can retell in detail	What you did, and in what order

Those questions expose three common mistakes that make a polished bullet collapse in the interview.

Inflated percentages. “Increased efficiency by 300%” sounds impressive, but a single “300% of what?” exposes it. A small, honest number is far safer.

Claiming the team’s result as your own. If you stumble when asked which part you did yourself, the number loses its value. The ownership Palantir looks for means seeing your own work through, not putting your name on a shared achievement.

Numbers without a baseline. “Cut processing time by 70%” without saying from what, or over what period, cannot be verified, and the interviewer will treat the line as if it did not exist.

Where to start

A common obstacle for engineers at outsourcing firms is having no data because the customer keeps it all. The fix lies in the work itself: on your next project, record the baseline in the first week, such as how long the current process takes, how many errors occur, and how many manual steps are needed. Without a before, there will be no Z later.

When reading an FDE job description, look for phrases such as “end-to-end”, “working directly with customers” and “production”. When you see them, order your bullets by customer outcome, not by stack. If the description is nothing but framework names, it may be a backend role under another title.

Before sending your CV, reread every number and ask the three questions above: measured where, confirmed by whom, which part was yours. Drop any number that cannot answer all three, because FDE recruiters will keep asking until they get an answer.

The best FDE CVs read like a series of handover records: which customer, what changed, how it was measured. The stack is something the interviewer will ask about once they already want to hear more.