常见的招聘过程我之前的主要工作是参与招聘并进行技术面试,招聘的总过程如下: 1. HR所进行的面试:判断候选人是不是一个连环杀手或{敏感词}。 2. 技术专家进行的面试:判断候选人是不是一个优秀的程序员。 3. 大老板进行的面试:判断候选人愿意接受多少报酬。 我面试过两种类型的人:实习生和准员工。实习生只需要经历以上第二条步骤即可,其他人则需要经历所有的步骤。在那个公司工作的两年多时间里,我进行了超过200次技术面试,这对我来说是一种丰富的学习经历,我逐步弄清了这一过程的实质。这里有一个很重要的前提,请你记住,在法国你不能轻易解雇一个人,雇佣了一个错误的家伙,你就等着抱憾终身吧。找出最好的候选人极为关键,不能犯任何错误,这是一个繁琐的过程,但我乐在其中。 特别专业的中彩票式技术问题在2008年,我进行了我的第一次技术面试,当时,公司已经有了一套工作流程供我参照:面试时间1小时,候选人有30分钟时间回答15个测试问题,之后我们会花15分钟时间讨论他们的回答,外加15分钟时间回答关于工作方面的问题。我很快就意识到这样的问卷是多么的糟糕,我的意思是,你竭尽全力也找不出比它更坑爹的东西了。我们公司里大概有50%的项目都是使用Java编写的,所以测试题就非常专注于Java,其中包含了5个琐碎的问题,紧接着是10个关于特定Java框架的极难问题,比如我们经常使用的问题有:
或
见鬼的是,甚至是我自己都无法解释这些问题或再补充点什么,每一次面试我都祈祷候选人不会用这些问题来反问我!对一个面试官来说,这很讽刺,不是吗?无论如何我还是会快速浏览一下他们的回答(2-5分钟),之后将时间放在讨论他们的简历上,这浪费了很多时间,于是我决定改进一下。我上网比较了成百上千个面试问题,那时我相信我们必须在测试中放置正确的问题,才能展示一个人才的真正优秀之处,正所谓“好马配好鞍”。 宽泛的、怎么回答都对的技术问题经过大约一个月的研究,我已经在网上找遍了各种问题,提炼出最好的50个问题,我认为它们都是好问题,因为用任何语言都能回答它们,同时难度也是平稳提升的。我将这50个问题打散,组成5套10大题,随机分发。 示例:
这问题好多了吧,我觉得显而易见的,一个给力的问题通常会得到一个给力的回答作为回报,我实践了几个星期,但是不知何故这并不完全奏效,我觉得我已经做的很好了,但结果却并不怎么好。是的,这些问题能够测试出一个人是否熟悉编程理论,然而最终我对此人能否编程依然一无所知,直到最后我也不确定用这种方法招聘员工能比用以前那种粗糙的struts 2问卷好多少。我想了很多,我意识到这其中有两个巨大的问题: 1. 问题太泛了,如果不专注于某一种语言,我无法讨论诸如SQL,前端细节等话题。 2. 问题太短了,10个泛泛而谈的问题涉及面太窄,我没法通过其他方式判断此人是否是优秀的程序员。 我需要的是更多的问题,并且这些问题必须针对候选人所申请的工作内容。 面试问题宝典:10万个为什么事情逐渐有点失控了,当时我继续深入研究,并创建了一个全自动化的测试工具(在一个实习生的帮助下):测试经理(QM)。这个工具使招聘过程变得完美:在初次面试后,HR会选择三个与工作描述相关的话题,之后工具会自动生成一组多项选择题,其中包含3*20=60个随机但具体的问题,其难度符合测试者的经验水准。 示例:
之后,工具会绘制一个小图表,产生并发送邮件给HR,直接显示结果,而不是一堆无用的指标。这是我多么为之骄傲的工具!我急切盼望着有候选人能够测试这套系统!我坐在HR旁边,在内部系统上观察候选人选择某些答案后的实时分数。QM使我们所有的工作都变得更容易了,看上去非常完美,直到在我们自己的开发人员上测试它时…… 好吧,情况比我们想象中的更为离奇,我们之中许多优秀的开发人员会获得和被我拒绝的那些人一样的分数,这才是正解,QM被证明是无效的!我花费了很多时间建立这个工具,同时也花费了很多时间认识到我犯了一个巨大的错误:我们希望对结果进行自动化处理,这迫使我们只能设置选择题。用户只需要选择一个答案,因而问题最后大多演变成了技巧性问题,最终的结果是我们根本没有测试软件开发的技能!要面对这副窘境非常艰难,但最后我还是承认这个工具产生了反作用,展示了错误的印象。 |