# Palantir 部署策略师和 FDSE，该投哪一个

> 两个岗位都驻场做同一个项目，一个定义问题，一个写代码给出答案，简历要说清你站在哪边。

原文: https://fdetimes.net/zh/guides/palantir-deployment-strategist-vs-fdse/

打开 Palantir 的招聘页面，你会看到两个并排的职位：一个是部署策略师（Deployment Strategist），另一个是前线部署软件工程师（Forward Deployed Software Engineer，FDSE）。两者都写着要去客户现场工作，对一个既喜欢写代码、又喜欢和用户打交道的工程师来说，听上去都很合适。

常见的做法是用同一份简历把两个都投了。可一份想同时兼顾两边的简历，哪边都说服不了。

好在招聘启事已经把每个岗位做什么写得相当清楚，前提是你像读需求规格一样仔细读。最省力的读法，是从头到尾跟一个假想的项目走一遍，再把看到的东西写成两份简历。

## 一个提出对的问题，一个把答案做出来

Palantir 美国政府业务的部署策略师招聘启事这样描述这个岗位：帮助客户看清零散信息之间的关联，再把他们的“直觉”（hunches）变成现实。

英国政府业务的启事写得更具体：策略师要去客户现场，和客户的分析师见面，弄清他们需要回答的关键问题。

英国政府的启事还写到，策略师要和前线部署工程师（FDE）一起，把数据整合进稳定、可扩展的数据管道。也就是说，岗位描述本身就把数据管道交给了工程师。Python、R、Matlab 或 SQL 经验只列为“加分项”。

FDSE 的启事正好相反。候选人必须是很强的程序员，熟练掌握 Python、Java、C++、TypeScript/JavaScript 或类似语言，工作内容包括根据客户需求开发定制应用。

**要点:** 一个负责找到值得回答的问题，另一个负责做出回答它的东西。

## 在同一个项目里，两个岗位各做什么？

设想一家政府机构管理着一个备件仓库。一位分析师怀疑缺货是少数几家供应商交货延迟造成的，但没人证实过。这正是启事里提到的那种“直觉”。

策略师来到现场，和这位分析师待上一整天。

策略师的任务是把直觉变成可衡量的问题，比如：“过去六个月里，哪些供应商交货延迟超过 14 天？哪些单位因为这些延迟订单出现了缺件？”策略师还要弄清数据在哪里：采购系统里有下单日期，仓库系统里有收货日期。

接下来轮到 FDSE。工程师为两个系统分别编写连接器，处理那个老问题：同一家供应商在两个地方用着两个不同的编码。然后搭建一条每天运行的数据管道，再做一个小应用，让分析师能按供应商和单位筛选。

最后一轮又回到策略师。培训时，策略师发现分析师根本不用筛选功能，而是把所有数据导出到电子表格。策略师把这个观察带回给工程师，下一个版本就多了一个按钮，能按分析师平时提交给上级的格式直接导出报告。

实际工作中，两个岗位的边界没有这么分明。一些二手资料称，Palantir 内部把 FDE 叫作“Delta”，把策略师叫作“Echo”，并引述 Palantir 的说法：Echo 偏向产品管理，Delta 偏向工程。

据同样的资料，每个岗位都兼有一部分产品经理、一部分软件工程师和一部分策略师的职责，所以一个岗位的人常常也会做另一个岗位的部分工作。

## 招聘启事里哪几行决定了你适合哪个岗位？

先看编码要求。一边把编程列为加分项，另一边把很强的编码能力列为硬性条件。如果你还没把握写出一条在真实数据上跑起来的数据管道，申请 FDSE 之前先把这件事练好。

再看工作经验。FDSE 启事只要求毕业后一年的相关经验。门槛低并不代表这个岗位好拿：和“编码能力强”的要求放在一起看，说明编码能力比工作年限更重要。

第三是工作安排，很多人会直接跳过这部分。FDSE 启事写明出差到客户现场的比例最高 25%，可按个人意愿灵活安排。维尔纽斯（Vilnius）的策略师岗位要求 10-20% 的出差，并需要安全许可。

美国政府业务的策略师岗位要求每周驻场 4-5 天，主要在科罗拉多斯普林斯（Colorado Springs），同样需要安全许可。同一个职位名称，在每个地方条件都不一样，所以每份启事都要读，不要读了一份就以为其余的都一样。

## 回想你状态最好的一周，再做选择

招聘平台 Paraform 给出了一条简单的规则：如果你想动手构建，就选 FDE，也就是在客户环境里写生产代码的岗位；如果你喜欢界定问题、和各方利益相关者打交道，就选策略师。这是一家招聘公司的看法，但和 Palantir 两份启事在编码要求上的差距是吻合的。

更好的检验方法是看你自己。想想最近一次下班回家还兴奋不已的那一周。如果那周你攻克了一个棘手的数据 bug，你更偏向 FDSE；如果那周你和用户坐在一起，发现他们问错了问题，你更偏向策略师。

## 简历：一个岗位一个版本

同样的经历可以有两种讲法。下表用一个假想的内部项目，展示同一个故事如何换一个重点来讲。

| 你要证明的能力 | 策略师版本 | FDSE 版本 |
|---|---|---|
| 理解问题 | 访谈 6 位用户，把三个零散的需求合并成一个可衡量的问题 | 阅读日志和数据表结构，为已确定的问题找到合适的数据源 |
| 构建方案 | 和工程团队一起编写需求规格和验收标准 | 用 Python 编写数据管道，关联两个系统并统一重复编码 |
| 推动使用 | 主持培训，记录用户卡住的地方 | 根据反馈更新应用，当天部署新版本 |

策略师版本仍应写上一行 SQL 或 Python，因为启事把它列为加分项。FDSE 版本仍应写上一行关于用户的内容，因为“根据客户需求”开发应用，前提是理解这些需求。

## 让申请落空的几个错误

最常见的错误，是以为策略师是非技术岗位。一个每天和 FDE 讨论数据管道、却不懂数据如何流动的人，很难定义出可行的问题。

相反的错误，是以为 FDSE 只是一个人埋头写代码：启事交给他们的是根据客户需求开发的定制应用，还要求随时准备出差到客户现场。

第三个错误，是没读工作安排那几行就投了。如果你没法在某个城市每周驻场 4-5 天，或者不符合安全许可的申请条件，那么面对有这些要求的岗位，申请材料再强也很难往下推进。

这两个岗位不是高低两级，而是和客户协作这一循环中的两半。一旦知道自己属于哪一半，你就不用再两个都投了。

**本周动手试试:**

- 列出过去三个月里最让你兴奋的 10 项工作，把每一项标为“定义问题”或“构建方案”，再数一数哪边更多。
- 打开 Palantir 的一份部署策略师启事和一份 FDSE 启事，划出所有关于编码、出差、驻场天数和安全许可的句子，再和你的实际情况对照。
- 把简历前三条要点改写成两个版本：一版讲你如何定义问题，一版讲你做了什么、它如何在真实数据上运行。

## 信源

- [Palantir Technologies - Deployment Strategist, Build to Apply - US Government](https://jobs.lever.co/palantir/842d6bc5-823c-4a77-8839-3f0f427bcd8c)

- [Palantir Technologies - Deployment Strategist - UK Government](https://jobs.lever.co/palantir/2f3a0a57-8f77-44d2-99c3-18aef115374f)

- [Palantir Technologies - Deployment Strategist](https://jobs.lever.co/palantir/4e99e055-96c7-497e-8099-3318e1ce0626)

- [Palantir Technologies - Forward Deployed Software Engineer](https://jobs.lever.co/palantir/dab396d4-2f14-4796-aac0-0d82883dccf0)

- [Palantir Deployment Strategist vs Forward Deployed Engineer: What's the Real Difference?](https://fde.academy/blog/palantir-deployment-strategist-vs-forward-deployed-engineer)

- [Forward deployed engineer vs deployment strategist (2026)](https://www.paraform.com/blog/forward-deployed-engineer-vs-deployment-strategist)