# 没有内推，如何拿到 FDE 面试机会

> 直接写信给招聘经理，话题落到对方的工作上，再附一个已在生产环境运行的项目链接。

原文: https://fdetimes.net/zh/guides/cold-outreach-fde-interview-no-referral/

想去的公司里一个熟人都没有，点“申请”按钮就像把简历扔进黑洞。ERE 引用的一项调查显示，联系人是招聘经理时，工程师最可能回复。

读完本指南，你会准备好四样可以直接发出的东西：收件人姓名、一条消息、一个证明链接和一条跟进消息。

这一点对前线部署工程师（FDE）岗位尤其重要。给一个从没听说过你的忙人写信，并说服对方花时间给你，正是你以后会和客户反复做的事。

开始前需要三样东西：一个你已上线到生产环境的项目、一个 GitHub 账号，以及一份在招 FDE 岗位的短名单。如果还没有这样的项目，先做第 2 步。没有证明材料，消息写得再好，也只是一段空口无凭的自我介绍。

## 第 1 步：写给谁，走什么渠道？

要找的是招聘经理，也就是将来直接管你的人，而不只是招聘专员。ERE 引用的数据显示，工程师最常回复招聘经理发来的消息。

这项调查问的是被招聘的人，而不是求职者，所以套用到你的情况属于推断。但道理站得住：团队负责人最能迅速看出，你的证明材料解决的是他们的哪个问题。

渠道方面，同一调查中 51% 的工程师更希望通过个人邮箱接到工作机会，LinkedIn InMail 排第二。调查样本不大，只能作参考。比较稳妥的做法是：能找到公开邮箱就发邮件，LinkedIn 作为备选。

**检查：**每个岗位都有一个具体的人名和联系方式。如果收件人一栏只写着“招聘团队”，这一步还没完成。

## 第 2 步：陌生人真正会点开什么证明？

dev.to 上一篇关于如何成为 FDE 的指南认为，一个做扎实的端到端项目，远胜十个玩具 demo。

具体标准是：项目要能说明你把一个模糊的问题变成了一个带评测（evals）的可用系统。Scaler 的一篇指南给出了类似的门槛：项目应当完成集成、已经部署并有人在用，而不是照着教程做的应用。

证明材料按由浅入深分三层整理。第一层是一段简短的演示视频，带旁白的录屏就够了。第二层是写给非专业人士看的案例研究或 README。第三层是代码仓库：代码整洁、提交历史清楚，并有在线部署。

一个建议的 README 大纲（为演示做了精简）：

```markdown
# [项目名称]：为[使用者]解决[问题]

## 最初的问题（有多模糊）
## 如何把问题收窄
## 线上系统：[部署链接] · [演示视频链接]
## 质量评估：评测覆盖了什么、发现了什么
## 谁在用，他们怎么说
## 如果有更多时间，会改进什么
```

“质量评估”一节用来展示系统有评测，这正是上面的标准，所以不要留空。**检查：**把链接发给一位不做技术的朋友。如果对方看完视频能说出系统解决的是什么问题，证明材料就准备好了。

**要点:** 一个放对位置的证明链接，足以撑起一条原本平平无奇的消息。

## 第 3 步：四段式消息

在 ERE 的调查中，39% 的工程师认为个性化是冷启动消息中最重要的部分，排在所有其他因素之前。

招聘平台 Underdog.io 建议，没有内推时，要和收件人本人、对方的工作或公司建立一个具体的关联。这个关联替代了你缺少的那次引荐。

由此，消息分成四个部分。标题点明具体岗位，不用泛泛的说法。开头一句是那个具体关联。中间是一个与对方问题相关的证明链接。

最后一句是一个小请求，比如下周聊 15 分钟。模板如下：

```text
标题：Forward Deployed Engineer – 用[项目]解决[与对方产品相近的问题]

[姓名]，您好：

您在[演讲 / 文章 / 发布]中谈到的[具体话题]，正是我在构建[项目]时
遇到的问题：[用一句话描述那个模糊的问题]。

这个项目我做了端到端交付：已部署，[谁]在使用，并针对
[质量的含义]做了评测。3 分钟演示 + 文字说明：[链接]

下周能否抽 15 分钟聊一聊，看看这是否契合
贵团队的 FDE 岗位？

[姓名] · [GitHub] · [简历链接]
```

LinkedIn 消息应比邮件更短，InMail 版本只保留关联句、链接和请求。**检查：**删掉收件人姓名再读一遍。如果这条消息发给任何公司都说得通，说明个性化还不够。

## 第 4 步：只用一个链接跟进

没收到回复很正常。跟进要非常简短，不要再附长文档，而是附上作品集里一篇案例研究的链接。可以把第 2 步的“质量评估”一节当作新切入点，比如用一句话说明系统最近一次改进后能做到什么。

**检查：**跟进消息不超过三句话，且没有附件。

## 常见错误

第一个错误是只写给招聘专员，然后干等。第二个是附上五个代码仓库。对方一个也不会打开，因为不知道从哪里看起；把一个端到端项目放在最前面效果更好。

第三个是要求太多，比如“能不能帮我看看简历并内推”，而一次简短通话要容易答应得多。

## 对方回复了，接下来呢？

每家公司流程不同，这里以 Palantir 为例。根据 Aced（原 Exponent）的面试指南，其 FDE 流程包括一次 30 分钟的招聘专员电话，重点是你的求职动机。第 2 步中你为什么做这个项目的故事，就是这次通话最好的准备。

Palantir 的 FDE 面试流程还包括一轮问题拆解（decomposition），要求你在几乎不写代码的情况下拆解一个开放式问题。几乎每位候选人都会遇到这一轮。

README 中“如何把问题收窄”一节是最贴近的练习，因为它逼你讲清楚如何把一个模糊的问题切成若干步骤。

## 这项技能如何用到客户工作中？

在客户现场，你常常要给一个对你没有任何义务的忙人写信：运营经理、客户方的数据工程师、项目发起人。

公式不变：找对有决策权的人，建立与对方问题的具体关联，给出几分钟就能看完的证明，再提一个小请求。

在简历上，可以用一行项目描述加一个演示链接来体现这项技能，而不是罗列一串技术栈。读你消息的人从没见过你，所以这条消息本身，就是检验你能否与客户合作的第一场考试。

**本周动手试试:**

- 挑三个 FDE 岗位，找到每个岗位招聘经理的名字，并记下这个人或其团队最近做过的一件具体的事。
- 为非专业人士重写你最好项目的 README，然后录一段带旁白的录屏演示视频。
- 用本指南的模板发出一条消息，并记下哪里最难做个性化。

## 信源

- [Increasing the ROI of Cold Outreach to Engineers | ERE](https://www.ere.net/increasing-the-roi-of-cold-outreach-to-engineers/)

- [Message to Hiring Manager: How to Get a Response](https://underdog.io/blog/message-to-hiring-manager)

- [How do you become a Forward Deployed Engineer? (2026)](https://dev.to/manduks/how-do-you-become-a-forward-deployed-engineer-2026-2l8p)

- [How to Become a Forward Deployed Engineer (Even Without the Perfect Background)](https://www.scaler.com/topics/how-to-become-forward-deployed-engineer/)

- [Palantir Forward Deployed Engineer (FDE) Interview Guide | Sample Questions (2026) - Aced (formerly Exponent)](https://www.aced.io/guides/palantir-forward-deployed-engineer-interview)