甚至没有提交的面试代码提交改变了我们的流程

在之前的工作中，我是一家知名公司的工程经理，负责某一特定的技术堆栈。我们深度参与了这个社区，并允许远程招聘，因此我们收到了源源不断的公开职位申请。我们对它们进行分类的一种方法是要求对潜在候选人进行编码测试。正如你可以想象的那样，我们得到了各种各样的结果，从令人印象深刻到怀疑这位候选人是否在耍我们。但是有一个很突出，它教会了我思考我在这些类型的投稿中真正寻找的是什么。

我知道，让人们免费编写代码只是为了获得面试机会的做法目前并不流行。这是一个完全不同的讨论，利弊是完全不同的讨论。在这个故事发生的那段时间里，它被更多的人接受，我们取得了很大的成功。曾经有一段时间，人们没有一大堆公开的回复可以细读。

出于测试的目的，我们在我们的org帐户下对GitHub进行了公开回购。说明和要求都很简单，并在自述文件中列出。

操作说明：1.在GitHub2上分叉此回购。创建一个程序，它可以与人类玩家交互地玩Tic-Tac-Toe游戏，并且永不会输。尽早地、经常地承诺，并传达好的信息。将您的代码推送回GitHub并向我们发送拉取请求。我们是[密文*]商店，但不要求您使用该技术堆栈实现您的程序。

这就是我们所有的要求；我们故意让它无限期地进行。一些人试图用使用不同服务和引擎的大型、精心设计的应用程序来给我们留下深刻印象。我们通过CLI提交了一篇文章，只是因为“我很无聊，想试一试”。我们在审查候选人时尽量保持开放的心态，在做出最后决定之前需要多人参与。如果公关上批准的比拒绝的多，我们就会请这个人来了解更多。

我们没有太多地关注他们留下的技术、打字错误、边缘错误，或者即使他们的tic-tac-toe引擎实际上从未失败；我们对有时会失败的应用程序有很多一致的批准。我们希望看到倾向于与我们的团队和工作流保持一致的因素：他们多久登记一次？提交消息如何？是否添加或需要测试？这个项目的可读性和组织性如何？

没有硬性清单，但我们很早就发现这些因素更值得关注，而不是只关注应用程序是否一直获胜。我们试图做到公平，但我们经常看到一些不真诚的意见书。有时我们看到一些应用程序是从其他网站直接复制和粘贴过来的， - 我们过了一会儿就开始记住它们了， - 上有来自另一位作者的评论和信用。但通常情况下，如果这款应用程序有意义，代码是可读的，即使风格与我们习惯的截然不同，我们也会更多地谈论这一点，并向申请者询问这一点。

在与一位向我们介绍特定候选人的招聘人员交谈后，很明显，这位应聘者可能很难继续进行编码测试。这个人工作很忙，担心他们不能及时提交代码。我让他们知道，他们必须工作多少小时没有时间限制或最低要求；我们希望在大约两周内做出决定，所以如果他们愿意的话，这对我们来说是可行的。每个人都竖起了大拇指，我们希望能有一个好的意见书。

在两周减去一天的时间里，我们收到了一份取款请求和一封电子邮件。我们先看了一下公关，遗憾的是，没什么可做的。这个应用的结构组织得很好，我们可以看到他们会走的道路是频繁的， - 提交是频繁的，有好的消息 - ，但是这个应用的实质是缺失的。可悲的是，我们甚至不能运行它，我们非常确定他们的时间已经不多了。我看了邮件，他们非常抱歉。他们解释说，由于工作和个人问题，他们没有时间，所以他们的提交是不完整的。但在接下来的三段中，他们解释了他们会做什么。

他们链接到关于Minimax的文章，他们打算将这些文章作为灵感。他们想知道Negamax是否可能更快，并会试图找出答案。

他们列出了他们认为根据经验很难处理的部分，并列出了如果A计划失败他们会尝试的一些事情。

他们写道，他们将如何为某些部分添加测试，但不会为其他部分添加测试，并快速解释了他们所说的“测试膨胀”以及为什么他们试图避免这种情况。

要点简明扼要，但仍然非常清楚。通常，我会对他们的挑战表示良好的祝愿，并提到如果我们开始另一轮谈判，我会伸出援手。但仔细想想，我想知道：我还希望学到什么呢？

我们有一些他们早期的代码片段来了解一些风格，以及他们将如何前进以解决陷阱的思考过程。即使是提交消息，尽管数量很少，但也显示出对读者的清晰和体贴。我将这份意见书中变得清晰的因素与其他更完整的例子进行了比较，注意到我对这份意见书中的候选人有了同样多的看法，并对其进行了解释，就像我在其他一致同意的情况下所做的那样。因此，我把我的想法和公关链接从候选人那里复制了三段，并在我去参加下一次会议之前将其通过电子邮件发送给了评审员。当我回来的时候，我在电子邮件链中收到了三个回复，只是说，“发货。”

我对那份意见书想了很久。为什么这件事做得很好，却与我们的计划有很大的偏差？我们是如何用很少的代码就对他们有如此深刻的印象的呢？我在这些代码提交中真正寻找的是什么？结果不是他们得到了面试机会(他们做得很好)，也不是他们得到了一份工作(他们婉言谢绝了)，而是问道：“我们在这些测试中真正想要的是什么？”

这是一个很难回答的问题。对我们来说，这种变化不是立竿见影的，它在允许更广泛的提交方式方面要渐进得多。我们甚至需要代码吗？有多少代码？我们少试一试吧。我们什么都不试吧！我们是不是直接跳到手机屏幕，讨论他们将如何启动？

我们开始观察有多少人开始更多地参加测试，并看到了这种更开放的方法带来的优秀考生的数量。

从那时起，我就完全不再编写测试代码了。现在有很多途径可以看到人们是如何发展的，而不需要他们花一整晚的时间来编写代码，只为了一次面试的机会。面试和筛选总是很难做好的；他们需要大量的工作和理解。现在，我试着在每一步之前花点时间，在面试的内外，提醒自己我试图从面试的过程中学到什么。总有一些让人感觉舒适和明显的空话，但当我们能够专注于我们真正想要学习的东西，以及我们可以学习的广泛方式时，与人沟通就变得容易得多。归根结底，无论是在招聘、指导还是表彰方面，与人建立联系都是管理者的目标。

标签：公告、采访、堆栈溢出