在 HelloBetter 构建 McDougall 方法：一种更公平、更现代的技术面试方法

作为一个痴迷于技术职业、业务增长和工程管理的人，我经常遇到技术面试的妖怪。

在许多方面，科技公司都停留在 20 到 30 年前的思维中：白板、算法、逻辑谜题和围绕面对面面试空间轮换的任务。

我们正处于一个新时代，99% 的工程面试都是虚拟完成的，面试团队无法控制候选人的工作空间。

我们需要适应这一点，不是简单地将以前的方法移植到在线平台上，而是从根本上重新思考我们期望 21 世纪软件工程师具备的技能。

当然，雇主和（潜在）员工对技术面试问题的看法很普遍。

例如，长期以来，leetcode 式的评估一直被嘲笑为对能力的糟糕测试。

“相反，”反对者争辩说，“你应该使用候选人可以向你解释的带回家的测试或项目”。

啊，但你看，并不是每个人都能负担得起让他们的晚上和周末消失在这些带回家的测试或副业项目中。

由于这种称为“时间”的不便的线性结构，更有经验的工程师开始拥有或照顾家庭、收养宠物或（主禁止）进行运动和爱好。大多数家务和护理职责仍然倾向于由女性承担，这也不是大秘密。

作为候选人，为了展现你最好的一面，无论有多少招聘经理告诉你“只花 2-3 个小时在解决方案上”，你都会创造出最好的解决方案。因此，带回家或“自己的项目”技术面试往往会使年长的候选人和女性候选人处于不利地位。

如今出现的另一个问题是工程师通过技术面试的人工智能工具的盛行，从手动输入提示到 ChatGPT（现在有点老派），一直到让其他人为您进行技术轮次并人为地贴上您的脸。

暂时回到带回家的测试，这些在人工智能时代几乎已经过时了，很大程度上是因为所有的解决方案似乎彼此惊人地相似......👀

那么当......

• Leetcode 测试并不能很好地指示工作本身。
• 带回家将有利于那些有更多空闲时间的人。
• 提出自由式技术问题很容易与人工智能作弊。

在这里，我分享了我们自己在柏林心理健康 DTx 初创公司 HelloBetter 的经历，即将我们的技术面试转变为一种解决方案，该解决方案不仅反映了实际工作，而且不需要不合理的候选人时间。

我不相信目前还没有一个完美的解决方案来应对评估工程候选人的技术技能的挑战，但我确实认为这是迄今为止我所知道的平衡现实期望、有用的见解和公平的测试条件的最佳解决方案。

背景

2024 年 11 月，我们开始监督招聘流程的变化，首先确定我们当前的问题是什么。

尝试过雇用工程师的读者啊，其中大部分对您来说可能很熟悉：

1. 面试过程步骤太多。
2. 招聘时间长。
3. 直到流程后期才发现有关候选人的关键信息（例如，他们想在一年内垂直或水平移动）
4. 候选人使用人工智能作弊或歪曲自己的能力。
5. 一轮技术面试，感觉更像是一次记忆力测试。
6. 工程师的时间被面试招聘经理不想要的候选人占用
7. 工程师在面试中推荐反对候选人时感到困惑，但该候选人还是被录用了，反之亦然。

非技术性招聘变动

首先，让我们看看我们实施的与技术面试无关的解决方案：

• 在申请表中引入了一份简短的问卷，以筛选出一些常见的目标、薪资等方面的不一致（但应该注意的是，所有 HelloBetter IC 薪资等级都是公开的)
• 将技术轮次移至招聘经理轮次之后。
• 将我们最后两轮半小时的面试——“团队面试”和“创始人面试”——合并到一个小时的时段中，以减少日程安排的延误。
• 我提供了更多的时间和意愿，例如每天或背靠背面试多个候选人。

对于我们最近的招聘，我特意与我们的招聘人员保持密切联系，每天至少分享 1-2 条闲聊消息，以掌握流程、候选人和后续步骤。我们还每周举行一次半小时的同步会议。

上述大部分更改都是在工程经理和招聘部门的合作中完成的。我自愿接受对技术面试进行定义更改的挑战，这在很大程度上是因为我对如何做得更好有清晰的愿景。

技术面试轮次：研讨会阶段

我想确保这涉及所有工程。由于工程师是进行技术面试的人，因此让他们根据我的标准推动精确结构的构思和缩小范围是有意义的。

在 Slack 中，我请求志愿者来帮助我，并获得了 6 个接受者。一次偶然的机会，他们巧妙地分成了两名工程师，分别负责移动、Web 前端和后端。

有问题的工程师是 Julia Ero、Mohamed Gaber Elmoazin、Andrei Lapin、Caio Quinta、Euclides dos Reis Silva Junior 和 Chaythanya Sivakumar。

我建立了一个 Miro 董事会，并定义了我们希望技术轮次实现的目标/指南。在两节课中，每节课约 1 小时，我指导工程师们就他们自己作为候选人和面试官的经历进行提问和讨论。

我们工作坊的 Miro 板部分屏幕截图

正如您在图像中看到的，我提供了一些指导原则：

1. 面试的目的是让招聘经理了解候选人的技术能力和水平，而不是通过或不通过该候选人。
2. 创建一个可以跨学科工作的面试结构（即后端和前端面试不应有太大差异）
3. 候选人应该感到受到支持和欢迎。
4. 该过程应尽可能接近他们将要做的实际工作，而不是纯粹抽象的概念。
5. 最终结果应该使我们能够评估候选人的分析能力、编程能力、对编程原理的理解以及“代码沟通”技能。

在第一节课中，我们介绍了工程师自己的经历。这里的目标是将他们的想法建立在生活经验的基础上，并确保他们的框架从候选人的角度开始。每个人都有自己的便利贴来填写，在每个部分之后，我都会总结哪些观点似乎最普遍或最一致。

从那里，我们设计了基本结构，总时间约为 75-90 分钟。

对技术面试与他们正在评估的工作之间的当前差距进行公平、可模因的评估。

麦克杜格尔方法简介

在这个 90 分钟的面试结构中，我们评估候选人在现实场景中的能力，该场景优先考虑候选人的公平流程和技术评估的务实现实。

该结构可分为四个阶段：

1. 对候选人的介绍和他们的技术历史的简要概述（10-15 分钟）
2. 结对编程课程（30-45 分钟）
3. 反思/跟进问题（15 分钟）
4. 候选人问题和总结（10 分钟）

将每个阶段分开，我们共同集思广益，讨论每个阶段可以提出哪些问题，以及对于第 2 步（结对编程），我们如何最好地实现上述目标。

面试每个阶段的共享头脑风暴

这些阶段中的每一个都很重要，并且具有至关重要的目的。让我们依次看看每个。

关于命名的快速说明......

“麦克杜格尔方法”一词是我自己为应对这些技术面试挑战而领导、开发和记录的框架的标签。我选择了这个名字，它比重复说“我们的新技术面试方法”或“HelloBetter 更新的技术面试轮次结构”更方便。

然而，就像大多数 EM 认为的事情一样，这实际上并不是一个人的努力，这要归功于上述六位工程师的投入，以及 HelloBetter 首席技术官 Amit Gupta 以及 EM 同事 Leonardo Couto 和 Garance Vallat——他们为我提供了推动这一计划的自由。

第一阶段：候选人介绍和技术背景

这个阶段很常见，但重要的是要了解为什么大多数技术面试中存在这个阶段，而不是直接跳到编码练习或测验中。这个阶段只包括两名工程师，以避免候选人不知所措，同时也避免任何潜在的个人偏见发挥太大的作用。

简而言之，我们希望候选人尽可能放松。在这种情况下，我们永远不会有完全放松的候选人，但如果我们有任何方法可以减轻压力，我们知道这将带来更好的表现。当大脑处于战斗或逃跑模式时，它不会以最佳状态运行。

在这里，我们微笑，自我介绍，闲聊我们在公司的角色，甚至可能是关于我们自己的有趣事实。

然后，我们让候选人有机会用他们在大多数面试阶段面临的相同基本问题来介绍自己，这应该会为他们提供一些“轻松的胜利”：

• 介绍一下你自己
• 告诉我们您最近的工作经历
• 这个角色是什么让你兴奋？

…等等。

我们明确不希望这个阶段持续太久，同样是因为压力。

每个候选人进入技术轮次时都知道他们会接受评估，因此太多的闲聊会耽误他们最担心的部分。

因此，我们希望有足够的介绍性对话来“润滑车轮”，但又不要太多，以至于他们开始对困难部分何时真正开始感到紧张。对我们来说，我们将此限制设置为大约 10-15 分钟。

评估标准

对于这一部分，我们保持非常轻松和不关键，只问“候选人能否清楚地表达他们的技术背景/专业知识？这个阶段主要关乎心理安全和建立融洽的关系，因此完整的标准或反馈在这里不是必需的。

第 2 阶段：结对编程

这可能是您来这里阅读的帖子的一部分，所以让我们深入了解一下。

首先，我之前规定面试的编码部分应尽可能模仿真实工作。为此，我们需要三件事：

1. 与我们自己的代码库相似：相同的技术堆栈、相同的命名约定、相同的结构等。
2. 与我们真正解决的问题类似的问题。
3. 这种设置允许与真实工程师相同的灵活性和自由度。

McDougall 方法的核心是 40 分钟的技术结对编程评估，提供一个虚拟代码库，反映您的生产代码的一部分，其中包含不完整的功能、错误的实现和失败的测试。

在面试前一小时，候选人会被发送对存储库的只读访问权限，以便他们查看它并感受代码、它的结构等。但是，他们不应该在那个小时内积极实施任何事情。

进入面试后，候选人与其中一位面试工程师配对，他们一起研究如何解决（可能）难度不断增加的五个问题。

AI的“问题”

“可是安娜！”我听到你在屏幕后面哭喊：“这并不能解决人工智能作弊的问题！他们可以拥有另一个屏幕或另一个设备，并使用人工智能来解决问题！

好吧，我们通过欢迎新的机器人霸主成功克服了这一挑战，因为麦克杜格尔方法明确允许使用人工智能工具。

没错。 候选人共享他们的屏幕，并被告知（无论是在早期的沟通中还是在面试本身中）他们可以使用 Google、Stack Overflow、GPT、Copilot、Cursor 等任何他们想要的东西。最重要的是，他们可以向面试官提出任何他们喜欢的问题，而且应该。

在人工智能时代，我们想在技术面试中评估的不是工程师可以记住多少事实或算法，而是它们是如何工作的，以及他们是否理解他们在这个过程中创造了什么。

如果我们接受我们希望我们的工程师使用人工智能工具来提高生产力，那么我们就必须将人工智能的使用视为一种技能。如果我们的技术面试轮次是为了评估技术技能，那么就必须允许使用人工智能。

代码库的注意事项

在过去的几天里，我在 LinkedIn 上的几篇相关帖子中发布了有关 McDougall 方法的信息，并出现了一些误解。

因此，我想在这里稍作停顿，介绍一下这个阶段的一些注意事项。

做：

• 创建一个私有存储库，他们可以在本地克隆并轻松安装和运行。
• 使用从生产代码库中获取的一小部分代码或密切镜像它。
• 构建多个难度级别，例如在前端，您将从一个小的样式更改开始，然后构建一个需要完全重构的复杂、冗长的函数。

不要：

• 使用实际的生产代码。
• 使用候选人完成真实的门票（即免费劳动，不酷）。
• 包括任何机密或 API 密钥。
• 忘记提前一小时发送存储库。

关于最后一点，GitHub 还没有提供安排存储库访问的功能。我希望这篇文章以及随之而来的大量团队转向 McDougall 方法可能会激发他们将其作为一种选择。目前，做到这一点的唯一方法是在面试前一小时为自己（或其中一位面试工程师）安排一次提醒。

练习的技术分级

我在上面提到，我们为每个代码库使用五个不同的问题“级别”，例如，在级别 1 更改样式，在级别 5 进行完整的功能重构。

这些级别应大致对应于候选人的技术等级。我在这里包含一些基于 React 作为框架的示例：

• 1 级：实习生或应届大三学生（例如小造型变化）
• 级别 2：初级或低级中级（例如 onClick 事件未触发正确响应）
• 第 3 级：中级能力（例如，从 API 响应中高效准确地填充组件）
• 4 级：中高高级能力（例如处理复杂的状态管理和/或重新渲染错误）
• 5 级：高级+能力（例如，对复杂的冗长函数和/或低效组件架构进行全面重构）

为什么？因为同样，我们的目标不是看看谁是我们的“最佳”候选人，而是看看我们招聘的级别是否与候选人相匹配。这还可以潜在地避免候选人自己的水平过低的情况（同样，从统计学上讲，女性更有可能发生），并确保我们准确确定雇用她们担任什么角色，这反过来又确保公平的薪酬，并降低中长期人员流动率。

• 招聘初级学生时，您将从 1 级开始。
• 招聘中级工程师时，您将从 2 级开始。
• 招聘高级工程师时，您将从 3 级开始。

为什么是 40 分钟？

简而言之，因为时间足够了。

你不会在与他们结对编程的 40 分钟中对候选人有更多的了解。

事实上，我们的最终指南表明最少 30 分钟，最多 45 分钟，但 40 分钟似乎是最佳选择。

评审准则

我已经指出，编码能力和有效的信息来源（例如向同事提问、使用 Google/AI 等）是本轮的主要目标。然而，还要评估的是他们传达他们关于如何解决问题的想法的能力。

这里我们请面试工程师回答四个问题：

• 考生解决了多少次测试？
• 他们完成的解决方案的平均质量是多少？（1-5 级）
• 候选人能否清楚地传达他们的决定或方法？
• 您估计候选人处于什么水平？

我们还提供了一个自由文本区域，他们可以在其中更详细地介绍，例如关于使用的工具、任何主要错误或混淆点等。

尽管我很喜欢前三个问题的结构，但自由文本框通常是弹出最有价值信息的地方，例如：

• 在代码中发现非故意错误的考生（哎呀！
• 无法解释他们从 AI/Google/etc 获得的结果是如何运作的候选人
• 无法谈论自己思维过程的候选人

之后，我们进入与结对编程任务直接相关的下一阶段。

第 3 阶段：反思/后续问题

几乎与结对编程课程本身一样重要的是团队之后提出的问题。

在传统的技术面试中，编码练习本身应该揭示候选人的技术知识。在 McDougall 方法中，结对编程会话更多的是评估它们的工作原理。

在第 3 阶段，团队的工作是提出问题，让候选人展示他们对自己实施的内容的理解程度。

如您所见，此阶段本身有两个步骤。

反射

首先，我们让候选人反思他们的感受。我们知道紧张不安，紧张情绪高涨，候选人几乎从未在面试中发挥出最佳水平。所以，让我们给他们一个机会说出来。

在第 3 阶段，每个面试工程师应该问的第一个问题是：

你对那次练习有什么感觉？

这是一个开放性问题，可以让他们解释自己的情绪、担忧和恐惧;甚至是他们引以为豪的东西。从那里，可能会出现关于他们想以不同的方式做什么，或者他们想做哪些其他任务的问题。

后续问题

在最初的反思之后，接下来应该是后续问题。这些围绕着他们为什么选择某种方法，可能出现哪些陷阱，某些实现将/可以如何扩展或维护;或者可能有关命名约定、可读性或内存管理的问题。

在我们最新一轮的采访中，正是在这里，优秀的“实施者”的知识差距得到了揭示。这对候选人来说不一定是坏事，因为如前所述，将候选人与该职位相匹配是招聘经理的特权。

例如，如果您正在招聘初级或中低级别候选人，那么您不会期望在这里得到很多深入的答案，但了解招聘的限制将有助于制定他们在公司第一年的发展计划。

简而言之，我们不是在第 2 阶段的编码练习中评估他们的核心知识，而是让候选人专注于纯粹的实施，然后在第 3 阶段进行更深入的学习。

注意： 这是工程师在准确定义预期的分析/理解水平方面最需要 EM 指导的部分。我将在未来的招聘轮次中密切关注这一点，并提供一些更具体的指导，以便在未来的博客文章中更深入地探讨这一点。

评审准则

由于这一部分可能会发生很大的变化，我们选择保留一个关于候选人对反馈的开放性的问题，但同样主要依靠自由文本摘要供面试官描述他们的方法、优势、劣势等。

第 4 阶段：候选人问题和总结

我在这里没有太多独特的见解可以补充，但我想说这是任何面试的关键一步。我为工程师提供的一些指导方针是：

• 向候选人开放提问
• 当您认为他们已经问完问题时，再问一次他们是否还想知道什么
• 解释后续步骤（例如，“我们会将反馈传递给 Anna，她将在接下来的几天内与您联系”）
• 以微笑结束并感谢候选人抽出时间

评审准则

与第 1 阶段一样，我们保留了文本信息的评估标准，其中包含他们提出了哪些问题以及任何最终注释。

最终反馈

除了上述领域和问题外，我们的人力资源软件 Personio 还为每位候选人提供“消极”、“中立”和“积极”选项。

我们对最终评级的说明如下：

• “积极”应该反映与候选人的整体良好体验，而不是您认为他们在技术上合适。
• “中立”应该是指候选人有礼貌，但可能是尴尬或缺乏凝聚力、一致性或良好的沟通能力。
• 只有在存在严重的文化或人际冲突（例如性别歧视、种族主义、攻击性、作弊等）时才留下“负面”。如果您认为他们的级别低于广告职位，请不要选择“负面”。

简而言之，最终评级应该作为给我们“氛围检查”的一种方式。就我个人而言，意识到围绕文化评估的一些问题，特别是对于神经多样性候选人，如果满足其他标准，我会接受任何具有中立或积极的候选人。

总体评价领域

最后一个字段是一个开放文本字段，每个面试工程师都可以在其中总结他们的想法。在我们的 Confluence 文档和我给工程师的培训课程中，我都强调需要注意该领域的优势和劣势。如果有人真的无法完成练习或完全不合格，我也希望工程师在这里概述这一点。

麦克杜格尔方法的结果

将我们之前的列表缩小到我们可以通过技术轮解决的三个挑战，我们可以清楚地看到结果：

雇用时间长

上述所有更改导致我们的“填补天数”指标是我们最新一轮招聘中平时的 30%。自然，这个时间等于金钱。这一指标受到简化的面试流程、与招聘人员的密切合作以及接受培训以提交可预测的标准化评估的工程师的影响。

除了通过快速推进面试过程节省的时间外，我们还节省了时间和精力，因为必须将候选人留在过长的管道中进行上下文切换：这对招聘经理和面试工程师来说都是如此。

候选人使用人工智能作弊或歪曲自己的能力

尽管这在技术上仍然是可行的，但编码阶段与分析阶段的分离使得使用 AI 变得更加困难。问题基于感觉、假设和偏好，其中许多没有正确或错误的答案。

在结对编程练习中公开使用人工智能的能力消除了将其用作工具的“羞耻感”元素。

一轮技术面试，感觉更像是记忆力测试

作为候选者，麦克杜格尔方法不需要零记忆或临时抱佛脚。相反，实用的编程基础知识成为关键。如果您在过去三年中一直在一家公司担任中级候选人，那么无论您最近多久反转了二叉树，您可以背诵多少 JavaScript 串联怪癖，或者您可以记住多少 HTTP 状态代码，您都可能会被 McDougall 方法评为中级候选人。

工程师在面试中推荐反对候选人时感到困惑，但该候选人还是被录用了，反之亦然

这种方法的重点是平衡候选人并确定他们的优势和劣势，而不是根据面试工程师的假设给他们一个通过/失败的分数。

候选人可能在技术上很强大，但与技术上更有缺陷、优秀的团队合作者候选人相比，文化权衡可能不值得。

此外，在方法本身中，实施者和知识持有者之间存在差异的空间。我们都在两者之间取得了平衡，这种结构使我们能够看到谁在哪里强大，以及哪些领域仍需要建设——这对于为新创业者制定发展计划至关重要。

最后，招聘经理的工作是平衡这些考虑因素，而麦克杜格尔方法为面试工程师提供了充足的机会来提供他们的反馈，并准确了解候选人的技术能力，供该经理权衡。

未来行动要点

还有一些方法可以改进这种方法：

1. More clearly define the technical criteria for Phase 3: since this is highly dependent on the role, it is hard to devise concrete questions in a standardised format here
2. More precise assessment criteria for Phase 3: as per the above, I think the variability in this phase means that we need to be open to more individualised assessment criteria here.

These two points lead me to believe that a new framework for the devising and assessment of this phase is required. For example, through some sort of question matrix or pre-hiring questionnaire to assess the relative importance of different technical insight areas and levels of knowledge per position.

Documentation and Training

After developing this method, I created detailed documentation for the engineers before also guiding a training session for those who I knew would soon be interviewing candidates.

• A Confluence documentation detailing the method similar to the details in this post
• A position-specific doc outlining the expectations for that precise role and how it related to the process

在 90 分钟的培训课程中，我不仅涵盖了您在上面阅读的所有信息，还让每位工程师练习了面试的介绍和结尾，提供了一些关于如何提供友好氛围的提示和反馈。

号召性用语

让我们让事情变得简单。我的行动号召是这样的......

试试看。

把它带到你的 EM 或你的团队那里，谈谈它。有什么优点和缺点？可能会错过什么？

如果这引起共鸣，请与您的团队分享。我特别想听听你有什么不同意见，无论是在评论中还是在LinkedIn上，我定期在评论中发布有关工程管理、技术职业以及我自己对该行业和健康技术的观察，尤其是健康技术。