5种迹象显示你应该当场聘用程序员

对面试官和面试者而言， 程序员进来面试及进行编程测验有时可能是有趣的经历。大多数面试结束时，招聘经理会告诉面试者“保持联系”，但有时求职者表现优异。此时，在他离开办公室之前就要考虑向他提供工作机会了。

我们在 TimeTrade的面试中包含了一项编程测验，大多数程序员都需要花费整整2小时来完成。整个测试由许多待解决的小问题组成，每一个都比前一个更难。我们可以单纯地基于完成时间来很好地对面试者的表现进行初步评估：如果一切都在一小时之内解决，我们将会很高兴。但是如果两小时过去了，甚至连第一个问题都尚未解决的话，求职者将将极有可能被拒之门外。

除了仅仅迅速解决测验问题之外，还有一些迹象表明一个程序员真得棒极了，应该在他们离开你的办公室之前得到一份工作：

1.他们提出多种解决方案

我最近面试了一名程序员，他用两种方法解决了整套测验题：一种使用迭代解法，另一种使用递归方法。我立刻录用了他。找到问题的多种解决方案是工程师每天必用的一种技能。

2.他们撰写完整的文档

去年我面试了一名工作非常勤奋、细心和专业的人，他在考虑完解决方案之前为代码创建了完整的Javadoc和注释。他甚至撰写了完整的自动化单元测试并且检查了测试覆盖率。当我在2小时时间点回到房间时发现他正在使劲地打字，起初我以为他测验遇到了难题，但他实际上正在向Javadoc添加HTML格式。任何自觉做到这些的工程师正是你所期望的团队成员。

3.他们改进测验

我们故意创建潜伏某些轻微问题的测验题，纯粹是为了看求职者是否(a)能够认出并且(b)愿意修正它们。它也许是字符串引号的不一致用法，误导性的变量名或者这些代码行中的任何东西。求职者阅读提供给他的全部代码作为测验–不只是我们要求他们撰写的那段–就像他们一旦加入我们的团队将在我们的真实产品中所从事的工作一样。

工程师愿意告诉潜在雇主，其所提供的测验存在问题，表明了他们把工作品质看得比仅仅按部就班的工作更重要。雇用他们，可能会为你的产品创造奇迹，在远超出分配给他们的领域的地方做出他们需要的改进。

4.他们巧妙地 重构

大多数求职者都会找到一种有效的解决方案，然后袖手旁观并且如释重负以为他们成功的完成了任务。那听起来不错，但是仅仅达到满足工作机会的底线。解决问题随后立即回过头来重构的求职者完全属于另一种类型。他们感觉选择的算法不正确，并且无法忽略这种可以更高效的感觉。他们的代码存在重复部分，这使得他们内火中烧。这是一群重构、重写以及改进解决方案直到制作完成的求职者。

然而这也是一柄双刃剑。如果求职者不断重写仅仅因为他们尚未到达理想中的“完美”点，这表明他们是一群不知道何时停止（类似的，交货）的程序员。然而如果他们仔细掐准时间并且能够在时间结束之前解决问题同时重构解决方案，这就是一个你真应该考虑雇用的好迹象。

5.所有其它指向“雇用”的迹象

有时存在大量非技术迹象表明你已经找到了合适的求职者。你的其他团队成员把你拉到一边告诉你，“我们必须雇用这位女士。”他们（求职者）的个性感觉上非常契合本团队。他们拥有团队所需的近期相关的经验。你认识一些曾经与他们共事过的人，这些同事告诉你他们是非常棒的团队伙伴（并且他们愿意再次立刻雇用这些求职者）。求职者对公司和工作机会表现得兴奋不已，急切渴望开始做出贡献。

如果求职者通过了技术群面并且所有其它迹象都指向“雇用”，为什么要等待呢？如果这样，你可能会错过这名求职者，因为其他雇主能比你更快地识别同样的迹象。相反，果断且快速地提供工作机会，从而给求职者留下公司求贤若渴的印象。这有助于双方的整体关系有一个良好的开始。

因此你下次在办公室里遇到了非常棒的求职者，不要假设明天还会有比他更好的。给他提供一份工作，然后让你自己–及求职者–投入工作中。

原文： 5 signs that you should hire a programmer on the spot

相关文章

• 如何招聘到高质量的程序员？
• 为什么我们不用智力题来面试程序员
• 如何面试程序员？
• 王淮：硅谷公司如何招人的一二事
• 不是缺少人才，而是面试过程有问题
• 我是工程师，不是编译器
• 提高程序员面试代码质量的三要素
• 为什么我们不要 .NET 程序员
• 你不懂技术，如何领导我们
• 怎样花两月时间去应聘互联网公司