证据标记

全文用四种标记区分事实与建议：

• 【直接证据】：候选人明确报告自己遇到过的流程或题目，或者公司职位文本明确写出的要求。
• 【跨样本综合】：多个相邻公司和岗位反复出现的共同模式。它能指导准备，但不能被表述成某家公司的确定流程。
• 【岗位文本】：来自职位描述、公司研究页面或正式招聘材料，用于理解工作，而不是证明面试一定会考什么。
• 【实践建议】：依据招聘实践与风险控制提出的方法。它不声称来自特定公司面经。

预测题网站、搜索摘要和无法追溯到候选人原文的题库可以保留为低置信度线索，但不进入真实题目频率。使用它们时应明确写成“练习建议”，不能写成“某公司曾考”。

1.1 它不是“把大模型套在科学数据上”

一个完整的 AI for Science 项目通常跨过以下链条：

科学目标
        ↓
      可学习的问题定义
        ↓
      数据生成、清洗与表示
        ↓
      baseline、模型、训练与评估
        ↓
      候选生成或预测
        ↓
      实验验证或模拟验证
        ↓
      新数据回流，重新建模
      

不同岗位拥有链条中的不同部分。只会介绍模型架构，而不能说明标签如何产生、数据如何泄漏、候选如何验证、失败如何反馈到下一轮，通常不足以证明能够做真实的 AI for Science 工作。

【岗位文本】 Lila 的 Foundation Models for Life Sciences 职位同时强调生物序列、分子结构、多模态实验数据、问题定义、模型设计、训练、评估和闭环发现，而蛋白设计被写成加分项。这说明至少在这一岗位中，科学建模链条比单一蛋白知识更核心。Lila 职位页

【跨样本综合】 Generate:Biomedicines、BigHat、insitro、Deep Genomics、Latent Labs 等面经把科学题面与一般 ML 能力混合起来。候选人可能面对蛋白、RNA、DNA 或 assay 数据，但追问会回到模型选择、loss、数据划分、统计检验、代码和评估。Generate:Biomedicines、BigHat、Deep Genomics

1.2 五个常见岗位谱系

1.3 用五条轴判断真实岗位，而不是职位名称

对每个职位分别打 1 到 5 分：

【实践建议】 用这五条轴把 JD 翻译成真实工作画像，再选择简历版本和面试准备。不要先问“这个标题适合我吗”，而要问“这五条轴中，团队最需要哪三条，我有什么证据”。

2.1 第一遍：找交付物

动词比技术名词更重要。

【实践建议】 把每个动词改写成一句“入职六个月后我要交付什么”。如果无法写出来，说明你还没有理解岗位。

2.2 第二遍：区分门槛与题面

JD 中的要求可以分成四类：

1. 硬门槛：学位、工作许可、地点、明确年限、必须掌握的领域技术。
2. 核心能力：建模、编程、实验设计、统计、沟通。
3. 工作题面：蛋白、分子、材料、RNA、显微图像或实验自动化。
4. 加分项：某个框架、特定模型、wet lab 经验或发表记录。

【岗位文本】 当一个岗位把 protein design 写为 bonus，同时把问题定义、模型设计、训练和评估放在核心职责中，不应因为自己不是蛋白专家就自动退出，也不应忽视领域补课。正确策略是先证明核心能力，再说明如何快速进入题面。

2.3 第三遍：推断面试，而不是假装知道面试

可以根据 JD 建立“待验证假设”：

• 反复出现 PyTorch、implement、training，可能提高 ML coding 权重。
• 反复出现 scientific collaborators、problem formulation，可能提高 case 与沟通权重。
• 反复出现 production、platform、scale，可能提高 system design、测试和工程权重。
• 反复出现 publication、novel methods，可能提高 research talk 与论文深挖权重。

【实践建议】 这些只能决定准备方向。除非 recruiter、HM 或候选人原文明确确认，不能写成“该公司一定有这一轮”。

2.4 识别危险的模糊描述

以下信号值得在 screening 中追问：

• 同时要求顶尖论文、全栈部署、数据平台和深领域知识，却没有说明团队分工。
• 目标写成“用 AI 革命科学”，但没有数据来源、验证机制或科学合作方式。
• 强调生成大量候选，却不说明筛选、实验验证或失败反馈。
• 要求“端到端负责一切”，但岗位级别、资源和权限不匹配。
• 小团队声称训练前沿基础模型，却没有说明算力、数据或合作基础。

【实践建议】 模糊不等于差。早期团队可能仍在形成组织。但候选人需要判断这是可塑性，还是缺少战略与资源。

3.1 科学闭环检查

逐项寻找证据：

1. 公司要改变的科学决策是什么。
2. 训练数据从哪里来，是否持续产生。
3. 模型输出如何被实验或模拟验证。
4. 验证周期和成本大致是什么量级。
5. 负结果如何记录并回到模型。
6. 公司的护城河在数据、实验、模型、人才还是运营。

【跨样本综合】 AI for Science case 面经经常追问数据、实验和评价，而不止模型名称。Latent Labs 的候选人被问如何产生并处理一百万个蛋白设计；insitro 以 RNA 数据和统计选择为题；Deep Genomics 要求解释 DNA 数据建模与设计选择。这反映了规模、数据生成机制与验证路径的重要性。Latent Labs、insitro、Deep Genomics

3.2 数据优势检查

不要只问数据量。更重要的问题是：

• 数据是否与最终目标同分布。
• 数据是否有可靠标签或验证信号。
• 同一实体是否跨 split 泄漏。
• 失败实验和负数据是否保存。
• 数据能否形成持续闭环，而不是一次性采购。
• 数据权利是否允许模型训练和商业使用。

【实践建议】 面试中可以问团队最难的数据问题，但不要要求披露机密。一个成熟团队通常能在不泄密的情况下说明数据类型、质量挑战和验证方式。

3.3 研究可信度检查

可观察信号包括：

• 论文是否回答了真实问题，还是只有漂亮 benchmark。
• 是否公开 baseline、ablation、失败边界和评价设置。
• 研究人员的背景是否与当前方向一致。
• 模型结果是否经过实验或外部数据验证。
• 公司是否持续产出，而不是只有融资时的展示。

【实践建议】 不要用论文数量简单排序公司。对于闭源或早期公司，重要成果可能无法发表；对于大型实验室，发表很多也不保证具体团队有清晰产品或实验闭环。

3.4 组织与管理检查

向 recruiter、HM 和未来同事分别验证：

• 谁决定研究优先级。
• Scientist、Engineer 与实验科学家如何协作。
• 项目失败后如何复盘。
• 一项研究从 idea 到验证通常经过哪些阶段。
• 代码、数据和实验的 ownership 如何划分。
• 晋升看论文、平台、发现、产品影响还是团队影响。

不同受访者的答案不必完全相同，但若相互矛盾，应继续追问。

4.1 不要只分“想去”和“不想去”

建议为每个岗位分别评估：

【实践建议】 每个维度分开打分，不要让名气或一个高薪数字覆盖其他风险。签证和雇佣资格属于需要直接向公司及合格专业人士确认的事实，不应根据论坛推测。

4.2 建立三层申请组合

• A 层：高度匹配且最想去。投入定制简历、研究公司、寻找 referral，并安排足够准备时间。
• B 层：匹配良好。使用同一岗位族的简历版本，做适度定制。
• C 层：探索或练习。控制投入，但仍保持专业，不把任何公司当作无成本 mock。

【实践建议】 如果长期没有面试，问题通常发生在岗位选择、简历证据或申请渠道；如果 recruiter screen 后大量失败，问题更可能是 narrative、动机、级别或约束；如果到 technical 后失败，再把重点转向具体能力。

4.3 申请顺序要服务于学习

理想顺序是让相近岗位形成一组：

1. 先安排一到两个中等优先级岗位，验证叙事和基础面。
2. 再进入最重要岗位。
3. 同期流程不要相差太远，以便 offer 时间可比较。

这不是操纵公司，而是减少一次偶然面试决定整个求职结果的风险。

5.1 每一条 bullet 回答四件事

问题是什么
      你做了什么关键判断或实现
      如何验证
      结果改变了什么
      

弱表述：

使用 PyTorch 和 Transformer 构建蛋白模型。

较强表述：

将序列到功能预测定义为带家族隔离的多标签任务；实现 Transformer baseline 与校准评估；发现随机划分高估跨家族泛化，并据此重做数据 split。

后一种写法不依赖夸张的性能数字，却提供了问题定义、实现、验证和研究判断。

【跨样本综合】 多家公司在面试中要求候选人深入解释项目与设计选择。Unity 要求端到端讲一个 ML system，Deep Genomics 追问模型、代码和设计，Amazon Applied Scientist 的 phone 与 onsite 都包含 ML depth。简历中的每个重要 bullet 都可能变成二十分钟追问的入口。Unity、Amazon

5.2 Scientist、Research Engineer 与 MLE 的侧重点

同一个项目可以有不同版本，但不能改变事实。

• Scientist 版本：问题、假设、方法、实验设计、结论和新颖贡献。
• Research Engineer 版本：原型、数据与训练系统、复现、调试、性能、测试和研究迭代速度。
• MLE 版本：端到端系统、规模、可靠性、部署、监控、成本和用户或实验影响。
• Computational Scientist 版本：领域问题、数据机制、计算方法、验证与科学结论。

5.3 数字必须有解释

数字可以说明：

• 数据规模。
• 训练时间或成本变化。
• 性能、校准或统计结果。
• 实验吞吐量。
• 系统可靠性或延迟。
• 研究周期缩短。

【实践建议】 不要只写“提升 20%”。准备好回答分母、baseline、数据 split、方差、统计不确定性和实际意义。如果数字不能公开，可以用区间、相对变化或定性影响，但必须保持真实。

5.4 论文与代码链接

只有在链接能加强证据时才放：

• 论文链接应能快速定位你的贡献。
• GitHub 应有可理解的 README、运行入口和有限而清楚的结果。
• demo 应稳定，不要求 reviewer 安装复杂环境。
• 私有工作可以用匿名架构图或公开演示项目替代，不能泄露前雇主信息。

6.1 Narrative 不是按时间背简历

一个可靠的 research narrative 回答：

1. 你持续关心什么问题。
2. 为什么这些问题重要。
3. 你形成了哪些独特能力。
4. 哪些结果改变了你的判断。
5. 为什么下一步与目标团队连接。

推荐结构：

长期问题意识
      → 两到三个代表项目
      → 从项目中形成的方法论
      → 当前能力边界
      → 为什么这个岗位是合理的下一步
      

【实践建议】 叙事需要连贯，但不要制造一条从学生时代就注定的职业故事。真实的转向、失败和重新选择能体现判断力。

6.2 把跨领域经历翻译成迁移能力

例如从计算机视觉进入蛋白设计，不要只说“Transformer 是通用的”。更有说服力的是：

• 你如何处理结构化或多模态输入。
• 如何设计严格 split，避免近邻实体泄漏。
• 如何在少标签与分布偏移下评价。
• 如何把生成结果连接到实际约束。
• 如何与领域专家共同定义错误成本。

【跨样本综合】 第一、二轮面经显示，科学题面变化很大，但底层能力反复集中在问题定义、数据、loss、训练、evaluation、debugging 和沟通。迁移叙事应落在这些可验证能力上，而不是只强调模型名称相同。

6.3 准备三个长度

• 30 秒：身份、核心能力、目标方向。
• 2 分钟：加入两个代表项目与转向原因。
• 10 分钟：完整 research arc，可承接追问。

三个版本应共享事实和主线，只改变细节密度。

7.1 每个主项目至少准备十二个问题

1. 原始目标是什么。
2. 你如何定义 ML 任务。
3. 数据如何产生，最危险的偏差是什么。
4. split 为什么合理。
5. 最简单 baseline 是什么。
6. 为什么选择这个模型与 loss。
7. 训练中最难的问题是什么。
8. 核心指标为什么与真实目标一致。
9. 哪个 ablation 最有信息量。
10. 失败案例揭示了什么。
11. 你本人负责什么，别人负责什么。
12. 如果再做一次会改什么。

【直接证据】 Generate、Deep Genomics、Unity、Amazon、NVIDIA 和多家研究岗位都在候选人报告中出现项目深挖、研究展示或设计选择追问。这是跨岗位最稳定的面试形式之一。

7.2 不要回避失败

优秀回答不是把项目描述成一路成功，而是显示你能区分：

• 实现 bug。
• 数据问题。
• 评价问题。
• 模型假设错误。
• 资源不足。
• 科学假设本身不成立。

【实践建议】 选择一个你真正改变过方向的失败案例。说明观察、排查顺序、关键证据和最终决策，不要只说“调参后解决”。

7.3 代码 ownership 必须准确

如果项目由多人完成，明确：

• 你写了哪些模块。
• 你做了哪些研究决策。
• 哪些结果来自合作者。
• 你如何验证接口和共同结论。

把团队成果全部说成个人成果，通常会在代码或实验细节追问中暴露。

8.1 Recruiter 在判断什么

常见目标包括：

• 你的经历是否大致符合岗位级别。
• 申请动机是否具体。
• 工作地点、开始时间、薪资和身份条件是否可行。
• 你的沟通是否清楚，是否存在明显风险。
• 候选人与哪个团队最可能匹配。

Recruiter 不一定能回答深技术问题，也不应被期待替 HM 做科学判断。

【跨样本综合】 多家公司候选人报告的第一步都是 recruiter screen，之后才进入 HM、technical 或 team matching。Unity、Spotify、Anthropic、OpenAI 等样本均出现这一模式，但具体内容和筛选权重不同，不能推断每家公司都有完全相同的 screen。

8.2 “为什么这家公司”要回答到工作机制

一个稳健回答包含：

1. 具体科学目标。
2. 公司的数据、实验或技术路径为何有吸引力。
3. 你的哪项经历能够立即贡献。
4. 你希望补足什么能力。

弱回答通常只复述使命或融资新闻。

8.3 应该主动确认的事实

• 完整面试阶段与每轮目标。
• live coding 的语言、框架、环境和 AI 政策。
• take-home 的时间预期。
• research talk 的时长、受众和保密要求。
• 职位级别是否固定。
• 工作地点和远程要求。
• 身份与签证支持是否适用。

【实践建议】 问流程不是索要原题。越早确认形式，越能公平准备，也能避免违反工具政策。

8.4 薪资问题

如果职位公开区间，可先确认 level 与总包结构，再讨论期望。如果必须给数字，可以说明基于职责、级别、地点和完整总包评估，而不是孤立报一个工资。

【实践建议】 不虚构已有 offer，不用未经核验的论坛数字作为事实。股权、奖金和福利的价值需要分别理解。

9.1 HM 在解决风险

HM 通常关心：

• 你能否承担团队当前最重要的问题。
• 是否能在不完整信息下做判断。
• 研究深度和编码能力是否平衡。
• 能否与领域科学家和工程师协作。
• 级别、ownership 与独立性是否匹配。
• 加入动机是否稳定。

9.2 HM 回答结构

回答项目或工作方式时，可以使用：

背景与约束
      → 我负责的决策
      → 备选方案与取舍
      → 验证证据
      → 结果与反思
      

这比只列技术栈更容易让 HM 判断你的工作级别。

9.3 反问 HM

有信息价值的问题包括：

• 这个岗位入职六个月后最重要的交付是什么。
• 团队当前最大的科学风险和工程风险分别是什么。
• 一个项目何时从探索变成正式投入。
• 最近一次停止项目的原因是什么。
• 模型、实验与数据团队怎样共同决定下一轮。
• 这个岗位不同 level 的行为差异是什么。

【实践建议】 不要把反问变成表演。根据对话选择两到四个真正影响决策的问题，并追问具体例子。

10.1 常见目的

Take-home 可以考察：

• 从模糊需求到可运行结果的过程。
• 数据探索、baseline 与评价。
• 代码组织、测试和可复现性。
• 研究判断与书面沟通。
• 时间管理和范围控制。

【直接证据】 Latent Labs 候选人报告过用 Colab 构建 protein diffusion model 的 take-home；Deep Genomics 候选人需要对 DNA 数据建模并解释选择；InstaDeep 的蛋白设计 Research Engineer 流程包含基于蛋白数据的 coding challenge。Latent Labs、InstaDeep

10.2 提交物结构

建议包含：

1. README：目标、运行方法、假设、结果、局限。
2. 清晰入口：训练、评价或 notebook 的执行顺序。
3. 最小可复现环境。
4. baseline 与最终方法的对照。
5. 关键图表或表格。
6. 必要测试和 sanity check。
7. 时间允许时才做的扩展。

10.3 控制范围

先交付正确 baseline，再增加复杂性。一个完整、可解释、可运行的小方案通常比半完成的宏大模型更能证明判断力。

【实践建议】 在 README 明确时间预算和未完成项。不要用精美包装掩盖数据泄漏、错误 split 或没有 baseline。

10.4 AI 使用

如果公司没有主动说明，可以礼貌询问：

• 是否允许自动补全。
• 是否允许通用 AI assistant。
• 是否需要记录 prompt 或引用生成内容。
• 是否有数据不能上传第三方。

未经允许，不把公司数据、私有 repo 或题目上传外部服务。

11.1 ML 与 PyTorch live coding

【跨样本综合】 候选人直接报告过以下任务：

• Neuralink：PyTorch 写基础 MLP 和 training loop；另一候选人在 1 小时内完成围绕模型训练的 10 个小任务，禁止 coding assistants。Neuralink
• Apple：解释 PyTorch snippets 并补齐 training loop。Apple
• Qualcomm：PyTorch 实现 decoder-only causal mask。Qualcomm
• Skild AI、Tap Mobile 与 TikTok：实现 multi-head attention，部分记录还要求 masking 与 KL divergence。Skild AI、Tap Mobile、TikTok
• OpenAI：Research Engineer 流程中分别有 PyTorch 与 NumPy ML coding，另有 data loader 和 tests。OpenAI

这些记录支持一个重要边界：基础模型可能出现，但常被拆成半小时到一小时可表达的小组件，而不是要求现场搭建完整训练系统。

11.2 ML fundamentals

【直接证据】 Pinterest 候选人遇到 L1/L2、稀疏性推导、vanishing gradients、bagging 和 boosting；Fusemachines 出现 optimizers、overfitting 与 regularization；Woven Planet 出现 class imbalance、transfer learning 与训练曲线诊断。Pinterest、Fusemachines、Woven Planet

基础题的评价重点通常不是背定义，而是能否回答：

• 现象为何发生。
• 数学或计算机制是什么。
• 如何在数据和曲线上识别。
• 哪种修复适用，副作用是什么。
• 如何用实验验证修复有效。

11.3 ML case study

case 没有唯一模型答案。面试官通常观察候选人如何缩小模糊空间。

推荐框架：

1. 明确科学目标和成功定义。
2. 说明 prediction、generation、ranking 或 decision 的任务形式。
3. 识别数据单位、标签、偏差和成本。
4. 设计 split，特别是 family、scaffold、time、lab 或 batch 隔离。
5. 建立最小 baseline。
6. 选择模型、loss 与约束。
7. 设计离线 metrics 与实验验证。
8. 分析失败、分布偏移和不确定性。
9. 说明下一轮数据或实验怎样选择。

【直接证据】 Latent Labs 的候选人被问如何产生一百万个蛋白设计；Generate 候选人讨论目标蛋白的生成模型；Spotify 的 final round 含多个 recommendation 与预测 case；Meta Research Scientist 的 system design 以 binary classification 为中心。Latent Labs、Spotify、Meta

11.4 Code comprehension、debugging 与 PR review

观察顺序：

目标与入口
      → 数据流与 shape
      → 状态和副作用
      → 训练与推理差异
      → 错误与边界条件
      → 测试覆盖
      → 性能和可维护性
      

【直接证据】 Wayve 候选人需要调试训练 CNN 的 PyTorch Colab；TORC 候选人阅读 neural network 和 training loop；Tractable 有 live coding 与 code refactoring；Anthropic 的 assessment 在需求逐级增加时要求快速重构；Sixt 候选人审查两个新 PR。Wayve、TORC、Tractable、Sixt

12.1 Transformer

直接面经支持的常见粒度包括：

• positional embedding。
• causal mask。
• single-head 或 multi-head attention。
• encoder 与 decoder 的差别。
• 训练与推理时的计算。
• masking、shape 和复杂度。

【跨样本综合】 Transformer 既可能是概念题，也可能是一个小组件实现题。它不应取代 MLP、loss、training loop 和 evaluation 等基础准备。

12.2 VAE

【直接证据】 Electronic Arts 的 Senior MLE 题目比较 AE、VAE 和 VQ-VAE，并追问输入特征与 VQ-VAE loss。Electronic Arts

【跨样本综合】 公开可核验的一般 ML 面经中，VAE 更多作为概念、目标函数和 representation learning 题出现。没有足够证据声称完整 VAE live coding 是高频题。

12.3 Diffusion

【直接证据】 BigHat 把 diffusion 作为抗体设计 case 中可能要求解释的基础支柱；Latent Labs 的流程出现 protein diffusion take-home；Ayna AI 问 diffusion 如何训练；SenseTime 研究实习要求写 sampling process 伪代码。BigHat、Ayna AI、SenseTime

【跨样本综合】 应理解 forward noising、训练目标、noise 或 score prediction、sampling loop、conditioning、评价和计算成本。现有证据不足以把“半小时写完整 diffusion pipeline”列为常见要求。

12.4 蛋白与科学领域覆盖层

领域准备应围绕问题结构：

• 表示对象是什么。
• 结构与序列如何关联。
• 标签或实验信号怎样产生。
• homology、scaffold、batch 或实验平台如何造成泄漏。
• 生成候选需要满足哪些硬约束和软目标。
• 离线得分与实验成功之间有多大差距。
• 如何在实验预算下选择下一批候选。

【跨样本综合】 第一轮 AI for Science 样本中，不以蛋白为题面的记录占多数，但一般 ML 能力和领域题面经常重叠。更准确的准备方式是“扎实通用底座，加一层岗位领域”，而不是在纯 ML 与纯领域之间二选一。

13.1 Research talk 的真正任务

研究展示不只是证明做过工作，还要让不同背景的人理解：

• 为什么问题值得解决。
• 现有方法为什么不足。
• 你的贡献是什么。
• 证据是否支持结论。
• 边界和失败在哪里。
• 这项工作如何连接团队问题。

【直接证据】 NVIDIA、SandboxAQ、Meta 与多家研究岗位的候选人报告包含 presentation、project walkthrough 或 research discussion。具体时长和受众因公司而异，必须向 recruiter 核实。

13.2 建议的 talk 结构

1. 一页问题与影响。
2. 一页最小背景，让非本领域听众进入。
3. 清楚的研究问题和假设。
4. 数据与评价设置。
5. 方法，只保留影响结论的细节。
6. 核心结果与对照。
7. failure analysis 与限制。
8. 下一步和岗位连接。

13.3 为两类听众设计

• 领域专家会追问科学假设、数据机制和结论边界。
• ML 或工程专家会追问 split、baseline、loss、实现、scale、reproducibility 和测试。

【实践建议】 主线服务混合听众，把数学、额外 ablation 和实现细节放在 backup slides。每张核心图都准备一句结论和一句限制。

13.4 连续 one-on-one

同一天与多人交谈时，问题会重复。保持事实一致，但根据角色调整细节：

• Scientist：假设、方法、证据、开放问题。
• Engineer：实现、debugging、接口、scale、可靠性。
• 实验科学家：候选、验证、失败成本、协作。
• Manager：优先级、ownership、冲突、交付。

记录每轮新信息，但不要在后续面试中泄露前一位面试官的私人评价。

14.1 不存在统一行业规则

同一公司不同阶段也可能有不同政策：

• live coding 完全禁止 AI。
• 允许库文档但禁止搜索和助手。
• take-home 允许 AI，但要求披露。
• repo review 允许普通编辑器功能，但禁止把私有代码上传第三方。
• 工作样本希望模拟日常工具环境。

【直接证据】 Neuralink 候选人明确报告 technical exercise 不允许 coding assistants、Stack Overflow 或 autocomplete，只能参考库文档。Lila 的候选人沟通也明确说明 live coding 不许使用 AI。这些是具体流程证据，不能外推为所有公司统一政策。

14.2 候选人的正确行为

1. 提前询问并保存书面说明。
2. 若规则模糊，在开始前再次确认。
3. 不把私有 repo、数据、题目或凭证上传外部服务。
4. 允许使用时仍理解并检查每一行提交内容。
5. 需要披露时，简洁说明使用范围和验证方法。

【实践建议】 不要寻找规则漏洞。面试评价的不只是产出，还包括可信度、判断和安全意识。

14.3 在 AI 时代保留无助手能力

即使日常使用 AI，也应保持：

• 从空文件写最小训练循环。
• 手动追踪 tensor shapes。
• 读 traceback 与定位错误。
• 为函数设计测试。
• 解释代码为什么正确。
• 在没有搜索时回忆基础 API。

面试只是一个压力测试；这些能力也决定你能否识别 AI 生成代码中的安静错误。

15.1 小公司常见特征

• 岗位边界更宽。
• 面试流程可能由少数团队成员直接设计。
• 更看重立即贡献和跨职能合作。
• 研究、工程、数据和实验 ownership 可能集中在同一人。
• 流程公开信息少，单条面经代表性有限。

【跨样本综合】 BigHat、Latent Labs、Deep Genomics、Tractable、Upstream Tech 等小型或较专门团队的候选人报告，经常把真实领域 case、项目讨论、coding 和团队交流结合起来。但不同公司的成熟度差异很大，不能据此给任何未披露流程的小公司套模板。

15.2 大型实验室常见特征

• 面试模块较标准化。
• coding、ML breadth、ML depth、system design、behavioral 可能分开。
• team matching 与 level 校准更正式。
• 资源和专家密度高，但 ownership 可能更窄。
• 研究发表、平台影响和组织协作可能有不同晋升路径。

【直接证据】 Amazon Applied Scientist 的候选人报告 phone screen 后有多轮 ML depth、breadth 和 coding；Meta 候选人报告 coding、ML system design、presentation 和 behavioral 的模块化组合。Amazon、Meta

15.3 选择不是“大或小”，而是风险组合

16.1 每轮结束后立即记录

不要记录或传播受保密约束的完整题面。可以记录：

• 阶段与时长。
• 能力类别。
• 哪些问题答得清楚。
• 哪些地方卡住，以及根因。
• 对公司和团队的新信息。
• 下一次要改变的一件事。

16.2 用失败阶段定位问题

这只是诊断起点，不是确定因果。公司通常不提供完整反馈，单次结果也可能受 headcount、team matching 和竞争者影响。

16.3 建立 evidence log

每次改进都要有新证据，例如：

• 30 分钟内独立完成 MLP 和 training loop。
• 在陌生 repo 中十分钟画出数据流。
• 用统一框架完成三个不同领域 case。
• research talk 的非领域听众能准确复述贡献。
• mock interviewer 能区分你本人和团队的工作。

【实践建议】 “看了更多资料”不是能力证据。以可观察表现决定是否进入下一项训练。

16.4 不要被一家公司过拟合

将准备分为：

• 通用底座：Python、PyTorch、ML fundamentals、case、代码阅读、项目深挖。
• 岗位覆盖层：蛋白、RNA、材料、分子、自动化实验等。
• 公司适配：流程、研究方向、团队问题和反问。

这既提高迁移性，也减少某家公司流程变化后准备全部失效的风险。

17.1 先确认事实

要求书面确认：

• title、level、汇报对象和地点。
• base、bonus、sign-on 与股权类型。
• vesting、cliff、行权与离职条款。
• 福利、休假、搬迁和开始日期。
• 身份与签证支持。
• 任何竞业、知识产权或发表限制。

法律、税务、签证和股权条款应由合格专业人士解释，本指南不替代专业意见。

17.2 工作内容的尽调

在接受前尽量与未来经理和一到两位同事沟通：

• 前三到六个月的项目。
• 当前项目最可能失败的原因。
• 数据与实验资源是否已经存在。
• 研究代码如何进入长期维护。
• 绩效如何评价。
• 团队最近的人员变化。
• on-call、加班、出差和实验节奏。

17.3 股权不要按融资估值等同现金

【实践建议】 对私营公司股权做情景分析：归零、低于当前估值、持平和显著增长。理解 fully diluted ownership、优先权、税务与流动性限制。若公司不提供足够信息，就应给股权更高折扣，而不是自行填补乐观假设。

17.4 经理与问题质量往往比模型名称更持久

模型热点会变化。长期复利更多来自：

• 是否在高质量问题上工作。
• 是否有强经理和同事反馈。
• 是否拥有完整决策链的一部分。
• 是否积累可迁移的科学与工程能力。
• 是否形成可信的成果记录。

17.5 Offer 决策矩阵

分别给以下维度打分，并写一句证据：

【实践建议】 先独立打分，再比较 offer，避免后到的数字或名气改变所有维度。

18.1 每个岗位一条记录

建议字段：

• 公司、团队、职位和链接。
• 岗位五轴画像。
• 硬门槛与核心能力。
• 简历版本。
• 申请渠道和联系人。
• 当前阶段与下次行动。
• 已确认流程和 AI 政策。
• 公司研究摘要。
• 面试复盘。
• 最终结果和原因假设。

18.2 每周复盘三个漏斗

1. 申请漏斗：高匹配申请是否转成 screen。
2. 面试漏斗：失败集中在哪个阶段。
3. 学习漏斗：投入时间是否转成可观察能力。

不要只统计申请数量。大量低匹配申请会让数据看起来丰富，却无法告诉你简历是否有效。

18.3 建立材料模块，而不是每次从零写

长期维护：

• 通用一页简历。
• Scientist、Research Engineer、MLE 三个强调版本。
• 30 秒、2 分钟和 10 分钟 narrative。
• 三个 project deep dive。
• 一套 research talk 主体与 backup slides。
• case framework。
• coding 与 repo review checklist。
• 公司研究模板。
• 面试复盘模板。

定制时选择和调整模块，不改变事实。

19.1 只准备前沿模型

Transformer、VAE、diffusion 很重要，但直接面经同时大量出现 MSE、MLP、training loop、regularization、class imbalance、数据处理和测试。

【跨样本综合】 “基础模型可能出现”与“基础可以跳过”并不等价。最接近半小时 live coding 的题常是一个小组件或基础训练任务。

19.2 只背领域知识

知道蛋白、材料或分子术语，却不能把目标定义为 ML 任务，也不能设计 split 和评价，无法完成 Scientist 的核心工作。

19.3 只会调用高级 API

如果无法解释 shape、loss、gradient、mask 和 train/eval 行为，调用一个现成模型不足以应对实现与 debugging。

19.4 Case 一开始就报模型名

先问目标、数据、约束和评价。一个昂贵的新模型不能修复错误标签、泄漏 split 或错误成功指标。

19.5 Repo review 只挑风格

优先 correctness、contract、data flow、测试与 regression。命名和格式除非影响理解，不应压过真实 bug。

19.6 Research talk 只有成功结果

没有 baseline、ablation、失败与限制的展示很难证明研究判断。

19.7 把推断写成事实

相似公司经常共享能力要求，但流程不必相同。所有准备材料都应区分：

• 该公司已确认。
• 相邻岗位反复出现。
• 单一低置信度线索。
• 为覆盖能力而设计的练习。

19.8 用 AI 代替理解

如果无法在无助手环境重建基础代码、解释生成内容并发现错误，工具会放大而不是弥补能力缺口。

20.1 单个职位研究卡

# 公司 / 职位
      
      ## 已确认事实
      - 职位链接：
      - 团队与汇报线：
      - 地点与身份条件：
      - 面试阶段：
      - AI 使用政策：
      
      ## 岗位画像
      - 科学领域深度：1–5
      - 方法创新：1–5
      - 工程可靠性：1–5
      - 实验闭环：1–5
      - 对外研究：1–5
      
      ## 我的三项匹配证据
      1.
      2.
      3.
      
      ## 最大缺口
      -
      
      ## 需要向 recruiter/HM 确认
      -
      
      ## 来源
      -

20.2 Project deep dive 卡

# 项目
      
      问题：
      我的 ownership：
      数据产生机制：
      split 与 leakage：
      baseline：
      模型与 loss：
      训练难点：
      评价与统计：
      最重要 ablation：
      失败案例：
      最终影响：
      如果重做：
      代码入口：
      可公开内容与保密边界：

20.3 Case 答题卡

目标与决策：
      任务形式：
      数据单位和标签：
      约束与成本：
      split：
      baseline：
      模型与 loss：
      离线 metrics：
      实验或在线验证：
      不确定性：
      failure analysis：
      下一轮数据选择：

20.4 面试后复盘卡

阶段与时长：
      已确认能力类别：
      答得最好：
      卡住位置：
      根因：知识 / 编码 / 结构 / 沟通 / 时间 / 环境
      公司新信息：
      仍未确认：
      下一项可观察改进：

20.5 Offer 尽调卡

书面条款已确认：
      直属经理与团队：
      六个月交付：
      数据与实验资源：
      最大项目风险：
      绩效与晋升：
      工作强度：
      身份与地点：
      现金与股权情景：
      两年后的能力资产：