FAANG 简历：大厂招聘专员筛选时看什么

FAANG 简历就是标准更严格的软件工程师简历。这个缩写（Meta、Amazon、Apple、Netflix、Google）比 Facebook 这个旧名字活得更久，现在大家用它泛指大型科技公司，所以 Google、Microsoft 和 Stripe 的软件工程师简历过的是同一道筛选。这些公司的招聘专员要处理很长的队列，第一遍只是扫读，而公司已经公开说明了希望这一遍扫出什么。

我从没在大厂做过招聘，这篇指南也不声称掌握任何内部消息。它依据的是 Google、Meta 和 Amazon 在自家招聘页面上公开的内容，加上一份好的软件工程师简历应有的结构，并给你一组虚构的范例要点，用来对照你自己的。

大厂招聘专员筛选什么：他们自己怎么说

Google 的招聘页面把简历称为「我们了解你过往经历和影响的第一眼」，并建议你针对每个职位从一份空白文档写起，而不是改旧文件。那个页面上的具体建议（Google Careers, How we hire）：

• 「让你的技能和经历与职位描述对齐。把你的工作直接和岗位资格要求联系起来（别忘了放数据）。」
• 确认你满足最低资格要求，并确保简历把这一点体现出来。
• 「具体说明你参与或管理过的项目。结果如何？你如何衡量成功？」
• 「如果你担任过领导角色，告诉我们。团队有多大？你的工作范围是什么？」
• 「保持简短。我们没有篇幅要求，但清晰和简洁是关键。」

Meta 的招聘流程页面要求简历「排版易读，突出你的工作经历、技能和成就」，提醒你申请前先核对最低资格要求，并说明其招聘网站上每位申请人只保存一份简历（Meta Careers, Hiring process）。

Amazon 的面试流程（interview loop）页面在「面试会是什么样、如何准备」下面列出了它的领导力准则（Leadership Principles）、行为面试问题和 STAR 方法（Amazon Jobs, Interview loop）。这些准则本身是公开的：「Deliver Results」（达成业绩）要求领导者「专注于业务的关键投入，并以恰当的质量及时交付」，「Ownership」（主人翁精神）写道「领导者是主人翁」（Amazon, Leadership Principles）。一条带结果和度量的简历要点，到了面试里也能充当 STAR 回答的开头。

把这三个页面放在一起读，筛选就归结为对每条要点的三项检验。

范围

范围是你所做事情的规模。Google 在领导角色上直接问这个（团队规模、工作范围），同样的问题也适用于代码：服务的用户数、每秒请求数、负责的服务数、处理的金额、团队里的工程师人数、在生产环境运行的月数。一条没有范围的要点，可能描述的是一个周末项目，也可能是一套撑起整家公司的系统，招聘专员分辨不出来。

影响

影响是因为有你而发生的改变。「参与搜索服务」描述的是一个座位。「把搜索的 p95 延迟从 600 ms 降到 180 ms」是一个结果。大厂的职位描述讲的是一定规模的问题，招聘专员在拿你过去的结果和那个规模做比对。

指标

指标是对这种改变的度量。Google 的页面说「别忘了放数据」，并问你如何衡量成功。指标需要基线：「延迟降低 70%」不写「从 600 ms」就没有意义。数字来自监控面板、事故报告、A/B 测试结果和迭代回顾。如果你只有估算，就写「约」，并保证它经得起追问；面试官会问你这个数字是怎么来的。

FAANG 简历要点的 XYZ 公式

Google 的招聘页面说：「拿不准时，就依靠这个公式：『完成了 [X]，以 [Y] 衡量，方法是 [Z]。』」它的面试准备页面重复了同一个公式，并补充说 Google「热爱数据」（Google Careers, Interview prep）。这个公式比招聘页面出现得更早：曾执掌 Google 人力运营（People Operations）的 Laszlo Bock 在一篇 2014 年的 LinkedIn 文章里发表了它，建议以主动动词开头、用数字衡量结果、给出用于比较的基线，并描述你做了什么。

放到工程类要点上，三个槽位这样对应：

• X，成果。 系统的变化或用户得到的结果：更快、更便宜、更可靠、已上线、已迁移、已解除阻塞。
• Y，度量。 带基线的数字：「从 14 小时降到 25 分钟」、「覆盖每月 3000 万笔交易」、「横跨 12 个服务」。
• Z，方法。 你做了什么、用什么做的：设计决策和技术。关键词也放在 Z 里，这样解析器能在一句证明你用过「Kafka」和「Terraform」的话里找到它们。

顺序可以调整。结果亮眼时先写 X，规模是重点时先写 Y，职位要的正是那项技术时先写 Z。检验标准是：重要的要点里三者是否都在。

FAANG 简历范例要点（虚构）

下面这位工程师是编出来的，公司和所有数字也是。每一组先给出大多数人的写法，再给出同一项工作加上范围、影响和度量后的改写。

Mateus Ferreira，软件工程师，Tidewater Analytics（虚构），5 年经验。

改写前：「参与数据接入流水线的工作。」

改写后：「把接入流水线从 cron 驱动的批处理任务重构为基于 Kafka 和 Flink 的流式架构，日吞吐量从 4000 万提升到 3.1 亿个事件，基础设施成本不变。」

改写前：「提升了 API 性能。」

改写后：「把聚合计算移到预计算的 ClickHouse 物化视图中，为 1,900 家企业客户把报表 API 的 p99 延迟从 2.4 s 降到 380 ms。」

改写前：「协助值班和可靠性工作。」

改写后：「负责 6 个服务的值班，这些服务的综合可用性目标为 99.9%；编写了运维手册和告警规则，两个季度内每周告警呼叫从约 25 次降到 7 次。」

改写前：「指导初级工程师。」

改写后：「带 3 名新工程师入职并指导他们，每人都在入职头 3 周内向生产环境交付了代码；编写了团队的代码评审规范，现已被 4 个团队采用。」

改写前：「主导迁移到 Kubernetes。」

改写后：「带领 4 名工程师，用 7 个月把 22 个服务从基于虚拟机的部署迁到 GKE 上的 Kubernetes，零面向客户的事故，部署时间从 40 分钟降到 6 分钟。」

改写前：「为销售团队做了一个内部工具。」

改写后：「用 React 和 FastAPI 做了一个自助用量仪表板，取代了 30 人销售团队每周的手动导出；上线一个月内 30 人全部采用。」

有两个规律值得注意。改写后的版本把技术名称写在句子里，而不是放进列表。而且没有一条声称全公司的数字；每条只认领 Mateus 负责的部分，用的动词（「重构」、「负责」、「带领」）面试官可以追问。

没有指标的时候

有些工作没有干净的数字：一次重构、一次设计评审、一个阻止了一场没人看见的事故的安全修复。给这类要点写范围，而不是指标。「重构认证模块（1.1 万行代码，3 个服务），去掉共享的可变会话缓存；改动通过功能开关上线，60 天内零回归。」规模、影响半径和持续时间也都是度量。

一页纸

Google 说它没有篇幅要求，希望清晰简洁。在大约八年经验以内，一页纸是大厂简历的惯例，这些公司的页面上也没有任何内容支持写得更长。第二页留给履历很长的 staff 级工程师，即便如此，最早的职位也要压缩到每个一行。

要压到一页，按这个顺序删：求职目标、兴趣爱好那一行、最早那份工作的要点、与工作经历已证明的技能重复的项目，以及任何没有范围、影响或度量的要点。别为了躲开这些删减，把字号缩到 10 磅以下或把页边距缩到半英寸以下；招聘专员还没读一个字，就会先注意到页面塞得太满。

除非申请表要求，否则别写求职信。Google 的页面说公司不要求求职信，并建议你把时间花在简历上。

最低资格要求和「一份简历」规则

Google 和 Meta 都告诉你，申请前先核对最低资格要求，并确保简历能体现你满足它们。把最低资格要求当成检查清单：每一行都指向能证明它的那条要点或技能条目。如果某项必备要求在你的经历里有、简历里却没写，就补上。如果你的经历里本来就没有，只有在缺口只有一项、其余都很强时才去申请。

按 Google 招聘页面的说法，你每 30 天最多可以申请三个职位，所以挑最合适的三个，别广撒网。Meta 在招聘网站上为每位申请人只保存一份简历，这意味着你的 Meta 简历要同时覆盖你申请的所有 Meta 职位；按这些职位之间重叠最多的部分来写，而不是只针对其中一个。对每次申请都接受新文件的公司，每份都单独定制。方法见我们根据职位描述定制简历的指南。

如何对待内推

内推是通过员工提交，把你的简历送到招聘专员面前，而不是进入普通队列。它不改变简历需要证明的东西，也不能跳过筛选或面试。把它当成让文件被读到的一种途径，并在开口之前把文件准备好。

• 找看过你工作的人。 内推表单常常会问员工怎么认识你、你的工作和同行相比如何。前同事或开源合作者能回答这些；LinkedIn 上的陌生人回答不了。
• 让对方省事。 发给对方职位 ID、定制好的 PDF，以及三行说明你为什么适合这个具体职位。推荐人把这些粘进表单就行。
• 自己也投一份。 通过招聘网站提交同一份简历，这样即使内推耽搁了，你的申请也已经在系统里；然后告诉推荐人你已经投了。
• 每家公司只找一个人。 同一职位的多个内推不会叠加，找五个人只会显得你在收集内推。
• 无论结果如何都要感谢对方。 内推要花员工的时间，也要押上一点个人信誉。

FAANG 简历上扎眼的错误

把团队的数字当成自己的。 一个只做了一个功能的工程师写「营收增长 40%」，会招来一个让对话就此结束的面试问题。用对应的动词认领你的部分。

含糊的动词。 「协助」、「参与」、「涉及」告诉招聘专员你在场。「构建」、「负责」、「带领」、「设计」告诉她你做了什么。

内部代号不加解释。 「把 Falcon 迁移到 Hydra」出了你原公司就没人懂。「把订单撮合服务迁移到新的事件总线」在哪里都看得懂。

四十项的技能列表。 招聘专员只能去猜你能聊哪十项。只保留这个月就能接受面试提问的工具。

用名气代替证据。 简历上有一家知名公司的名字有帮助，但它替代不了你在那里所做工作的范围和指标。

流行语。 「充满热情」、「结果导向」、「前沿」、「协同效应」。一页纸能放的行数有限；把它们花在事实上。

重设计轻解析。 带图标、技能条和照片的双栏版式看着漂亮，解析出来却是一堆噪音。大厂的申请在有人看到之前，要先经过 ATS（招聘管理系统 / 申请人跟踪系统）；带真实文本和标准标题的单栏 PDF 能完整通过。我们的简历关键词指南讲了解析器会找哪些词。

补全简历的其他部分

FAANG 简历靠要点撑起来，但个人简介、技能、项目和教育背景板块也要写对，排版也要能通过 ATS。软件工程师简历指南里有可复制的一页模板、中级和高级两份完整的虚构范例，以及逐个板块的建议；这篇文章是在那之上再加的一道更严的标准。

如果你同时申请好几家大厂，每家都有自己的最低资格要求，我维护的免费开源工具 Resume Matcher 会保留一份主简历，并为每个职位裁出一个定制版本。你在自己的电脑上运行它，接入你已经在用的 AI 模型，代码检查会锁定你的雇主、职位和日期，并撤销模型试图编造的任何数字。这一点在大厂求职中比在任何地方都重要：大厂简历上编造的指标，在第一轮技术面试里就会露馅。

如果这篇文章帮到了你

公司已经告诉你他们看什么；要做的是写出回应这些要求的要点。如果这篇指南或这个工具帮到了你，给 GitHub 上的 Resume Matcher 点个 Star 能帮更多工程师找到它，你也可以在 GitHub、X 和 LinkedIn 上关注我，Saurabh Rai。