乔尔测试(Joel Test)的第11个问题是:“新应聘者在面试中是否写代码?”。要求新候选人在面试中编写代码并做出决定的论点是什么?
乔尔测试(Joel Test)的第11个问题是:“新应聘者在面试中是否写代码?”。要求新候选人在面试中编写代码并做出决定的论点是什么?
Answers:
我看不到缺点。面试包括很多部分,应征者应被“批准”多次。
我每周采访约10个人。我真的非常非常感谢HR完成了所有背景工作并向我提供了很多笔记。当他们到达我的时候,是时候让我为他们的考试打分了。
测试完全取决于位置。通常,我尝试探究:
通用编程技能。您可以有效地使用运算符吗?您能设想一个数字系统的基数不是10吗?
您知道如何做我们雇用您的工作吗?
评估您对列出的任何开源项目的贡献
我尽量保持简短有趣。当我进入办公室时,我会抓住答案,将其查找,然后进行第二次面试。要被录用,您通常必须完成三个面试。
我还会评估您与接待您的团队的融合程度。该团队依靠我来有效地做到这一点。
以元形式回答问题是一回事,而实际生成代码则是另一回事。如果要雇用您,我真的需要看到您产生代码。
如果您打算雇用一名杂耍演员,那么让他为您做杂耍会很疯狂。或您有试奏的音乐家。否则,您将得到令人敬畏的“大师” K-strass之类的东西。
程序员在白板上浏览内容等同于快速演示。
我认为它非常有用,而且我一直都会这样做,但是由于好处已被很好地涵盖了,所以我将只讨论(表面上的)负面因素。
我认为代码测试不太可能给您带来误报:实际上无法写代码的人在面试中会设法伪造代码的可能性很小,至少在您遇到难度越来越大的问题时如此。(也许最有可能的情况是,他们不是通过面对面的采访问朋友,而是在作弊。)
问题更多是在假阴性方面:代码测试会导致您拒绝实际上是最佳人选的人吗?
怯场
您可能会有一个实际上是一个非常好的开发人员的人,但是对这次采访非常紧张,而且他们本质上是怯场。在一定压力下进行表演在某种程度上很重要,但是应对舞台恐惧并不是成为程序员的关键部分(与其他职业相比),并且不幸地拒绝遭受此痛苦的人。这可能会更加复杂:如果该人无法回答他们知道应该回答的问题,他们可能会变得更加紧张。或者,就像这个问题一样,他们觉得他们不能同时交谈和编码。
缓解措施:在进入技术性问题之前,先了解一些有关其背景,目标等的问题。也许从一些更简单的技术问题开始,以便他们获得一些动力。不要在面试中成为鸡巴(质疑分号等)。
这是一个嘈杂的措施
有趣的代码问题可能有多个正确答案。如果一个人写了正确的答案,而另一个人写了正确且更有效的答案,那么您应该加多大的分量呢?
在某种程度上,这就像是一些“难题”问题的问题:这个人要么有洞察力,要么没有洞察力,而您得到的结果几乎是二进制的。智力可能会影响获得该洞察力的可能性,但是仅采样几次就可以得出粗略的度量。
这使我对代码问题感到困扰(尽管我仍然在使用它们。)我能想到的最好的缓解方法是尽可能多地提供一系列可能的解决方案:这个人至少可以写一个粗暴的答案,或者为问题的一部分。意识到这总比没有好是一个好兆头。然后,如果他们发现更多内容,则可以使其变得更高效或更优雅。尽可能避免提出会产生二进制响应的问题。
这不是真正的代表
编程并不是一个接一个地解决十分钟算法问题的工作:关于理解和设计更大的系统以及长时间专注于该领域还有很多工作要做,更不用说人际交往能力了。代码问题并不能真正测试这一点。
但是,代码问题并不是您要问的唯一问题:您可以查看他们的背景,他们的参考资料,他们的开源工作(如果有),以找到持续努力,创造力和人际交往能力的证据。
知道如何解决小算法问题以及如何将其简化为代码是一个必要但不充分的条件:如果您不能解决小问题并且不能编写非平凡的代码,那么世界上所有的大图思维都不是将使您成为富有成效的开发人员。
任何人都可以解决
不,显然不是。正如著名的FizzBuzz帖子所指出的那样,您可能会认为问题是微不足道的陷阱,不仅是新毕业生,还有具有多年行业经验的人。我不知道为什么 要么代码测试是一个很差的衡量标准(有可能,尽管我认为这不太可能),或者它们对简历中的项目贡献不大,或者通过复制粘贴非代码来完成很多工作,算法代码(可能)。
值得承认的是,无需编写任何算法代码,您确实可以完成很多工作。人们在应用程序上赚了很多钱,这些应用程序的价值在于图形或业务逻辑,而不是所谓的“编程”,这很好。但是,如果您实际上需要程序员,那么这不是一个很好的选择。
校准可能不正确
如果您提出一个问题,答案对您来说似乎很容易。但是,如果您突然被问到其他类似的问题,或者没有偏向您自己的特定兴趣和背景的问题,则可能会困难得多。
缓解措施:在您已经知道的一些开发人员上运行测试,并查看其效果。也许您团队中已经有人非常聪明的人可能会遇到其中一个麻烦,您可以考虑对其进行调整。也许他们会想到更好或更不同的答案。
太像琐事了
我认为,如果您坚持认为人们是内心深处了解晦涩的API,或者语法完美,或者记住一个非平凡算法的确切定义,那么代码问题肯定会引起人们的关注。这些都是依靠文档,Web搜索或编译器错误来获取的,并且与实际专业知识几乎没有关联。甚至不知道该API可能在哪里,这可能是该人最近没有使用过该API的线索,但这不一定是一个问题,只要他们不依赖自己的简历即可。
因此,答案很简单:不要问琐碎的问题,不要挂在琐碎的错误上。提醒应聘者该API的名称或让他们查找该API;修正语法错误;不要测试记住数据结构定义的人。
你如何比较?
如果您有两个候选人,并且都很好地回答了问题,那么您如何在他们之间进行选择?您可以选择做得最快的那只,但也许您开始选择乌龟而不是野兔。您可以再进行一轮,并提出更困难的问题,但我也不确定。也许您只是给他们两个A +,然后尝试根据其他条件在他们之间进行选择(或尝试找到同时雇用这两个人的钱)。
我可以想到的一个缺点是,很难在别人面前“大声地编码”。我发现即使有人看着我的肩膀也很难打字,但我并不孤单。我注意到,当有人叫我到他们的工作站寻求帮助时,他们突然开始输入错误,选择错误的代码补全,甚至犯了完全错误-如果我不坐在那里,他们不会犯任何错误。地狱,我已经看到人们开始使用菜单进行剪切和粘贴操作,只是因为他们正在观察中。这不是正常的行为,我正在谈论的编码人员是优秀的程序员,而且非常聪明。
最近,我接受了一次采访,采访者问我如何编写特定的操作,他说:“给我看一下数学。” 好吧,在进行数学计算之前,我必须首先考虑该问题,这使我感到困惑和困惑。一开始我放在白板上的事情很尴尬,那时我觉得自己输了。我最终得到了A-ha的瞬间,并找到了答案(实际上当它终于出现在我心中,他真正在问的是什么),但是我到达那里之前所做出的“混乱”让我感到非常不舒服。但是,我找到了工作,但是如果面试官的耐心较小,我可能就没有。
我认为,如果您给受访者一个编码任务,请给他们一些时间在计算机上解决问题,甚至是在他们熟悉的IDE中。让他们为您编写代码,然后再讨论。问他们为什么以某种方式做事,以及另一种方式是否会更好。从这种过程中,您将发现更多的信息,而不是要求他们(示意性地)将小便撒到您面前的杯子中。
缺点:
优点:
您确实希望该人员在面试中编写代码-甚至更好,让他们与团队中的成员配对程序X倍的时间(无论您在时间/人力上如何负担得起)。
这几乎是您可以判断该人是否可以编码的唯一方法之一。
我稍微喜欢使用结对编程,因为它可以显示他们的团队合作精神,为他们提供真正的IDE,并让他们解决“真实”的问题(结对中的另一个人可以指导他们了解受访者的任何环境细节)无法合理地知道)。
我们已经开始使用这项招聘政策,我们对结果感到非常满意。
我会说:
优点
缺点
Reverse
方法或类似方法,或者针对书面测试,例如“ 该类的Foo
方法的参数是什么?Bar
”,任何白痴都可以使用Google或使用该文档),而不是显示出架构/设计问题考生可以把事情做好,并解决业务问题。编程是一项具有许多清晰的“可交付成果”的高技术技能。候选人可以或不能提供他们。因此,询问技术问题没有“缺点”。完全是为了说:“向我显示此应用程序的某些代码,或”向我显示您已编写的应用程序的代码”。
不这样做可能会导致以下结果:一位富翁采访了一位辅导老师,教他的孩子下棋(这是一种扩展思维的运动)。老师打开了一个棋盘,开始谈论这64个方格,但没有碰到棋子。时间紧迫,父亲还是聘请了老师。导师教孩子们玩CHECKERS。