要求应聘者完成某种编码测试或挑战,这往往是科技行业的标准招聘做法。有时,这采取了令人畏惧的白板面试的形式-应聘者被要求在面试小组面前解决前面提到的白板上的问题。在其他情况下,这是一项带回家的作业,或编码挑战。通常在最初的面试(有时是两轮面试)之后,应聘者会被安排在自己的时间里完成一项任务,这通常是他们申请的工作的典型内容,或者需要许多相同的技能。
这篇文章不是专门关于白板采访的,我自己从来没有经历过,尽管我的许多观点同样适用(也许更适用)。更确切地说,它是关于“编码挑战”的完全无用,以及为什么我永远不会主张用它来评估你职位空缺的潜在应聘者。我曾多次作为前端开发人员职位的候选人,我百分之百相信编码挑战是浪费时间和资源,并给未来的人带来不必要的压力。我特别喜欢劳里的这条推文:
好的,我来做一个。技术面试可以很好地进行,而不需要候选人编写一行代码。他们不能参加面试的想法更多的是关于面试官,而不是被采访者。#dev讨论。
-Laurie(@laurieontech)2020年9月9日。
(如果您不想阅读整篇文章,请阅读她的Twitter帖子!)。
免责声明:我是以面试人员的身份写这篇文章的,我从来没有坐过面试台的另一边(至少是网络开发职位)。也许你是一名面试官,觉得编码挑战很重要,也很有价值。我会争辩说,即使是这样(这本身令人怀疑),它们也不值得你给候选人施加的负担。
我认为不应该进行编码挑战的首要原因是它们需要花费大量的时间才能完成。找工作很累,而且常常让人士气低落。你的应聘者很有可能已经花了很多很多小时来写申请表和修改简历。许多编码挑战都附带着“只在这上面花6个小时”这样的警告,但在很多情况下,应聘者会花费比声明多得多的时间。当你知道其他申请者有可能比你花更多的时间,提供更完美的结果时,你为什么不呢?
出于这个原因,编码挑战是反包容式的,只会鼓励空闲时间不受限制的人使用应用程序。对于为人父母、有其他照顾责任、做多份工作、有医疗条件、在业余时间学习的应聘者(清单还在继续),为一份他们甚至可能得不到的工作工作6个小时是他们根本没有的时间。
这里特别提到“规范工作”:这应该是不言而喻的,但要求应聘者完成原本是有偿工作角色一部分的任务是完全不可取的。我不应该解释为什么这是糟糕的,但可以肯定的说,如果你希望你的候选人做任何像这项挑战涉及的工作量,你应该相应地补偿他们。
人们在压力下没有做好他们最好的工作。白板面试是一个经典的例子,说明了如何将某人放在一个令人焦虑的环境中不太可能产生最好的结果,但编码挑战也以其自身的方式带来了压力。编写代码时知道每一行都会被仔细检查和判断以决定您的未来,这意味着您无法完全专注于编写有效的代码。你总是在事后猜测--“他们会赞成我构造这个函数的方式吗?”等等--这可能会导致你想得太多,占用你可用的时间,因此需要更多的时间。
另一方面,也许这项挑战对应聘者来说很容易,他们会轻而易举地通过它。以“待办事项”列表应用程序为例--这是一个相当常见的编码挑战示例。很有可能他们之前已经为面试建立了类似的东西,而这次“挑战”将会重新讨论同样的问题。在这种情况下,您不会学到任何不能从查看他们以前的工作中获得的东西,而且会浪费每个人的时间。
一些候选人可能会坚守他们舒适区的安全,专注于提供一些技术上精致但不那么先进的东西。其他人可能会过度伸展自己,接受一些新的东西,结果却达不到要求(同时在这个过程中给自己带来了压力)。一个来自我自己经验的例子:申请初级开发人员的角色,我被要求从一个设计建立一个登录页。虽然我几乎没有使用Javascript的经验,但这是“理想的”工作要求之一,所以我花了不成比例的时间来尝试添加一些JS功能,这意味着我没有太多的时间去做我有信心做好的事情。进入面试时,我已经感觉自己是个失败者。无论哪种方式,编码挑战都是一个人工环境,它不能反映员工感觉压力较小的真实世界。我重复一遍:这绝不是他们在工作环境中表现如何的指标。
出于这些原因,编码挑战不太可能展示候选人真正的能力。
通常会花费不成比例的时间来尝试推断挑战的要求。实际上被评判的是什么?在前面的示例中,我不知道我是会因为平庸的JS实现而受到不好的评价,还是会因为尝试了一下而受到好评。另一个恰当的例子是卡罗琳·斯特兰斯基(Carolyn Stransky)的这条推文:
当您在前端编码挑战中看到这一点时…。你觉得他们是真的不在乎还是真的在乎?(下面的投票)眨眼让我离开了🙎🏼♀️pic.twitter.com/OJUKeNgyWb。
-卡罗琳·斯特兰斯基(@carolstran)2020年8月22日
当然,如果不清楚你的标准是什么,你可以问你未来的雇主。但不明确的要求会导致更多的时间浪费,以及更多不必要的压力。在最坏的情况下,进行招聘的人本身并不知道标准,除了“当我看到它时我就会知道”。(如果是这样的话,那就是一个重大的危险信号。)。
那么,我应该提倡什么呢?经理怎么知道哪些候选人最有潜力在工作中大放异彩呢?
嗯,当然你可以问他们。一个好的面试官应该能够鼓励未来的员工谈论他们过去使用不同技术的经历,这种方式能让他们洞察自己在工作中的表现。他们建了什么?他们是团队的一员吗?他们需要考虑哪些限制因素?他们是如何做出某些技术决定的?他们喜欢或不喜欢某项技术的哪些方面?他们在哪些领域感到舒服,在哪些方面他们觉得自己的知识或经验不足?他们好奇的是什么?他们想学习或改进什么?
人们通常不会对自己的经历撒谎(他们很快就会被发现),尽管有时他们可能会夸大自己的简历。一个例子是一位面试官在寻找Reaction开发人员。在简历中将“Reaction”列为一项技能的人可能是一名很有成就的Reaction开发人员,或者他们可能只从参加训练营或浏览在线教程中获得了一些肤浅的知识。只需与他们交谈几分钟,就能了解他们在这一领域的知识深度,以及他们是否是这个角色的合适人选。
大多数工作都已经有了这样的试用期-固定的试用期(通常是6-12周),雇主和未来的雇员可以在这个试用期内确定他们是否适合这个角色。如果没有,他们可以自由地分道扬镳。再加上良好的面试过程,这应该就足够了。尽管完成了编码测试或挑战,很多人还是没有通过他们的试用期。除了技术熟练程度之外,还有许多因素可以决定某人是否适合您的团队,但是编码挑战通常首先集中在技术熟练程度上。
大多数应聘者都会有副业或为前雇主做过的工作。让他们向您展示代码并描述过程,并在此过程中提出问题(见上文)。
即使是初级职位的候选人,也许是刚从训练营毕业的人,也可能会有他们可以展示的项目。如果他们是试验性的或非公开的,那也没关系。这不是演习的重点。
在某些情况下,候选人可能会因为特定原因(例如NDA)而无法展示工作。在这些情况下,仍然可以谈论所面临的工作和挑战,而无需查看源代码或深入细节。但如果这些都不实用,还有更多的选择……
不是编码挑战,而是让他们花很短的时间来构建他们喜欢的东西,并谈论他们做了什么以及为什么。也许他们想花时间学习一项特定的技术,所以他们制作了一个简单的演示来帮助他们更好地理解它。也许他们已经是CSS动画的行家里手了,所以他们制作了一个有趣的演示,真正展示了他们的技能。或者是乔丹经历的另一种选择:
刚刚结束了一次技术面试..。这个过程包括我在我的一个个人项目中实现了一个新功能,而面试官则跟随着我,实际上我很喜欢这个,而不是典型的技术面试问题,但我仍然紧张得像屎一样😭。
-约旦(@TheJordan Rules_)2020年9月3日。
这里的不同之处在于,候选人可能会更自在地谈论他们理解的东西。关键不在于结果有多完美,而在于他们事后是如何谈论这件事的。
我仍然要注意这一点,因为你仍然要求人们在他们的业余时间完成一项任务,这并不是每个人都可以选择的。我不主张将其作为标准,但在特殊情况下可以考虑。
您可能会争辩说,编码挑战的意义在于测试候选人的局限性,您可能无法通过允许他们选择构建什么来收集这些局限性。测试候选人的局限性是一个糟糕的想法,这只会增加形势的压力。而且,如前所述,压力过大的人不会给人一个准确的印象,他们在“真实”的工作环境中会如何表现。(除非你的工作环境压力很大,这完全是另一回事……)。
再说一次,我在这个问题上持观望态度,因为结对编程不一定是压力较小的选择。就我个人而言,当有人监视我的一举一动时,我并不觉得我做得最好-我可能会少做很多谷歌搜索,编写更糟糕的代码!但如果这件事做得好,并带着同情心,它可能会被用作最后的手段。
可以说,考生的学习能力比他们目前在某一特定学科上拥有多少知识更有价值。编码挑战只能真正展示当前的技能集。更好的策略可能是浏览一下您公司或产品的代码示例,鼓励应聘者提问,并谈论他们熟悉哪些方面。
如果我还没有说服您完全放弃编码挑战,那么让我给您最后一条建议:不要试图抓住别人。让你的挑战变得简单明了,人们可以在没有隐藏的“陷阱”的情况下完成挑战。
这里有一个例子:在一个职位上,我面临的挑战是使用API调用构建一个简单的应用程序来获取数据并将数据发布到服务器。我被授予了对入门存储库的访问权限,只有当我尝试在本地运行该项目时,才不断收到错误。我花了几个小时试着调试它,认为我做错了什么,责备自己在第一个栏就摔倒了(在最终弄清楚之前!)。在随后的面试中,我了解到这个错误是故意放进去的,以测试我是否会伸出援手寻求帮助。这立即让我在接下来的面试中处于不利地位,尽管我丝毫没有反映出我在工作环境中的表现。
所以。别干那事。而且,如果可以控制的话,根本不要设置编码挑战。有更好的方式来打发你(和你的候选人)的时间。