通过技术问题框架识别前5%的候选人
在这篇文章中，我分享了我作为一名经验不足的数据科学招聘经理犯的一个错误，以及它如何改变我进行技术面试的方式。我还通过一个数据科学面试提示的示例，展示了更强的候选人与较弱的候选人在解决问题上的不同方法。虽然我将讨论重点放在数据科学上，但我大部分的见解和建议对于任何技术角色都是相关的，包括软件工程、数据工程等。
但首先，让我简单介绍一下我自己的背景。
我已经在软件工程和数据科学/机器学习领域工作了大约九年。我曾在各种规模的公司工作过，最大的是Wayfair（13,000名员工），最小的是我的现任雇主Fi（约100名员工），我是数据副总裁。我现在正接近一个拐点，我的职业生涯一半时间是作为个人贡献者（IC），一半时间是作为经理/总监/副总裁。在后半段时间里，我建立或继承了从2到15人不等的团队。在那段时间里，我招聘了大约20人，进行了数百次面试，设计了无数次面试流程。
在我担任招聘经理的时间里，我成功地招聘了很多人，但也犯了一些错误。例如，在我作为招聘经理的职业生涯早期，当我首次被委以从头开始构建面试流程的责任时，我犯了一个最大的招聘错误。我花了另外一年或两年的时间才完全理解我犯的错误。但一旦我能够清楚地表达出来，我知道这是可以避免的，并且能够采取措施确保不再犯同样的错误。
这篇文章就是关于那个错误，以及我避免再次犯错的做法。
我的招聘错误
2019年，我从高级机器学习工程师晋升为首席数据科学家，担任了管理角色。我的团队希望构建新的建模应用程序，这些应用程序需要与我之前构建的模型和集成不同的模型和集成。由于我最近担任了管理角色，我没有时间自己构建所有所需的基础设施。因此，我开始寻找一名高级数据科学家来帮助构建和维护新的模型和集成。
面试流程
我设计了一个面试流程，包括一个招聘经理筛选、一个回家项目和几个小组面试。除了跨职能面试外，所有的面试都是技术性的，涉及一些形式的机器学习、数据工程或软件工程挑战和设计问题。几个月后，我们找到了理想的候选人。
新员工的前几周进行得很顺利。一旦他们熟悉了技术栈、团队成员和工作流程，我给他们分配了一个更大的项目。
症状出现
在完成分配的项目的几个星期后，我注意到他们的任务所花的时间比预期长。因此，我每周额外花时间与他们一起确保事情保持在轨道上。但不幸的是，情况没有改善。几乎每次我们会面讨论进展和下一步时，似乎都没有取得任何进展。相反，他们会提出一些新遇到的技术障碍，从他们的角度来看，需要解决才能继续前进。我记得当时感到沮丧，因为我很难理解他们提出的所有技术障碍为什么如此相关，因为它们似乎突然出现。
我记得当时项目已经进行了两个月，本来预计只需要两周完成，但我们仍然没有一个可用的解决方案。更糟糕的是，我们甚至没有一个明确的完成时间表。
潜在问题
现在我已经管理和招聘了几年，并且见证了许多新员工的成功和失败，我能够明确指出潜在的问题以及我犯错的地方。
潜在问题是他们缺乏成功所需的关键技能。表面上看，他们似乎缺乏技术能力，因为他们经常遇到无法快速解决的技术障碍。但事实并非如此。事实上，他们的技术能力非常出色。
相反，他们缺乏理解技术应用和业务需求之间连接的能力，这阻止他们知道何时以及如何权衡取舍。这表现为不可逾越的技术障碍，每一个都可以通过简化问题陈述来避免。
例如，他们经常遇到的一个挑战是由于他们处理的数据集的大小。但每次他们提到这个问题时，我都会建议将数据集缩减到我们感兴趣的前三或四个特征，并仅筛选出可能相关的记录。这样做将会将整个数据集减小到原始大小的不到0.5％，这将避免由于数据量而引起的任何问题，并为我们提供整个数据集80％的增值。但是每次我建议这样做时，很明显他们没有考虑过这一点，尽管我一再提起。
技术问题框架
简而言之，新员工在同时维持对业务背景和技术背景的深入理解方面遇到了困难，因此他们设定的技术任务往往比实际需要的复杂。换句话说，他们在技术问题框架方面存在问题，即将业务目标框定为技术目标的能力，以及理解一组需求代表的潜在业务目标的能力。
对于那些不熟悉技术问题框架或数据团队的典型工作流程的人来说 – 通常，需求是由产品经理（PM）或经理/技术负责人提供的。但即使在提供给IC的情况下，需求也永远不会完全详尽。因此，IC必须能够理解导致这些需求的目标。如果他们不能自己做到这一点，那么他们将需要由他们的经理或PM密切监视。这限制了团队的可扩展性，并且通常会导致IC与他们的经理/PM之间的摩擦。
当我反思这个场景时，很清楚我犯了什么错误 – 我没有构建一个评估技术问题框架的面试，而这个技能是他们在工作中成功所必需的。一旦我意识到这一点，我开始尝试将其纳入我的面试流程中。幸运的是，我发现最有效的方法只需要进行一点调整。
调整面试
下面是我所做的不同之处。
至少在一次技术面试中，我将技术任务嵌入到一个需要完全理解附加上下文才能充分解决问题的实际业务场景中。
除了评估技术能力外，这种调整后的面试还评估候选人根据需求推断项目的实际意图，并确保在设计技术解决方案时实现这一意图的能力。
下面我将介绍一个不评估技术问题框架的示例面试，并讨论一个强大的解决方案是什么样子。然后，我将展示同样的面试，但进行了技术问题框架的调整，并展示它如何修改被认为是一个强大解决方案的内容。
您可以在这里找到我用于此次面试的原始数据集。您也可以在这里找到配置为Kaggle笔记本的面试提示。
示例1：数据科学建模面试无技术问题框架评估
这是没有任何技术问题框定评估的面试提示。
################################################ 面试中没有技术问题框定评估的部分。 ################################################# 我们为您提供了一个数据集#，其中包含与心脏骤停（心脏病发作）相关的患者健康信息#。每个记录代表一个因为胸痛而#来急诊室（ER）就诊的患者。每列#对应于他们到达急诊室时采取的测量#，包括他们所经历的胸痛类型。数据集还包含一个#二进制列，指示患者在急诊就诊后48小时内#是否发生心脏病发作。import pandas as pddf = pd.read_csv(f"{filepath}/heart.csv")display(df.head(5)# 您的任务是构建一个模型#，根据提供的输入预测候选人是否会#发生心脏病发作。def predict_heart_attack(row): """ 接受一个心脏病发作数据集的行。 返回0或1作为预测值。 """ # TODO pass
我过去常在实时环境中进行这样的面试，这样可以方便地使用一个小而干净的数据集。数据集很小（303行和13个输入），相对干净，所以有任何机器学习经验的候选人都可以轻松构建一个分类器。
评估
较弱的候选人很容易辨认出来，因为他们通常在规定的时间内都很难构建一个基本的模型，更不用说一个好的模型了。作为面试官，更微妙的任务是从“好”的候选人中辨认出“优秀”的候选人。除了在短时间内展示构建一个可行的分类器的能力之外，较强的候选人通常通过以下方式展现出与众不同：（1）采取迭代的方法——他们快速让某些东西起作用，然后改进它；（2）做出有意识的决策。例如，当我问他们为什么选择特定的性能度量来评估模型的性能时，他们会有一个具体的答案。较弱或经验较少的候选人会给出答案，但没有任何真正的理由。
示例2：带有技术问题框定评估的数据科学建模面试
这是同样的面试问题，但包含了一个嵌入的业务场景，因此它包括了技术问题框定作为被评估的一部分。
################################################ 面试中包含技术问题框定评估的部分。 ################################################# 急诊室（ER）接收到#大量经历胸痛的患者，这是心#脏病发作的症状。显示出其他#心脏病发作症状的患者应该#被优先考虑（快速通道）进入#急诊室候诊室，以减轻#心脏病发作的影响，或#完全避免它。## 平均而言，急诊室可以快速通道#20%的经历胸痛的患者，让他们#跳过患者队列。目前，急诊室的政策是#快速通道任何经历2型胸痛（非典型#心绞痛）的患者。这在数据集中对应于#`df['cp'] == 1`的值。急诊室的工作人员#认为他们现有的政策不够完善，并要求您#对这些患者数据进行分析，以制定一个更好#地优先考虑高风险患者的政策。# #我们为您提供了一个包含与#心脏病发作相关的患者健康信息的数据集#。每个记录代表一个因为胸痛而#来急诊室（ER）就诊的患者。每列对应于#他们到达急诊室时采取的测量#，包括他们所经历的胸痛类型。数据集还包含一个#二进制列，指示患者在急诊就诊后48小时内#是否发生心脏病发作。import pandas as pddf = pd.read_csv(f"{filepath}/heart.csv")display(df.head(5)# 您的任务是使用数据集构建一个#优于急诊室现有政策的快速通道政策。def fast_track(row): """ 接受一个心脏病发作数据集的行。 返回0或1作为决策以进行快速通道。 """ # TODO pass请注意，问题的技术方面保持不变 – 使用完全相同的数据集和解决方案签名。但现在有额外的信息改变了理想解决方案的特征。
新问题陈述
新增的业务背景引入了两个新信息，候选人在开始解决方案之前需要了解。第一个是只能有20%的患者可以快速通道。这相当于60.6名患者，或者我们取整后为61名：
.20 * len(df) # 输出 60.6因此，我们通过快速通道可以“挽救”的患者的最大数量是61，因为急诊室无法快速通道超过这个数量。
急诊室提供的第二个新信息是，急诊室有一种基准策略，需要超过该策略才能考虑采用新政策。该基准策略可以正确预测41例心脏病：
# 急诊室的基准策略是快速通道# 任何有第2型胸痛的患者，# 对应`df['cp'] == 1`。所以急诊室的基准# 策略是在# df['cp'] == 1时返回1，否则返回0。( df.groupby(['cp'])[['had_heart_attack']] .agg(['mean', 'count']))
.82 * 50 # 输出 41将新增的限制条件（61个快速通道）与超过基准（41个正确预测）的目标结合起来，我们可以将新目标定义为：找到一个分类器，其在k=61的情况下具有大于41的召回率。
弱候选人
在技术问题构建方面表现较差的候选人会忽略这两个信息，直接进入解决方案模式。这通常会导致两种次优的解决方案之一：具有高精度但召回率等于或低于41，或者具有很高的召回率，但精度太差，前61名快速通道患者不会有超过41例的心脏病发作。作为面试官，如果我看到他们走错方向，我会给予提示来引导候选人。一些候选人会注意到我的提示并正确调整方向，而其他人则仍然努力找到正确的问题。
强候选人
在技术问题构建方面表现较强的候选人会以不同的方式处理问题。他们不会从一开始就立即进入解决方案模式，而是花时间仔细阅读提示，通常会多次阅读，以确保他们理解背景。
接下来，他们会做一些与成功密切相关的事情，这也是我密切关注的：
最好的候选人在开始之前会写出他们的方法，并问我（面试官）是否合理。
当我看到这一点时，我非常高兴。为什么呢？因为如果他们加入我的团队，这正是我希望他们做的。我希望有人在开始之前能够预先表达他们的计划，并且还能意识到在开始之前向我请教。尽管这需要更多时间，但它减少了需要在面试过程中改变方法的需要，因此确保他们剩下的时间得到了很好的利用。
能够准确表达问题的候选人通常也能够解决挑战。这并不令人意外，因为打败基准并不是很困难。例如，即使是以下简单的基于规则的解决方案也能击败基准：
def fast_track(row): """ 一个非常简单的解决方案，但仍然击败了基准。 """ # "cp" 是胸痛的列。 if row['cp'] == 2 and row['sex'] == 0: return 1 elif row['cp'] == 1 and row['sex'] == 0: return 1 else: return 0# 检查性能df['pred'] = df.apply( lambda row: fast_track(row), axis=1)top_k_preds = df.sort_values('pred').tail(61)recall_at_k = len( top_k_preds .query('had_heart_attack == 1') .query(pred == 1))print(f"Recall@61 = {recall_at_k}")# 输出 Recall@61 = 50但如果候选人能够清晰地陈述问题并将其解决到最大程度（k=61时完美召回），那么额外加分肯定会给予。
面试技术问题框架的好处
面试技术问题框架的主要好处是，通过面试并被聘用的人能够更加独立地进行工作。因为他们能够内化他们被赋予的改进目标，他们可以减少他们的经理以及产品负责人所需的额外工作量。这对于提升技术团队的影响力至关重要，特别是在小型组织中，那里几乎没有项目经理的支持，而经理们被期望是IC（个体贡献者），因此他们的精力有限，无法同时监督大量项目。
比如，我们在Fi的数据团队一直保持着非常小而敏捷的规模，这在很大程度上是因为我们只雇佣具有强大技术问题框架能力的人才。目前，我们只有四个人的团队（很快将增加到五人），但我们为100多个业务需求提供了所有与数据相关的服务，并拥有所有的ETL流程、数据仓库设计和维护、Tableau报告、深入分析和根本原因分析、机器学习和预测建模，以及最近的新功能开发的研发工作。我们涵盖的领域包括企业的方方面面——财务、市场营销、客户体验、工程、硬件、固件、运营和产品。我们能够承担如此多的工作并涵盖如此多的领域，是因为团队中的每个人都擅长将一个模糊定义的问题映射到一个技术问题陈述。
即将推出
敬请期待未来一篇文章，我将在其中介绍如何提高您自己的技术问题框架能力，以及如果您是一名经理，如何提高您团队的能力。