反对白板编码的心理案例

为什么白板编码面试没有我们所有人想象的那么有效。

“白板编码”是大多数软件开发人员都会熟悉的采访实践。 它最初的形式涉及面试官提出一个问题,例如“编写一个将字符串中重复的字符打印出来的算法”,而候选人必须在白板上编写代码,以便面试官大声解释自己的思维过程。 现在,有了诸如Codeinterview或HackerRank之类的应用程序,这些应用程序可使求职者在计算机上打字并实际运行代码以测试其解决方案。 对于更好还是更坏,我们仍未达成共识:能够打字更自然,但是在白板上很容易原谅的语法错误又困扰了我们……

本文的目的是在软件开发人员访谈中检查白板编码的问题,并提出一种更好地预测工作成功的替代方法。 出于该论点的目的,我将更普遍地使用术语“白板编码”来指代以下条件的实践:

  1. 面试官要求候选人写出代码来解决问题。
  2. 候选人必须解释自己的思维过程,并在解决问题时提出问题。
  3. 候选人将自己的解决方案写在与面试官同一个房间中,而不是私下里。

让我们谈谈我们的问题。 实际上有两种类型的问题。 这是我们许多人已经看到的“洞察力”问题的示例:

画出穿过所有点中间的四条直线,而不用把铅笔从纸上移开。

这是一个“分析”问题:

三张纸牌面朝下摆在您面前的桌子上。
在皇后区的左边有一个千斤顶。
锹的左边有一颗钻石。
在心脏右边有一个国王。
在国王的右​​边有一个锹。
什么卡?

第二种问题对我们逻辑上的人们来说很自然。 诸如此类的分析性问题要求我们采用提供给我们的信息,并通过合理的流程进行处理才能得出答案。 我们也很容易向提出问题的人解释我们如何获得答案。 例如,这就是我的想法:

”“ 在心的右边有一个国王,在国王的右​​边有一个锹。 好的,那必须意味着最右边的一张牌是黑桃,国王在中间。 由于心脏的右边有一个国王,因此左卡必须是心脏,并且锹的左边有钻石,因此中间的卡必须是钻石。 由于皇后区的左边有一个插孔,因此左卡为插孔,右卡为女王。

因此答案是,从左至右:黑桃皇后钻石之王杰克之心。

ew 还不错 这是一个相当简单的问题,我可以很容易地解释我的思考过程。 实际上,我们经常发现自己在大声说话以解决这些类型的挑战。 这种类型的问题称为“三段论”。 分析族的其他成员是密码,算术和消除过程。 这些问题通常需要您理性,逻辑的头脑来解决,而您的头脑中的同一部分才能验证解决方案。 假设我只是为您提供上述关于卡问题的解决方案,而没有任何解释:您将不得不自己做一些工作,以确定它是否是正确的解决方案。 您可能会遍历这四个语句中的每一个,直到找到一个不适合我的解决方案的语句,或者在没有矛盾的情况下宣布我的解决方案正确。 算术问题甚至更糟—如果我告诉您57 x 86是4942,则必须自己解决整个问题,然后才能肯定地提供4902的正确解决方案。

但是洞察力问题呢? 这些类型的问题使我们在花了整整三个小时就取得了零进展之后,全力以赴。 如果我第一次尝试上述问题时尝试解释自己的思维过程,听起来会像这样:

好的,四行。 不应该太难。 我会在这里,这里画一条线,哦,等等,那行不通。 怎么样呢……不,那也不行。 我可以以“ N”形绘制三条线,这些线在其两侧相交吗? 不,他们必须经过每条线的中心。 这有什么窍门吗? 这不可能。 哦! 怎么样-没关系。”

并且持续了大约20分钟。 我诅咒这些点,吃了一个三明治,感到失败。 最终,在胜利的“ a-ha!”时刻,我知道了解决方案。 在我的脑海中,这一天很清楚:

看到此解决方案,您可以验证其正确性,而不会产生太多的认知负担。 如果您像大多数人一样,您会立即意识到这是一种解决方案。 您甚至不必询问是否所有点都已连接,或者实际上是否有四条连接的线。

盖·克拉克斯顿(Guy Claxton)是世界知名的心理学研究人员,专门研究学习和创造力。 他比我更了解头脑。 读他的著作,特别是他1997年的著作《黑脑,乌龟思维》,有助于我的直觉,即洞察力问题与分析性问题截然不同。 这本书的中心思想是我们进行几种不同类型的思考。 我们都熟悉我们甚至无法追踪的超快速反应(例如触摸火炉后反冲),并且我们也熟悉典型的以大约对话速度进行的刻意思考。 正如克拉克斯顿(Claxton)所说,这种思维方式是“找出问题,权衡利弊,建立论据和解决问题”。 我们通常将这种类型的思维称为意识思维。 我们对此非常熟悉。 这种思维,即“大脑”,很适合分析问题。 如果我们特别擅长,我们就是“智能”。但是思考的层次更深,思考的速度更慢,更沉思。 这是我们在思考问题而不是共同解决问题时所使用的思维类型。 这就是“乌龟思维”。我们通常将其称为无意识思维。 这种类型的思维有助于创造力,甚至智慧。

使用克拉克斯顿的野兔大脑和乌龟思维模型来描述有意识和无意识的思想,我们可以为我们关于洞察力问题和分析性问题的讨论提供信息。 纯粹的分析问题是利用野兔的大脑。 纯粹的洞察力问题利用了乌龟的思想。 实际上,问题位于一个频谱上,而不仅仅是一个问题,但通过更相似的类型来识别问题很有用。 我在上一节中指出了洞察力和分析问题之间的一些区别。 尤其是:

  1. 解决它们的过程非常不同,并且
  2. 对解决这些问题的过程进行叙述非常不同。

对于卡排序问题(分析),我必须共同努力解决,在此过程中取得了明显的进展,并且从逻辑上得出了一个解决方案。 我的过程很清楚,在解决问题时轻松谈论我的思考过程。 大声说出来实际上有所帮助,因为它使其他想法在我脑海中回弹,并使我更加专注。 但是,点对点连接问题(洞察力)完全不同。 我只能将自己的过程描述为“猜测和检查”,因为我确实没有做比这更聪明的事情。 没有明显的进展-观察者不能仅仅看了一眼就知道是在问题上花费了几分钟还是几个小时(除了可能数了椅子下面弄皱的纸),而且我是否试图叙述我的问题。思考过程,对观察者来说并没有多大用处。

请注意,如果已选择,我可以尝试更快地解决卡订购问题。 当我们承受时间压力时,野兔的大脑可能会被踢得过速。 但是,当您强迫乌龟思维敏捷时,它会不喜欢它。 正如Teresa Amabile,Constance Hadley和Steven Kramer在他们的《哈佛商业评论》案例研究“枪下的创造力”中发现的那样,时间压力严重影响了工程师获得技术见解的能力。 克拉克斯顿(Claxton)的工作表明,缓慢思考对创造力至关重要,如果我们追求质量,我们绝不能强迫有洞察力的思考快速进行。

Jonathan Schooler,Stellan Ohlsson和Kevin Brooks在1993年的一组实验中比较了洞察力和分析问题。 他们总结了大量证据,表明解决洞察力问题涉及无意识且难以叙述的思维过程。 洞察力问题利用了乌龟的思想。 他们研究的目的是确定口头表达是否实际上会削弱洞察力解决问题的能力。 结果很明显:要求参与者在解决这些问题的同时对其过程进行叙述会大大降低他们的成功率。 研究人员发现,对于分析问题,无论是否要求他们进行口头表达,受试者大约70%的时间都能找到正确的解决方案。 对于洞察力问题,没有口头表达的受试者大约80%的时间找到了正确的解决方案。 但是,口头表达的对象的成功率下降到了惊人的55%。

为什么会这样? 在对他们的论文的讨论中,Schooler,Ohlsson和Brooks建议“语言化破坏了洞察力问题特有的某些过程。”由于Claxton的工作,我们现在有了模型来解释这一点:野兔的大脑的注释颇具破坏性。乌龟头脑的焦点。

我经历的最新面试过程如下:

  1. 招聘人员的电话屏幕(非技术问题)
  2. 与高级开发人员进行1小时的视频通话(技术知识+编程访谈)
  3. 一天的现场采访:
    一种。 与两名资深开发人员进行的1小时编码面试
    b。 1小时设计与架构访谈,团队负责人和高级开发人员
    C。 与工程总监进行1小时的非技术面试

以下是两次编码访谈中的问题:

  • 访谈2:编写一个功能,以在适当的位置反向链接列表。
  • 访谈3a:设计和实现可存储大量字符串的数据结构。 编写一个insert方法和search方法,它们采用输入字符串来搜索或插入结构。 两者都必须在时间上与输入字符串的长度成线性关系。

这些问题似乎具有分析和洞察力问题的属性。 考虑解决方案时,您将面临许多死胡同,一旦出现问题解决方案,如果再次提出问题,您可以轻松地重现该解决方案。 通常,这些问题的定义不明确,应聘者必须向面试官提出澄清问题,以证明他们能够胜任工作中的这类问题。 但是,一旦有了解决方案的想法,实施和解释就类似于一个更具分析性的过程。 将您的想法从头脑转换到白板(或代码编辑器)是一个简单的逐步过程。 您的解决方案也可能对面试官来说不是很明显。 您将需要解释它的工作原理。 解释解决方案的有效性是一个逻辑,麻烦的过程。

看来这些问题可以分为两个部分:对解决方案的思考是洞察力部分,而对它的实现/解释则是分析性部分。 我们可以考虑我在上述问题上的经验来对此进行测试。 当被问到链表问题时,我开始思考解决方案,并将我的想法写在一张纸上。 我被要求大声思考,但我的叙述断断续续,包含很多“等待,将无法工作”,以及“也许我会尝试一下。”我最终沉默了一下,思考了一下,留下了一些空气中尴尬的紧张感。 经过几分钟的思考,我乌龟的脑子想通了。 解决方案在我脑海中非常清晰,我的野兔大脑接管了。 我在两分钟内编写了十行代码:

  void reverse(Node * head){ 
节点* next;
节点*上一页;
节点*当前=头;
while(当前!= NULL){
下一个=当前->下一个;
当前->下一个=上一页
上一页=当前;
当前=下一个;
}
头=上一页
}

我解释了为什么我轻松做出选择,并说明每一行。 我解释了为什么该解决方案是正确的,它可以很好地处理边缘情况(例如传递NULL),并且只能与单链表一起使用。 我解释说它不需要返回新的头,因为调用者已经有了它的引用。 我写了一些测试,解释了每种情况下要测试的情况。 问题的后半部分非常清楚地是分析性的,我的兔子大脑对此没有任何问题。 如果您喜欢冒险,请尝试自己解决第二个面试问题,并注意当您的思维从见解模式转换为分析模式时。

尽管我在这里只提到了两个示例,但是您可以在大多数编码面试问题中看到类似的结构。 由于编码面试涉及时间压力和口头表达,因此您可以了解为什么我很难解决链表问题的洞察力部分。 现在,我们陷入了一个难题:编码面试的条件会干扰解决这些问题的洞察力部分。 这意味着在这些面试中的表现并不是实际技能的可靠指标。

有一家公司在不断改进面试流程方面的承诺比其他公司出色:Google。 关于公司的两本书介绍了这一部分:执行董事长兼前首席执行官埃里克·施密特(Eric Sc​​hmidt)和前产品高级副总裁乔纳森·罗森伯格(Jonathan Rosenberg)的“ Google工作原理”(2014),以及谷歌人员运营高级副总裁拉斯洛·博克(Laszlo Bock)的“工作规则!”(2015年)。 )。 自公司成立以来,Google的采访过程经历了多次迭代,从硅谷最令人恐惧的公司之一到其最受尊敬的公司之一。

Google曾经因其脑筋急转弯问题而臭名昭著,例如“波音747可以容纳多少个高尔夫球?”或“为什么要盖人孔盖?”,埃里克·施密特和乔纳森·罗森伯格说,他们喜欢这些问题有两个原因:首先,他们看看候选人是否可以解决一个复杂的问题,其次,他们看看候选人是否喜欢这个问题。 乐于解决难题的能力是Google喜欢雇用的“智能创意”的基本特征。 但是,这些问题在最近几年已经中止。 施密特(Schmidt)和罗森伯格(Rosenberg)提到,许多答案最终都在线上出现,从而违背了目的。 博克在他的书中提出了令人信服的理由将其删除:

“(脑筋急转弯)几乎没有能力预测候选人在工作中的表现。 部分原因是任务无关紧要……部分是因为预测工作绩效的流体智能与脑筋急转弯等洞察力问题之间没有相关性,部分原因是无法区分天生就是聪明的人,还有刚练过技巧的人。”

像上面提到的那些难题是纯粹的洞察力问题。 编码面试题不是。 我们显然不能将编码问题与脑筋急转弯归为一类,但是我们还没有解决上一节中概述的难题。 为此,我们需要检查与工作成功最密切相关的评估类型,并查看我们是否可以提高编码面试的预测能力。

弗兰克·施密特(Frank Schmidt)和约翰·亨特(John Hunter)在1998年进行的一项大型分析发现,某些选择方法要比其他方法好得多。 我在下面列出了他们的发现之一:

常规心理能力测验,工作样本测验和结构化面试是与工作成功最相关的措施。 拉斯洛·博克(Laszlo Bock)说,即使这些都不完美。 您与他人的协作程度,适应不确定性以及学习的能力也会影响实际的表现。 在Google,所有技术候选人都要经过几次结构化面试和几次工作样本测试,通常是带回家的编码挑战和几次编码面试的结合。 编码面试问题通常涉及一些不确定性,但是“ Google的工作原理”和“工作规则”都没有提及任何会直接测试开发人员在团队中工作或学习的能力的面试实践。

让我们回顾一下:

  1. 典型的编码访谈包含一些对问题有深刻理解的问题,这使他们在访谈的条件下无法成功预测。
  2. 带回家的编码挑战可以使候选人保持不间断的关注,但不会给面试官提供实时评估候选人的思维过程的机会。

考虑到这一点,我将建议一种面试技巧,以我的经验,该技巧可以强烈预测我所雇用人员的工作成功。 我对解决方案的建议是对编程的修改版本。

候选人与开发伙伴和标记匹配。 合作伙伴应是与候选人同等或更有经验的开发人员。 标志可能是经理,但Google的见识表明,应该是与候选人所从事的团队无关的人,主要是为了减少偏见。

然后,候选人和合作伙伴开始进行一个小型编程项目。 该公司在这里具有很大的灵活性。 就像进行结构化面试一样,这个小项目应该花一些时间让团队进行开发。 它可能是设置一个简单的API,或者可能是为Web应用程序编写一个主页。 您可以让候选人从头开始,也可以从入门代码开始。 他们可能会被要求选择图书馆来完成工作,或者您可以挑战他们不使用图书馆就可以做到。 这里的重点是项目的每个部分都测试特定的东西。 由于全栈Web开发是我的游戏,因此,我将举一个与招聘Web开发人员使用的示例类似的示例:


时间:1小时

说明:完成任务0,然后使用剩余时间完成您认为可以完成的其他任务。 您可以使用互联网查找您不知道的任何内容。 您可以在合理的范围内使用库(例如,可以使用Express,Django或Laravel之类的框架),但是要注意,与小型项目相比,这些库有时会花费更多的时间来建立。 记录您采取的任何捷径或所引入的技术债务。 如果您遇到困难,您的伴侣将为您提供帮助,并在此过程中填补您的知识空白。

任务0:从头开始,编写一个简单的Web服务器,该服务器将返回带有文本输入和提交按钮的页面到客户端。 当用户单击按钮时,它将把输入中的文本发送到服务器。 服务器应将输入记录到控制台。 这需要10到20分钟。

额外任务:

  • 让应用程序将消息存储在数据库(后端)中,而不是登录到控制台
  • 使用CSS使登录页面看起来更好(设计)
  • 使应用程序在Docker容器中运行(基础结构)
  • 描述如何将应用程序部署到云主机并为数百万个客户端扩展(架构)
  • 使点击提交按钮使用fetch / AJAX或类似方法,以使页面不刷新(前端)

与标准面试相比,此过程具有以下优点:

  1. 它显示了候选人与他人合作的能力
  2. 面试官看到候选人在被困时的表现
  3. 它显示了候选人如何研究和学习
  4. 该项目最大程度地减少或消除了见解问题
  5. 您了解候选人对特定技术的了解程度
  6. 所有这些操作的费用与标准面试相同:1小时,两名面试官和一台笔记本电脑

公司可以为任何事物创造这样的挑战。 QA候选人可以编写测试并寻找现有应用程序中的错误,信息安全候选人可以评估安全漏洞,前端候选人可以将现有应用程序迁移到新框架中,清单不胜枚举。 这完全取决于您要测试的内容。 最重要的部分是您与团队一起花费时间来决定要评估的内容,并为此制定评分标准。

此技术是评估开发人员实力的工具箱中的附加工具。 将其与带回家的编码挑战,结构化的面试和一般智力测验相结合,您将拥有最准确的候选人选择方法之一。 建立一支为应对明天的挑战做好准备的团队需要坚定地致力于今天的招聘过程。 你愿意吗?