推荐系统工程师入职前 90 天启动检查清单

一句话总结

正确的判断是：入职前的 90 天不是“把所有代码跑通”，而是“搭建信息框架、验证关键假设、赢得团队信任”。如果你把重点放在盲目写代码上，你会在第一个迭代里被边缘化；如果你先把业务、数据、评估指标、关键同事的沟通模式全部映射清楚，你将在两周内完成第一个 A/B 实验的部署。

适合谁看

本清单专为以下三类人群设计：

  1. 获得硅谷大型互联网公司（如 Netflix、Amazon、Meta）推荐系统岗位 Offer 的新入职工程师；
  2. 已在国内头部内容平台（如字节跳动、快手）从事相似工作，但即将进入全新技术栈的技术转岗者；
  3. 想在入职前 90 天内快速定位价值、避免“技术孤岛”，并争取第一轮绩效评估的资深工程师。

核心内容

1. 入职前的 “信息收割” 应该怎么做？

不是盲目刷 GitHub，而是系统化收集内部文档。

  • 场景：入职前两周，HR 发来 Welcome 包，里面有 3 份内部 Wiki 链接：Data Pipeline Overview、Feature Store Design、Evaluation Metrics。你在第一天就把这三份文档下载到本地，并用 Obsidian 建立 “推荐系统” 主题库。
  • 对话：在第一次与 Hiring Manager（HM）的视频面谈中，HM 说：“我们更关心你能否在两周内说出我们最核心的三条业务指标。”你回复：“我已经把 Metrics Doc 里提到的 CTR、Retention、Revenue 三个指标列出，并标记了它们对应的业务场景。”
  • 结果：HM 当场点头，后续的 1:1 中直接进入了指标细化讨论。

2. 第一次代码提交的正确姿势

不是把所有模型代码一次性 push，而是先提交 “实验框架 + 验证脚本”。

  • 场景：在第 3 周，你准备把最新的召回模型代码上线。你先在本地跑完离线评估，生成了两套指标报告（baseline vs new）。随后在 PR 描述里写明：“此 PR 仅包含实验框架，实际模型参数将在后续的 A/B 中替换”。
  • 对话：代码审查（Code Review）会议上，资深 SDE 说：“如果直接上线模型，风险太大。我们需要先把实验框架稳住，再做模型迭代。”你回答：“我已经在实验框架里预留了参数化入口，后续只要改 config 就能切换模型。”
  • 结果：审查通过，实验框架在两天内被全团队复用，提升了后续模型迭代的效率。

3. 与业务方的沟通节奏

不是每周一次的例会，而是 “关键节点 + 数据驱动的快速反馈”。

  • 场景：业务侧 PM（Product Manager）每周一上午 10 点会有产品路标会。你在第 4 周的例会上主动提出：“我们上周的召回实验提升了 3% 的点击率，这里有一张对比图”。
  • 对话：PM 回应：“这很好，但我们还需要看对新用户的影响。”你立即打开笔记，展示了分层指标（新老用户）并说明了下一步的实验计划。
  • 结果：PM 当场决定将实验范围扩大到全平台，给你争取到了额外的计算资源。

4. 薪酬结构的合理预期

不是只看 Base Salary，而是 “Base + RSU + Bonus” 三项齐全。

  • Base Salary：$150,000 – $210,000（视经验而定）
  • RSU（受限股）：价值 $40,000 – $80,000，四年归属，首年 25% 归属
  • Bonus：年度绩效奖金 $15,000 – $30,000，依据 OKR 完成度发放

> 关键判断：如果你只盯着 Base，看不到 RSU 的长期激励，你的谈判杠杆会被大幅削弱。

5. 面试流程的全拆解

不是只记住轮数，而是每轮的 “考察重点 + 时间分配”。

轮次 时间 考察重点 典型问题 评价标准
1️⃣ 初筛（HR） 30 min 文化契合、薪资期望 “你为什么想加入我们？” 价值观匹配度
2️⃣ 技术电话（SDE） 45 min 编程基础、算法思维 “实现一个 Top‑K 推荐的高效算法” 代码可读性、复杂度
3️⃣ 系统设计（Lead Engineer） 60 min 架构全局、数据流、容错 “设计一个每日 10B 召回系统” 可扩展性、监控方案
4️⃣ 推荐专项（Hiring Manager） 60 min 业务指标、实验方法、模型迭代 “如何从 CTR 到 Revenue 优化召回？” 指标洞察、实验设计
5️⃣ 团队匹配（Peer） 45 min 跨团队协作、沟通风格 “描述一次跨部门冲突并如何解决” 沟通技巧、冲突处理
6️⃣ 最终 Offer Review 30 min 薪酬结构、职业发展路径 – 双方共识

> 关键判断：如果你只准备算法，却忽视系统设计和业务指标，你在第 4 轮会被直接淘汰。

准备清单

  1. 信息框架：在入职前两天完成内部 Wiki、Metrics、Feature Store 三大文档的结构化笔记。
  2. 实验框架：在本地搭建可切换模型参数的实验脚本（Python + Airflow DAG），并提交一次内部审查。
  3. 业务指标映射：列出 CTR、Retention、Revenue 三个核心指标对应的业务场景，准备 1‑2 张对比图。
  4. 沟通日程：提前在公司内部日历上标记所有关键会议（产品路标会、实验评审会、团队周会），并设定 15 分钟的预备时间。
  5. 薪酬对齐：在 Offer 环节明确 Base、RSU、Bonus 的具体数额，准备一份 “总包 vs 市场” 对比表。
  6. 面试回顾：系统性拆解面试结构（PM 面试手册里有完整的[面试流程拆解]实战复盘可以参考），把每轮的考察重点写进笔记。
  7. 技术准备：在入职前 1 周完成公司内部代码规范（Google Style）和 CI/CD 流水线的本地模拟运行。

常见错误

错误一：盲目写代码

BAD：入职第一周就把自己的实验模型全部 push 到 prod，代码缺少单元测试，导致线上召回 CTR 突降 5%。

GOOD：先在本地跑完离线评估，提交只包含实验框架的 PR，加入详细的测试用例和监控指标说明，得到审查通过后再上线。

错误二：只关注 Base Salary

BAD：在 Offer 谈判时只问 “Base Salary 能不能再高 10%？”结果只多拿 $12k，RSU 与 Bonus 完全忽视，三年后总收入比同行低 30%。

GOOD：把目标拆成 Base + RSU + Bonus，展示行业 RSU 参考值，争取 $70k RSU + $25k Bonus，实际总包提升 45%。

错误三：缺乏业务指标意识

BAD：在第 4 轮面试中只讲模型的 AUC 提升 2%，未说明对业务 Revenue 的影响，Hiring Manager 直接打了 “业务洞察不足”。

GOOD：在同样的模型提升场景下，补充说明 AUC 提升对应的 Revenue 预估增长 $1.2M，并提供实验分层结果，得到 “业务驱动” 评价。

FAQ

Q1：我已经拿到 Offer，但对 RSU 归属周期不清楚，应该怎么确认？

A：先在 Offer 邮件中找到 “Equity Grant” 那一行，通常会写明 “4‑year vesting, 25% after 12 months”。如果文档里只有总额 $60k，直接发邮件给 Recruiter，引用公司内部政策（如 “Equity Handbook 第 3.2 节”），要求确认每年归属比例。实际案例：一位新入职的同事在邮件中写明 “请确认我的 RSU 归属计划是否为 1‑yr cliff + 3‑yr linear”，Recruiter 回复确认后，后续绩效评估时也能明确对应的激励目标。

Q2：入职前两周，我该如何快速定位关键业务指标？

A：不要等到正式会议才去问。最佳做法是先在内部 Wiki 找到 “Metrics Dashboard” 链接，下载最近 3 个月的 KPI 报表。随后在 Slack 中私聊对应的业务 PM，直接说 “我在准备第一个实验，想确认 CTR、Retention、Revenue 的最新基准值”。在一次真实对话中，候选人在入职前第 10 天就通过这种方式拿到了基准 CTR 0.42% 的数据，直接在实验提案中引用，获得了 HM 的即时认可。

Q3：如果我的第一轮代码面试被刷，我还能继续争取这个岗位吗？

A：不是所有轮次都决定命运，而是 “是否留下技术成长的痕迹” 更关键。被刷的候选人如果在面试后 24 小时内给面试官发送一封技术复盘邮件，指出自己在实现 Top‑K 召回时忽略了缓存层的优化，并附上改进的伪代码，往往会得到 “Keep in mind for future roles” 的回复。实际案例：一位候选人在第一轮被拒后发了复盘，HR 在下个月的内部招聘中把他拉入 “候选人池”，最终以更高的 Senior Level Offer 收到。

以上即为推荐系统工程师入职前 90 天的启动检查清单。把判断落在“信息框架、实验框架、业务指标、薪酬结构、面试全拆解”五大核心上，你将在两周内从“新人”转变为“可交付价值的成员”。祝你在新岗位顺利起航。

准备好系统化备战PM面试了吗？

获取完整面试准备系统 →

也可在 Gumroad 获取完整手册。