我的上一份工作是在一家世界500强金融集团担任架构师,当时,公司的IT团队规模将近2000人。与其他IT公司一样,程序员的流动性也比较高,而作为架构师,我需要为所在的部门招聘各个层级的开发人员,当然也包括外包。在这长达5年时间里,我面试了大约400名程序员。我并没有参加过任何人力资源方面的培训,也没有正式研究过如何面试程序员,但是我通过对大量程序员的面试,以及录用后效果的观察,得出了一套自己的面试策略,去找到那些真正靠谱的程序员。
1. 简历看人
阅读简历永远是面试的第一步。好的简历一定是正确、清晰并且能够体现候选人最有价值一面的。我首先会过滤掉那些包含错别字,文句不通或没有逻辑性的简历,因为如果一个程序员连自己的简历都不愿意去仔细检查并完善的话,很难想象他写出来的代码质量会如何。接着,我便会重点阅读简历中的项目经验部分,在这里我能够看到面试者的开发经验,技能栈,并且判断他们熟悉的技术框架、工具是否与目前公司要求相匹配。
这里,我还会特别关注面试者是如何来写这部分项目经验的,你需要用尽可能简练的文字来描述项目的背景,你在项目中承担的角色、参与项目的时长,你用到的技术、以及你在项目中的亮点等信息。优秀的程序员们往往有一个共同的特质,那就是善于归纳,并能够一针见血的发现问题或把一个问题说清楚。我经常看到面试者在简历中像写故事一般地描述他们的项目经历,光这一个章节就有好几页,其实这反而会给你减分,因为这会让面试官判断你缺乏必要的归纳能力。
最后你的一些与编程有关的社会化活动,如:你在GitHub上的开源项目,在知乎、V2EX中给他人的解答以及你的个人技术博客等等都会给你加分,因为这说明你对所从事的工作有着极大的热情,并愿意在业余时间去学习和提高自己,就像在我之前的 “给职场新人的10点职业建议” 一文中提到的,如果你要成为一个领域的专家,那你必须花费超过1万小时,而这光靠工作时间是远远不够的。
2. 给面试者10分钟介绍自己最擅长的
当面试者通过了笔试和HR面试之后,你就需要面对面地对候选人进行面试。我远不是什么面试专家,但我有一些自己的独特方法。我讨厌问一些很个人的问题,比如你的职业规划是什么?你为什么想换工作?等等。我更愿意给面试者10分钟时间,让他介绍自己最擅长和最感兴趣的领域。这往往能帮助我很快作出下面的判断:
·这个人对他所做的事情是否充满激情
·他们是否能在团队中很有效地进行沟通
·他们是否在专业领域足够擅长
·你的团队是否会乐于和这个人一起工作
这一招我在面试中用得很多,而实践证明也确实非常有效。
3. 基础打牢了吗?
一般,有一定规模的公司都会为面试者安排机考或笔试,从而能首先筛掉一批未能通过的面试者。另一些规模较小的或初创公司则会让面试官直接进行技术面试。其实,我觉得这两者的差别不大,有经验的面试官往往能够通过几个最简单的技术问题,判断出面试者的技术基础是否牢固,这不是为了证明他有多优秀,而是用来判断他是否是一名合格的程序员。对于我来说,并不看重机考的成绩,因为机试的考题很多能够在网上得到,特别对于一些外包公司,他们总是能够通过各种途径得到考题,从而使得他们推送的外包能够顺利通过笔试。
下面是我经常会问的几个问题(JAVA):
1.HashTable与HashMap有什么区别?
2.Servlet是线程安全的吗?
3.JSP中@include跟jsp:include的区别
4.HTTP的response code 403和500分别代表什么
......
这些问题都很简单,但一些基础不牢的程序员往往会在这个时候露馅。当然,根据面试岗位的不同,你还可以有针对性地问一些问题,例如,你需要找一个能写核心算法的程序员(比如,银行的总账计算,或者保险公司的保费计算),那么你可以问一些算法相关的问题。
4. 技术深度够吗?
具备牢固的技术基础,一般就可以满足项目中普通程序员的要求了,但如果你需要找的是一个资深程序员,那么你还需要对面试者的技术深度进行考察。我们现在做项目时都会大量使用框架,这能使我们的开发效率和质量都得到提升和保障,但同时也降低了对于程序员开发技能的要求。因此我一般会询问面试者下面的问题,来考察他对所使用框架的掌握程度。
请你描述一下,在这个项目中,从一个HTTP请求发起,到最终的Response返回,它在你的系统和框架内部是如何流转的?
这个问题往往能够判断出面试者对于相关技术掌握的深度。较初级的开发人员描述的层级往往比较浅,比如使用Spring MVC框架的,只能说到实现一个Controller继承BaseComman dController(甚至很多开发人员只知道继承了一个公司内部框架的基类),至于再往下Spring框架是如何进行内部流转的,就再也说不清楚了。而更资深的开发人员,往往能说出框架内部的实现机制,以及如何调用和处理的。在面试者描述的过程中,你还可以穿插询问一些比较有深度的问题,比如框架中某个类这样设计是哪一种设计模式的体现,采用这样的设计有什么好处等等。这比让面试者默写一个设计模式代码要有效、自然得多。
除了技术层面上的考察之外,对于资深开发人员,还需要考察他们的设计能力。说到软件设计,大部分面试者都能熟练地背出面向对象的三个基本特性:继承、封装、多态,也能把它们的概念描述清楚。但我一般会问下面的这个问题来考察他们的面向对象设计能力。
请用一段程序代码描述我们所在的这间房间。
我惊讶地发现至少有一半的面试者都很难准确使用Interface和Class来给房间建模,也有一些人会将最基本的代码语法或关键字写错。
5. 选择适合所在企业文化的人
这一点也曾是我经历的一个误区,我总是希望能为团队招到技术能力最强的人,而忽略了他是否与整个公司和团队的文化相匹配。这往往会造成,虽然招到了人,但没过多久就因为理念不同不欢而散的结果,反而给公司带来了损失。让我们看看GitHub的负责人是怎么说的。
我们很严肃地看待我们自己关于招聘流程的哲学。我们希望每一个GitHub员工都了解他们所要面对的环境,并保证他们是能够很好适应的。这包括我们所创造的文化、哲学、计划、错误甚至是晚餐。比起他们的技能是否满足要求,我们更看重他们的潜力以及是否能够适应我们的企业文化。
我曾在具有鲜明文化差异的不同公司或团队工作,看到许多崇尚开放、开源的程序员在一个相对封闭,具有很多流程以及规范限制的公司中很难发挥,最终选择离开。因此在招聘程序员时,选择合适的往往比选择最优秀的更重要。
6. 行为面试法
行为面试法可能是我在整个面试过程中唯一用到的教科书面试方法。一个程序员是否能够很好地工作,不仅取决于他能否顺利地完成开发任务,更重要的是在遇到一些特殊场景或问题时,他能否合理有效地处理和解决。行为面试法能够帮助我们从面试者描述的过去某一具体事件中,预测未来他在工作中可能的表现。下面便是一个我经常用到的问题。
请谈谈你在这个项目中遇到的最大困难或挑战是什么,你是如何解决的。
从面试者对上面这个问题的回答中,我能够很好地判断他是否有较强的独立解决问题的能力,而我认为这是除技术能力之外,程序员最应具备的能力。
7. 给他们一个虚拟任务
经过上面的这些环节,你可能对面试者的整体情况已经比较满意,但先别急着下结论。我曾见过能够顺利通过上面所有面试步骤,并且被雇佣的程序员,当他们进入实际工作后却没能把事情做好。
在你确定是否录用他们之前,可以给他们一个虚拟任务。我不是说一个抽象的程序问题,而是指一个真实的,可能就存在于你当前项目中,并且需要在一两个小时之内完成的一个开发任务。我曾经出过这样的考题:
写一个小程序将一个以特定格式(如CSV)存储的文本文件转换为XML格式,并存储为另一个文件。
你可以给他一台已经配置好开发环境以及IDE的电脑,让他当场编写代码。当然如果时间有限,你也可以直接询问面试者的实现思路,并简单用伪代码来描述处理过程。通过这个测试,你能够看到很多细节,比如面试者是否有良好的编码习惯,异常处理是否规范,代码逻辑是否缜密高效,以及他的开发效率是否足够高。如果面试者给出了非常优秀的解答,那么你就应该能够判断他确实是一个优秀的候选人了,因为我从没碰到过能够通过上面的测试,却在实际工作中无法做好的人。
8. 以上绝不能保证你招到合适的程序员
你可以在面试程序员时参考上面的这些步骤,对于我来说大多数情况下它们都是有效的,但偶尔也会出错。你需要结合你所在公司和团队的实际情况,提炼你觉得有用的面试步骤,并忽略其他的,最终形成属于你自己的面试策略。另外,你还需要根据面试时的实际情况,随机应变,因为人是最复杂的动物,而面试过程却是需要双方互动的。
想象一下,在你退休之前的未来几十年时间里,你都需要每周40小时地工作,因此无论是公司还是应聘者都应该互相尊重,建立充分的信任,并充分判断是否适合对方后,再确定是否雇用某人或接受一个公司的职位。你的目标不应该是简单的获得一份工作或者雇佣某个人,而应该以获得更多的工作乐趣和建立更良好的工作关系为目的去看待招聘这件事,切忌不要急于求成,就像谈恋爱一样,当双方都有感觉时,一切就水到渠成了。
又到了一年中的招聘热季了,希望每一位年轻的程序员朋友都能找到一份让自己快乐的工作 ~