跳到主要内容

如何有效的考察应聘者能力

· 阅读需 8 分钟

又到一年招聘季,这段时间我既在面试别人,也在被别人面试了几次,所以想借此机会跟大家分享一些心得体会。

先说说我被面试的感受吧。总的来说,国内外的面试风格差异挺大的。国内的面试官好像特别喜欢问技术细节,比如类继承、虚函数、多线程同步、内存分配、字符串拷贝等等。而国外的面试官则更喜欢聊你的过往经历,最常见的问法就是“你有没有遇到过XXX的情况?当时是怎么解决的?最后结果怎么样?”我个人更喜欢后一种风格,感觉更能考察一个人的综合能力。

这些年,因为公司的培训,加上自己的一些实践和反思,我对面试的看法和做法也变了不少。刚开始,我也喜欢问一些有标准答案的问题,比如设计算法、分析程序出错的原因、怎么调试错误、喜欢什么样的公司和老板等等。这类问题的好处是答案对错分明,容易判断好坏。但缺点也很明显:答案好不好,并不能完全说明这个人适不适合我们公司。技术问题问得太细,就算回答得很好,也可能只是他恰好看过这道题;回答得不好,也可能只是他研究的领域不在这儿。至于问一些非技术性的问题,效果也不太好,很少有人会回答得太离谱,而一般的回答又提供不了太多有用的信息,对最终的录用决定没什么帮助。更何况,现在技术问题有题库,非技术问题也有标准答案,面试前突击一下,看看面经,就能把自己包装得挺好。

意识到这些问题后,我就开始琢磨怎么改进面试方法,把考察的重点从技术细节转移到能力上来。我觉得,一个员工如果能在公司待个四五年,只要能力过硬,什么技术细节学不会呢?

于是,我就开始调整策略,不再问那些有标准答案的技术细节问题,而是问一些开放性的问题。有些公司会问“一个城市有多少下水井?”或者“某种动物有多少只?”这类问题,不是为了要一个准确的答案,而是通过观察应聘者思考问题的过程,来判断他解决问题的能力。不过,这类问题也可能存在一些固定的解题套路,面试官有时还是分不清应聘者是真的会思考,还是只是套用了从面经中学到的技巧。

那段时间,我主要通过了解应聘者以前做过的项目来考察他们。一般来说,如果应聘者能清晰地介绍项目,抓住重点,就能说明他工作认真、研究深入,而且表达能力不错。这样的人正是我们需要的。但这种只聊项目的方法也有缺点,就是面试官不太好把控方向,应聘者可能会避重就轻,只讲自己擅长的部分,导致面试官没法全面了解情况。所以,面试官还是需要主动提问,引导谈话。

现在,比较流行一种叫 SBO(Situation, Behavior, Outcome)的面试方法,意思是情境、行为、结果。也有人提到 CAB、PAR、STAR 等方法,意思都差不多。简单来说,就是面试官先设定一个情境(或者挑战、问题、任务),让应聘者结合自己的经历,举例说明当时是怎么做的,结果如何。面试官还要问一些细节,以便更深入地了解应聘者的能力和性格。面试时,面试官需要准备多个不同方面的 SBO 问题,全面考察应聘者的解决问题能力、学习能力、沟通能力、工作热情和团队合作精神等等。

比如,面试官可以询问这个问题:“请你回想一个你在工作中遇到的特别棘手的技术问题,并详细描述你是如何解决的。” 应聘者在回答时,面试官要记得追问细节,比如:

  • "这个问题是在什么项目背景下出现的?"
  • "当时的具体症状是什么?"
  • "为什么说这个问题特别棘手?"
  • "问题对项目造成了什么影响?"
  • "你最初是如何着手分析这个问题的?"
  • "在解决过程中用到了哪些工具或方法?"
  • "遇到了哪些障碍?你是如何克服的?"
  • "在这个过程中,你与团队成员是如何协作的?"
  • "最终是如何解决这个问题的?"
  • "解决方案带来了哪些具体改进?"
  • "从这次经历中你学到了什么?"
  • "如果再遇到类似问题,你会如何改进解决方案?

面试官需要通过候选人的回答评估以下几个方面:

  • 问题分析能力,比如应聘者是否能清晰描述问题本质,是否考虑到问题的各个层面,分析方法是否系统合理等
  • 设计解决方案的的能力,比如方案是否具有可行性,是否考虑了多个可能的解决方案,解决方案是否具有创新性等
  • 执行能力,比如应聘者是否有清晰的解决步骤,是否能有效地利用各种资源,遇到困难时是否能及时调整策略
  • 协作沟通能力,比如应聘者是否善于寻求帮助,是否能有效地与团队协作,是否能清晰地表达自己的想法

通过这种结构化的面试方法,面试官能够更全面、客观地评估候选人的实际能力。同时,这种基于真实经历的对话也能让候选人更自然地展示自己的能力和特点。