用 Pull Request 替代白板面试：AngelList 的异步代码评审实践

技术面试长期存在一个结构性矛盾：候选人在高压环境下解算法题的表现，与其实际工作中阅读代码、协作沟通、交付功能的能力往往不成正比。白板面试考察的是表演能力，而工程团队真正需要的是能够阅读现有系统、识别改进空间、并通过代码评审流程将改动安全合入生产环境的人才。

AngelList 工程团队近期分享的实践经验提供了一个值得参考的替代方案 —— 用真实的 Pull Request 流程取代传统面试环节。这套方法不仅更准确地评估候选人的工程能力，还产生了意外的附加价值：候选人提交的改进直接合并到了生产环境，面试流程本身实现了自我迭代。

从算法题到业务问题：重新定义考察目标

传统 take-home 作业的设计往往陷入两难：题目太简单无法区分能力，太复杂则变成时间投入的无底洞。AngelList 的解决方案是选择与自身业务高度相关的真实问题 —— 实现一个三层次风投基金分配瀑布算法的 JavaScript 版本。

这个选择有几个刻意的设计：首先，它涉及实际的金融计算逻辑（返还资本、优先回报、附带权益），候选人需要理解业务语境才能正确实现；其次，题目自包含，不依赖特定框架知识，降低了环境配置的门槛；最重要的是，它同时考察算法思维和数值精度处理能力，这两者都是金融基础设施开发的核心能力。

更具前瞻性的是，AngelList 允许候选人使用 Claude AI 助手完成这个任务。但关键区别在于，他们并非测试候选人能否避免使用 AI，而是观察候选人如何与 AI 协作 —— 是否验证 AI 生成的代码、能否识别 AI confidently wrong 的情况、是否对边界条件保持怀疑。系统会记录候选人与 AI 的完整对话以及每次按键操作（带毫秒级时间戳），使面试官能够复盘候选人的思维过程。

第二阶段：向生产代码提交 PR

通过第一阶段筛选的候选人进入真正的创新环节 —— 他们获得测试平台本身（Next.js 应用）的代码库访问权限，任务是找到值得改进的地方并提交 Pull Request。

这不是模拟任务。候选人面对的是与团队日常工作中完全相同的代码库、相同的 CI/CD 流程、相同的代码评审标准。他们可以选择修复 bug、优化 UX、改进架构，或者提出产品层面的改进建议。

AngelList 已经合并了多个来自候选人的 PR：有人发现 Part 2 编码环境中 AI 聊天面板与测试用例编辑器无法同时显示的问题，于是构建了支持标签切换的侧边栏组件，包含流式响应指示器、localStorage 持久化和事件驱动架构；有人定位到一个数据丢失 bug—— 当网络请求失败时，候选人的答题数据会被静默丢弃，他提取了 flush 逻辑到独立模块，添加了重试机制和七个单元测试，并引入了 Vitest 测试框架；还有人优化了 AI 助手的校准参数，使评估的 signal-to-noise ratio 更精准。

这些贡献的价值远超任何白板题的答案。它们展示了候选人在真实代码库中的导航能力、对边缘情况的敏感度、以及将改进安全交付到生产的工程判断力。

异步代码评审流程的设计要点

PR-based 面试的核心是建立一套异步评审机制，使评估过程既高效又能保证公平性。

代码提交规范方面，应当要求候选人遵循与团队一致的提交信息格式和分支命名约定。AngelList 的做法是让候选人直接工作在真实代码库中，这意味着他们需要阅读现有的 CONTRIBUTING 指南，理解项目的代码风格要求。这种设计本身就在考察候选人的协作意识 —— 是否能够快速适应陌生项目的规范。

评审维度标准化是确保评估一致性的关键。建议从以下四个维度建立评分 rubric：

• 问题识别能力：候选人选择解决的问题是否反映了真实的业务价值或技术债务？是选择了表面的 UI 调整，还是发现了深层的架构或数据完整性问题？

• 方案设计质量：解决方案是否考虑了向后兼容性？是否引入了不必要的依赖？改动范围是否聚焦？

• 代码实现水平：代码是否清晰可读？是否包含适当的错误处理？测试覆盖是否充分？类型安全是否得到保证？

• 沟通与文档：PR 描述是否清晰地解释了问题背景、解决方案和验证步骤？是否主动标注了潜在的风险点或需要特别 review 的部分？

评审响应机制应当模拟真实团队的工作节奏。建议设定明确的评审反馈时间窗口（例如 24 小时内），并要求候选人根据反馈进行迭代。这个过程能够观察候选人的响应能力、对建设性批评的接受度，以及协作沟通的风格。

可复现面试环境的构建

PR-based 面试对基础设施有特定要求。首先需要维护一个 "面试专用" 代码库分支或独立仓库，该环境应当：

• 与生产环境保持同步：定期从主代码库同步更新，确保候选人面对的是当前的技术栈和架构模式
• 包含已知但未修复的问题：刻意保留一些适合面试时长（4-8 小时）解决的 bug 或改进点，问题难度应当分级，使不同经验水平的候选人都能找到匹配的挑战
• 具备完整的开发环境：提供 devcontainer 配置或详细的本地环境搭建指南，确保候选人能够在自己的机器上快速启动项目
• 包含自动化测试套件：候选人应当能够运行现有测试并添加新的测试用例

安全隔离是另一个关键考量。候选人提交的代码需要经过自动化安全扫描，CI 流程应当限制网络访问权限，防止恶意代码执行。同时，代码库中不应包含真实的生产凭证或敏感数据。

AI 辅助的边界设定需要明确。如果允许使用 AI，应当记录使用情况（如 AngelList 的做法），并在评审时区分候选人自主完成的部分与 AI 生成的部分。评审重点应当放在候选人对 AI 输出的验证和批判性评估上，而非单纯禁止 AI 使用。

实施建议与潜在风险

对于希望采用类似方法的团队，建议从以下步骤开始：

首先，选择或创建一个与团队技术栈一致的 "面试代码库"，规模控制在候选人能够在几小时内理解核心架构的程度。微服务架构可能过于复杂，单体应用或清晰分层的模块化代码库更适合面试场景。

其次，建立问题 backlog，将已知的技术债务、小 bug 或 UX 改进点整理成候选任务列表，标注预估工作量和难度等级。这使候选人能够快速选择与自己能力匹配的问题。

第三，培训面试官掌握 PR 评审的评估维度，建立校准机制确保不同面试官对同一候选人的评估结果一致性。建议定期举行 "评审标准对齐会议"，讨论边界案例的评分标准。

潜在风险需要提前规划。维护面试代码库需要持续的工程投入，如果团队没有足够资源保持代码库更新，候选人可能会面对过时的技术栈或已知已修复的 bug，这会降低面试体验。此外，PR 评审的主观性较强，需要建立多轮评审机制避免单一面试官的偏见影响评估结果。

时间投入是另一个考量因素。相比一小时的算法面试，PR-based 流程可能需要候选人投入 4-8 小时，团队也需要投入相应的评审时间。这要求筛选机制足够有效，确保只有高潜力候选人进入这一阶段。

结语

AngelList 的实践表明，技术面试可以跳出 "表演解题" 的范式，转向 "协作交付" 的模式。当候选人提交的代码真正合并到生产环境、当面试流程本身因候选人的贡献而持续改进时，面试不再是单向的筛选工具，而成为双向的价值交换。

这种方法特别适合那些强调工程师自主性、鼓励团队贡献而非被动执行任务的组织。它传递了一个明确的信号：我们寻找的不是能背诵算法的人，而是能够阅读系统、识别改进、并安全交付的工程师。

参考来源

• AngelList Engineering Blog, "The Interview That Ships to Production", May 2026

engineering-practices