Two sentences on a project for an FDE application: production, not a demo

The application form has a small box labelled “Describe a representative project”. You type “Built an app using Python and React”, decide it looks thin, add a few more technology names and press submit. For a Forward Deployed Engineer role, that sentence tells recruiters almost nothing they are looking for.

Your project may be very good, but the sentence does not show it. FDE Academy, in its CV guide for FDEs, argues that reviewers look for evidence that you have owned deployments and think in terms of business outcomes, not just technical breadth.

Its example of a “strong” sentence opens with putting a classification model into a customer’s production workflow.

For FDEs, vagueness costs even more. Paraform’s guide to hiring a first FDE advises employers to ask candidates directly about code they have deployed onto customer infrastructure. Your two sentences need to answer that question before it is asked.

The skill travels well: in a CV, in the description box on an application form, in a message to a recruiter, and in the first sentence you say when an interviewer asks you to “tell me about a project”.

One project, three ways to write it

Picture a hypothetical project, numbers included. You work at a logistics company, and the warehouse team relies on a legacy ERP system written by another vendor, with no API documentation.

You write a service that reads inventory data from a replica of the database, add an API and a dashboard, then deploy it to the company’s on-prem servers after the IT team signs off on security.

Version 0, the way many people still write it: “Built an inventory app using Python and React.” It names tools, but has no users, no constraints and no result.

Version 1 applies the formula Careerflow recommends: Action + Task + Tool/Method + Metric + Result/Scope. The new sentence: “Built an inventory dashboard in Python and React, cutting report preparation time from 2 days to 15 minutes.”

That is good enough for an SWE role. For an FDE role it still lacks exactly what the reader needs to know: whose system, what made it hard, who is using it.

Version 2, written for an FDE role:

“Built an inventory service and dashboard reading directly from a vendor’s legacy ERP (no API documentation, only a database replica), then deployed it to on-prem servers after passing the IT team’s security review. Used daily by 40 managers across 6 warehouses; inventory reporting time fell from 2 days to 15 minutes.”

A tighter version for the CV itself: “Built an inventory service and dashboard on top of a vendor’s undocumented legacy ERP via a read replica; deployed on-prem after passing IT security review. Used daily by 40 managers across 6 warehouses; cut reporting time from 2 days to 15 minutes.”

Each phrase in version 2 answers a line in the job description

“A vendor’s legacy ERP, undocumented” matches a requirement in Valletta Software’s sample FDE job description: candidates who have built something useful inside a system they did not design and cannot fully see.

“Deployed on-prem, after security review” matches how that job description frames the work: deploying into the customer’s infrastructure and getting through their security requirements, rather than running in a sandbox you control.

“Service, API, dashboard, deployment” shows you have worked across several layers. Aced’s Palantir FDE interview guide describes the role as owning the product end to end, from framing the problem and working the data through to the front end.

“Used daily by 40 managers across 6 warehouses” does two jobs. It fills the Scope slot in Careerflow’s formula. It also proves the project runs in production, which is exactly what Valletta’s sample job description states outright: you own production, not a demo.

“2 days to 15 minutes” carries over from version 1. This is the easiest kind of impact to read: UT Austin Career Services gives the example of a sentence about cutting pipeline build time from weeks to days for more than 10 teams, which shows both time saved and scale.

Five steps to rewrite your own project

Step one: name the real users. Not “users” in general, but a specific role such as warehouse managers, the operations team or customer support staff. If nobody but you uses the project, say plainly that it is a personal project and pick another one as your main story.

Step two: name the part of the system that is not yours. It might be a third-party API, an inherited database, another team’s approval process. Many engineers hide this detail because it makes the project look “messy”, yet for an FDE role it is the most valuable part.

Step three: state one real deployment constraint. An on-prem environment, the customer’s cloud, a security review, restricted data access: a single detail like this can replace a whole line of listed technologies.

Step four: pick two numbers, one for scope and one for impact. FDE Academy argues that even an honest estimate of the direction of change beats having no number at all.

If you have no precise measurement, estimate conservatively or write something verifiable, such as “replaced a weekly manual data-entry process”, rather than inventing a percentage.

Step five: cut it to two sentences, then reread it as an interviewer would. For each phrase, ask yourself: if pressed, could you talk about it for five minutes? Drop any phrase you cannot expand on.

This test mirrors how the interview actually runs. According to Aced’s guide, Palantir looks for people who turn a customer’s vague needs into well-scoped, deployable software, and it also assesses how you extend or fix code when the specification is incomplete.

Paraform is blunter: candidates who need a detailed spec before they start will struggle in this role.

So the phrase “undocumented ERP” must lead to the story of how you worked out the database structure and whom you asked for access.

The mistakes that leave two sentences saying nothing

The most common mistake is a list of technologies in place of a story. Anyone can write “Python, React, Docker, Kubernetes”. An FDE recruiter needs to know what you used them to solve, and for whom.

The second is presenting a demo or hackathon project as a production product. One question, “who is using it now?”, exposes the truth. Call a demo a demo, and make a project that reached production your main story.

The third is vague verbs such as “participated in”, “supported” or “improved performance”. If you built part of a large project, name that part: “wrote the ingestion layer myself” is far clearer than “helped build the pipeline”.

The fourth is describing only the backend. If you also touched the data, the interface or the deployment, let the sentence show it, even with a single phrase.

The last is length. Two sentences means two sentences. The urge to cram in more detail usually signals that you have not yet chosen the most important constraint.

The same project, opened differently for each job description

If the job description stresses deploying into customer environments, lead with on-prem and the security review; if it talks mostly about data, open with the database replica. That is not embellishment. It is what FDEs do every day: listen carefully to what the person in front of them needs, then describe their real work in that person’s language.

Behind every signal, the person reading the CV is still asking one question: put this person inside a customer’s system, and will they build something that works? Your two sentences are your first chance to answer it.