Deployment Strategist or Forward Deployed Software Engineer at Palantir: how they differ and which to apply for

You open Palantir’s careers page and see two postings side by side. One is for a Deployment Strategist, the other for a Forward Deployed Software Engineer. Both talk about working with customers on site, and both sound right for an engineer who likes writing code as much as talking to users.

The usual reflex is to apply to both with the same CV. A CV written for both will convince neither.

The good news is that the postings say fairly clearly what each role does, as long as you read them as carefully as a spec. That reading is easiest if you follow one hypothetical project from start to finish, then turn what you see into two CVs.

One asks the right question, the other builds the answer

The Deployment Strategist posting for Palantir’s US government business describes the role as helping customers see the connections between scattered pieces of information, then turning their “hunches” into reality.

The UK government posting is more specific: the strategist goes on site and meets the customer’s analysts to understand the key questions they need to answer.

The UK government posting also says the strategist works with Forward Deployed Engineers to integrate data into a stable, scalable pipeline. In other words, the job description itself hands the pipeline to the engineer. Experience with Python, R, Matlab or SQL is listed only as “a plus”.

The FDSE posting is the reverse. Candidates must be strong programmers, proficient in Python, Java, C++, TypeScript/JavaScript or a similar language, and the work includes building custom applications for the customer’s needs.

What does each role do on the same project?

Picture a government agency that manages a spare-parts warehouse. An analyst suspects that shortages come from a handful of suppliers who deliver late, but nobody has proved it. That is exactly the kind of hunch the posting mentions.

The strategist goes on site and spends the day with the analyst.

Their job is to turn the hunch into a measurable question, for example: “Which suppliers delivered more than 14 days late in the past six months, and which units ran short of parts because of those late orders?” They also find out where the data lives: the procurement system holds order dates, the warehouse system holds receipt dates.

Then it is the FDSE’s turn. The engineer writes connectors into both systems and deals with the familiar problem of one supplier carrying two different codes in two places. They then build a pipeline that runs daily and a small application that lets the analyst filter by supplier and by unit.

The last round goes back to the strategist. During training, they notice the analyst ignores the filters and exports everything to a spreadsheet. They take that observation back to the engineer, and the next version has a button that exports a report in exactly the format the analyst already submits to their manager.

In practice the boundary between the two roles is not this sharp. Some secondary sources say Palantir internally calls FDEs “Delta” and strategists “Echo”, and quote Palantir as saying Echo leans towards product management while Delta leans towards engineering.

According to the same sources, each role carries part product manager, part software engineer and part strategist, so people in one role often do some of the other’s work.

Which lines in a posting decide which role fits you?

The first line to look for is the coding requirement. One side lists programming as a plus; the other lists strong coding as a condition. If you are not yet confident writing a pipeline that runs on real data, practise that before applying for an FDSE role.

The second line is experience. The FDSE posting asks for only one year of relevant experience after university. A bar that low does not mean the role is easy to get: paired with the demand for strong coding, it suggests coding ability weighs more than years on the job.

The third line is logistics, and this is where many people skip ahead. The FDSE posting lists travel of up to 25% to customer sites, with flexibility according to personal preference. The strategist posting in Vilnius requires 10-20% travel and a security clearance.

The US government strategist posting requires being on site 4-5 days a week, mainly in Colorado Springs, also with clearance. The same title comes with different conditions in each place, so read every posting rather than reading one and assuming the rest match.

Choose by looking back at your best working week

Paraform, a recruiting platform, offers a simple rule: if you want to build, choose FDE, the role that writes production code inside the customer’s environment; if you enjoy scoping problems and working with stakeholders, choose strategist. That is the view of a recruiting firm, but it matches the gap in coding requirements between Palantir’s two postings.

A better test is to look at yourself. Think of the most recent week you came home from work still excited. If it was the week you cracked a hard data bug, you lean towards FDSE. If it was the week you sat with users and realised they were asking the wrong question, you lean towards strategist.

CV: one version per role

The same experience can be told two ways. The table below uses a hypothetical internal project to show how the same story shifts its emphasis.

What you need to prove	Strategist version	FDSE version
Understanding the problem	Interviewed 6 users and merged three scattered requests into one measurable question	Read logs and schemas to find the right data sources for the agreed question
Building the solution	Wrote the spec and acceptance criteria with the engineering team	Wrote a Python pipeline joining two systems and normalising duplicate codes
Getting it used	Led the training session and recorded where users got stuck	Updated the application from feedback and deployed the new version the same day

The strategist version should still include a line on SQL or Python, since the posting names it as a plus. The FDSE version should still include a line about users, because building applications “for the customer’s needs” requires understanding those needs.

Mistakes that sink an application

The most common mistake is assuming the strategist role is non-technical. Someone who talks to FDEs about pipelines every day without understanding how data flows will struggle to define a feasible problem.

The opposite mistake is assuming FDSEs just code alone: the posting gives them custom applications built for customer needs and asks them to be ready to travel to customer sites.

The third mistake is applying without reading the logistics lines. If you cannot be on site 4-5 days a week in a specific city, or are not eligible for clearance, even a strong application will struggle to progress for postings that require those conditions.

These two roles are not a senior and a junior rung. They are two halves of the same loop with the customer. Once you know which half you belong to, you will no longer need to apply for both.