Palantir 部署策略师和 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 天，或者不符合安全许可的申请条件，那么面对有这些要求的岗位，申请材料再强也很难往下推进。

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