在我职业生涯的早期,在多伦多的一家咨询公司进行了一次简短的初步面试后,我在同一天被邀请参加一个技术面试。我将加入的团队中的两名资深开发人员将进行面试。
采访开始时,他们愉快地描述了他们一直在做的项目:大学教授与学生交流的门户。它是用ASP.NETMVC构建的,这是我已经使用了几年的一个框架。我表示我对这个框架很满意,我很高兴能参与到这个项目中来。然后技术考试开始了,当考试结束时,我感到羞辱地离开了面试。
许多年后,当我准备接受采访时,当我回顾这段经历时,我意识到提问和接近的路线对那些开发人员来说是一次自我旅行。我向自己保证,永远不会让我的任何候选人有和我一样的感觉。
那些开发人员做错了什么?撇开他们对我的态度不谈,他们的问题与角色或项目无关。我当时不知道什么是红黑树,但我绝对知道如何使用ASP.NETMVC,他们没有询问过。
我对技术面试的金科玉律是,每一步、每一次谈话和每一个问题都必须与该职位的日常工作相关。虽然这一点可能是显而易见的,但我相信许多招聘经理仍然期待应聘者在参加技术面试时背诵计算机科学书籍。这种形式的技术面试应该被淘汰。
以我的黄金法则为指导,我的面试过程要简单得多。在面试之前,我和我的团队回顾了应聘者与我们分享(或在Github上写的)的代码样本,以了解他们的代码质量。在面试期间,我深入到了与应聘者讨论的三个领域:产品建设、过程坚持和团队合作。
回顾他们过去的经验,询问他们开发了哪些技术和产品,以及如何开发。我询问他们以前从概念发货到市场的产品。
为了了解他们派生解决方案的思维过程,我绘制了一个UI,并要求他们概述和解释他们将使用哪些方法、结构和技术来构建解决方案。
我问他们如何跟上技术的步伐,以及他们如何提高技能来衡量他们对工作的热情。
我回顾了他们的经验,询问他们是如何管理产品构建的,以及他们使用了哪些工具和流程。
我解释了在我们团队中工作的过程,并询问他们将如何改变这一过程,以及他们在哪里看到了效率低下的地方来讨论他们的想法。
通常,我会给他们一个场景,流程无法让团队发现他们将采取什么措施来解决效率低下的问题,以及他们是否愿意直言不讳。
在回顾他们过去的经历时,我问他们是如何与他们的团队合作和沟通的。
我提出了一个场景,其中他们可能缺乏某一领域的知识,并评估他们是否以及如何利用并与他们的团队协作。
我询问的另一个场景是,在评估他们如何管理冲突并将重点放在为团队交付结果方面,他们与团队成员存在分歧。
我在一次面试中这样做是为了记住应聘者的时间和我的时间。我想招聘应聘者,因为他们愿意学习、成长并挑战现状。
技术前景是这样的,一旦我们拥有了一套基线编程技能。那么,我们需要的是愿意挑战自己并保持开放的心态,因为每个开发人员几乎所有时间都必须在工作中学习。有鉴于此,技术面试是神秘的、学术性的,简直就是死路一条。