软件随想录(local.joelonsoftware.com/wiki)-2006年10月25日 软件人员面试教战守则(第三版)

来源:互联网 发布:centos 7.3 gitlab 编辑:程序博客网 时间:2024/06/08 22:09

2006年10月25日 软件人员面试教战守则(第三版) - The Guerrilla Guide to Interviewing (version 3.0)

 

软件人员面试教战守则(第三版)

From The Joel on Software Translation Project

Jump to: navigation, search

作者:周思博 (Joel Spolsky)
Wednesday, October 25, 2006
A part of Joel on Software,http://www.joelonsoftware.com

无政府主义者、自由之爱(free-love)拥护者还有替香蕉争取权利的人组成了一个杂牌军,在墨西哥瓦亚塔港绑架并开走了爱之船,而且威胁如果七天内不答应他们的要求,就会让616名乘客和327名船员随船一起沈没。歹徒的要求?无记号的一百万美元小钞,以及一套依GPL授权实现的WATFIV(也就是尊贵的Waterloo Fortran IV编译器)。(自由之爱的人和香蕉权利派一致同意的事这么少,实在是令人惊讶。)

interviewing1.jpg

你身为嘉年华航运公司编程部门的主程序员,必须决定是否能无中生有,在七天内交出一套Fortran编译器。现在你底下有两个程序员可以帮忙。

你做得到吗?

你回答:「好的,我想想,这要看状况...」写这种文章的好处之一,就是我可以随意地编造你讲的话,你拿我没办法。

看什么状况?

「嗯,我的团队会用UML产生工具吗?」

这真的有差吗?三个程序员,七天,Waterloo Fortran IV。用UML工具就能搞定吗?

「我想是不行的。」

好,那么又要看什么状况吗?

「我们会有19英寸的屏幕用吗?所有人都有喝不完的Jolt可乐(译:咖啡因超高的饮料,是美国程序员最爱)吗?」

又来了,这有差吗?你做不做得到要靠咖啡因来决定吗?

「我想也是。噢,等一下。你说我有两个程序员?」

没错。

「他们是谁?」

有差吗?

「当然有差!如果团队无法和睦相处,我们就永远不能一起工作。而我知道有几个超级程序员,他们自己就能在一周内做出一个Fortran编译器,我也知道很多的程序员,给他们六个月也写不出列印启动标题的程序。

现在我们有点搞头了!

人是软件项目中最重要的部份,这种话每个人都在讲,可是没有人能真正确定要些什么。如果你想要拥有好的程序员,第一要务就是要「请」到对的程序员,也就是说你必须能辨别出谁对的程序员,而这通常都是在面试过程中完成的,所以本章全都在谈面谈。

(面对面的面谈只是雇用过程中的一环,整个过程始于履历筛选和电话筛选。这篇文章只涵盖面对面的面谈。)

interviewing2.jpg

每个被雇用的人选都应该至少和六个人面谈,六个人里至少要有五位会和应征者共事的人(也就是其他程序员而非经理)。你知道那种只靠几位老鸟(salty)经理和应征者面谈,一试定生死的那种公司吗?这些公司里头不会有非常优秀的工作人员。要瞒过一场面试实在太容易了,特别是由非程序员面试程序员时更是如此。

如果六次面谈中有两人认为对方不值得用,就不要录取。这表示当你不打算录用某位应征者时,在两次面谈后就可以技术性地结束「整天」的面试,这并不算是坏事。不过为了避免流于残酷,最好不要事先告诉对方要面谈的次数。我还听过有些公司允许任何一个面试官把人选刷掉。我觉得这有点太过头了;对我来说,或许可以容许让资深人员刷掉应征者,不过不会只因某个新进人员不喜欢而否决。

不要尝试同时和一大群人面谈。这样做并不公平。每场面谈都应该只有一位面试官和面试者,并在一间有白板而且有门可关的房间内进行。我基于丰富的经验可以告诉你,如果一场面试花不到一小时,是无法做出决定的。

你在面谈时会看到三种人。在天平的一端是无知的大众,他们连这份工作最基本的技能都没有。这种人很容易辨别剔除,通常问两三个简单的问题就解决了。天平的另一端是光采夺目的超级明星,他们只是因为好玩,就在任天堂DS游乐器上运用组合语言,在一个周末里写出lisp编译器。而在两者中间,有大量似乎可以有某些贡献的可能人士(maybes)。其中的窍门就是找出超级明星和可能人士之间的差异,因为秘诀就在于你并不想雇用任何一位。绝对不会。

在面谈结束时,你必须准备好对该人选作出明确的决定。这个决定只能有两种可能结果:录用或是不录用。没有其他的答案。绝对不要说:「录用,但我的团队不要。」这是很粗鲁无礼的,暗示对方不够聪明没资格和你共事,不过对其他团队的笨蛋来说可能够聪明了。如果你发现自己很想说「录用,但我的团队不要。」,请直接把这句话翻译成「不录用」那就万事OK了。即使某个人选就你特定的工作很适合,但不太适合另一个团体,这也是「不录用」。软件产业的变化太频繁又太快,所以你需要那种任何编程工作都可以胜任的人。如果基于某种原因,你发现一个非常非常擅长SQL,但是完全无法学习其他主题的白痴学究,不录用。否则就会就是拿长痛去换短痛。

绝对不要说「或许吧,我不确定。」如果你不确定,就表示不录用。这其实比你想像中容易。不确定吗?就直接说不吧!如果你不置可否,就表示「不录用」。绝对不要说「嗯,我想应该是录用吧,不过我对某些地方有点在意...」那也等于是「不录用」。把所有胡扯都机械式地当作「不要」,那就没问题了。

interviewing3.jpg

为什么我那么坚持这一点呢?因为错失好人选比录用不适合的人要好太多了。不对的人会耗用很多钱和精力,还会让其他人浪费时间去修正所有的问题。录用错人要开除得花上好几个,而且会非常的困难(当他们决定对簿公堂时更是格外麻烦)。在某些情况下也有可能完全无法开除任何人。不好的员工会破坏好员工的士气。而且他们可能是个烂程序员,同时却又是个真正的好人或是极度需要这个工作,所以你根本不忍心开除他们,不然就是一开除就会犯众怒,或是其他种种的窘境。反正很惨就是了。

反过来说,如果你否决了一个好人选,我是指我认为有些地方不太公平,不过如果他们真的这么聪明就不用担心,他们有很多好的工作机会可以挑。别害怕会因为拒绝太多人而找不到人用。这在面谈过程中并不是你的问题。当然找到好的人选非常重要。不过当你实际面试某人时,要假装门外还有900个人排队等著和你面试。不管优秀人选似乎有多么难找,也不要降低你的标准。

好了,我还没有告诉你最重要的部份:如何知道是否要录用某人?

原则上很简单。你要找的人必须

  1. 聪明,而且
  2. 能把事做完。

就这么简单。你要的就是这两句话。背起来。每天睡前复诵一遍。简短面谈的时间很短,不足以发现其他资讯,所以别浪费时间去尝试了解,应征者滞留在机场时能否保持心情愉快,或者他们是真懂ATL与COM程序设计还是假装的。

聪明但不能把事做完的人通常拥有博士学位,而且在大公司里工作,不过由于他们完全脱离现实,所以公司里没人会理他们。对他们来说,与其准时完成工作,还不要去反覆思索某个问题的学术性。这种人不难辨别,由于他们喜欢指出两个天南地北的概念之间在纯理论上的相似点。举例来说,他们会说「试算表实际上只是程序语言的一个特例。」然后他们会把工作放下,花一星期去写一篇惊世骇俗的白皮书,讨论试算表作为程序语言时的理论计算语言特性。聪明,不过没什么用。辨别这种人有另一个方法,他们常常会在你要赶出beta版的那一天,手里端著杯咖啡出现在你的办公室,想要开始一场有关Java introspection与COM type library间优劣的长篇对话。

把事做完但不聪明的人会像没想过一样做出蠢事,于是事后别人就得替他们擦屁股。这使得他们成为公司的净负债,因为他们不但没有贡献,还吃掉了其他好员工的时间。他们会前一晚才刚读到Visitor pattern,而且完全误解其意义,却决定要用它来重整你的核心演算法,结果本来用来累加数组内容的简单循环,被改成一个Addervistior类别(没错,还会拼错字)和一个VisitationArrangingOffice singleton,而你的程序也不会动了。

interviewing4.jpg

你要如何在面谈中察觉聪明这回事呢?头一个征兆就是你不必再三地说明事情。对话会很流畅地进行。应征者经常会说出某些很有见地有思想或是心思敏锐的话。所以面谈的重点之一就在于建立情境,让某人能向你展示他有多么聪明。爱吹牛的人是最差劲的面试官。这种人在面谈时都在胡扯,应征者只来得及说「是的,这实在是对了,我衷心的同意你的看法。」吹牛专家什么人都会录用;他们认为应征者一定很聪明,因为「他的想法和我很像!」

益智问答型的面试官是第二糟的。这种人认为聪明表示「知道很多事实」。他们只会问一堆琐碎的编程问题,答对就加分。纯粹好玩提一下世界上最烂的面试问题:「Oracle 8i里的varchar和varchar2有何差别?」这是个烂问题。会知道这种芝麻小事的人和你真正想用的人完全不会有任何关联。谁会在乎有什么差别?你只要约15秒就可以在在线找到答案!记住,聪明并等于「知道琐碎问题的答案」。总而言之,软件团队是要雇用有才华而非会某种特定技能的人。毕竟所有能用在工作上的特定技能,就技术而言都会在数年内过时,所以最好雇用能学习任何新技术的人,而不是此刻刚好知道如何让JDBG和MySQL数据库沟通的家伙。

不过大体来说,要深入了解一个人的方法就是让他说话,要提出开放性的问题与难题。

那么你要问些什么呢?

我个人的面试问题库源于我前一家公司微软。事实上著名的微软面试问题有好几百个。每个人都有他们最喜欢的问题集。你也会发展出自己的问题集以及个人的面谈风格,帮助你作出录用/不录用的决定。下面列出一些我曾经成功用过的技巧。

在面谈之前,我会细看应征者的履历,并在纸片上简略写一份面谈计画。其实只是一串我想要问的问题。下面是面试程序员时典型的计画。

  1. 开场白
  2. 有关应征者最近所从事项目的问题
  3. 简单的编程问题
  4. 指针/递回问题
  5. 你满意吗?
  6. 你有其他问题吗?

我会非常小心避免让自己对应征者有先入为主的观念。如果你在面试前,只因为某人是MIT的博士就认为他很聪明,那么不管他接下来一小时说了什么,都改变不了你一开始的偏见。如果你因为人们读社区大学,就觉得他们一定头脑简单,不管他们说什么也无法克服一开始的印象。面谈就像是台非常非常精密的天平:很难基于一小时的面谈评断某人,而且可能似乎左右为难(like a very close call)。不过如果你事先多知道应征者的一点点小事,就相当于在天平一边加了一个大砝码,而面谈也就白做了。曾经有一次,招募人员在面谈前来我的办公室。她说:「你会爱上这个家伙的。」这种事真是让我生气。我当时应该要说:「嗯,如果你这么确信我会爱上他,你何不直接录取,这样也不用浪费我的时间去面谈了。」不过当时年轻又天真的我还是去了。当他说了些不怎么聪明的东西时,我脑袋里就想著:「哎呀,这一定是失误。」我戴著美化一切的眼镜去看他所说的一切。虽然他是个糟糕的人选,我最后却说了录取。知道后来发生什么事吗?其他面试官通通都说不录用。所以啰:别听招募人员的;在面谈前不要去探听应征者;而且在你们都独立下决定之前,绝对不要和其他面试官谈论应征者。这就是科学方法。

interviewing5.jpg

面谈的开场白阶段目的在于让应征者放松。我会问他们在飞机上好不好。再用约30秒介绍我是谁以及面试会如何进行。我总是会对应征者再三保证,我们只在意他们解问题的过程,实质的答案并不重要。

第二部份是有关应征者最近所从事项目的问题。面试大学生时就问他的学位论文(如果有的话),不然就问他们曾修过,而且真正投入做过大规模作业的课程。举例来说,我有时候会问:「你上学期修过的课里最喜欢那一门?什么课都可以,不一定要跟电脑有关。」而在面试有工作经验的应征者时,可以谈谈他们前一个工作中最后做的事。

同样要问开放性的问题,然后静静地聆听,偶而在他们要停下来时来一句「关于这件事多告诉我一些」就可以了。

在问开放性问题时要找些什么呢?

首先是寻找热情。聪明人热爱他们所做的项目,在谈到的时候会变得非常兴奋。他们说起话来会变快而且生气勃勃。负面的强烈情绪也是个好征兆:「我前一个老板只会用VAX电脑,所以什么事都想在上面做。真是笨蛋!」有太多的人就只是在做事,其实并不在意事情会怎样。像这种人就很难会对什么事有兴趣。

不好的人选根本不在意,在面谈时也完全不会爆发热情。应征者是否对某些事有热情,可以注意某个确实的征兆。当他们谈到那件事时,会暂时忘记自己正在面试。有时候应征者开始时会因为面试而很紧张,这当然是正常的,而我通常也都会忽略不去在意。不过稍后当他谈到单色计算艺术(Computational Monochromatic Art)时会变得异常兴奋,而且一点都不紧张了。很好,我喜欢会真正在意事情的热情人。(什么是单色计算艺术?拔掉你的电脑显示器的电源就可以看到了。)你可以质疑某些事(试试看。先等他们谈到某些可能为真的事,然后你就说「这不会是真的」),即使他们五分钟前还在冒汗,还是会挺身辩解。因为他们非常在意,所以忘记你不久之后即将主宰他们的命运。

其次是好的人选会仔细地从各个层次把事情解释清楚。我曾经因为应征者在谈论之前项目时,无法用普通人能明白的方式说明而否决他们。主修电脑科学的人常会直接假设,每个人都知道Bates Theorem(译:一种经济学理论)或O(logn)的意义。如果他们开始这样,尽快阻止他们,然后说「帮我一个忙,纯粹为了练习,请你用我祖母能懂的话来解释这件事。」这时候很多人依旧会继续使用术语,于是完全无法让人了解他们。停!基本上你不会想录用他们的,因为他们不够聪明,无法理解要如何才能让别人了解他们的想法。

第三点:如果他从事的团队合作的计画,找寻他们担任领导角色的征兆。某个应征者可能会说:「我们在做X,可是老板说要Y而客户说要Z。」我就会问:「那么你做了些什么?」好的答案可能会像「我集合其他团队成员写了一份提案...」不好的答案就像是「嗯,我无计施,这根本就无解。」记住,聪明而且把事做完。而要知道某人是会能把事做完,唯一的方法就是观察他们过去是否有把事情做完的倾向。事实上你甚至可以直接要他们提供一个例子,说明过去他们曾扮演领导角色并把事情做完(比如克服某些制度惯性)。

interviewing6.jpg

不过面谈的大部份时间,还是应该用来让应征者证明他们能撰写程序代码。

再度向应征者保证,你知道不用编辑器是很难写程序的,而且你不会在意白板被涂得乱七八糟。另外你也了解没有编译器是很难写出正确无误的程序代码,这些在看结果时你都会考虑进去。

我会在一天的第一场面谈里加上一个非常非常容易的编译问题。我被迫在dotcom热潮时期开始这样做,因为当时有很多认为HTML就是写程序的人跑来面试,我得找方法避免在这些人身上浪费太多时间。这是那种现役程序员都能在一分钟内解决的问题。举些例子:

  1. 写个函数找出某个字串是否以大写字母A-Z开始
  2. 写个函数算出半径已知的圆面积
  3. 将某数组中所有的值累加起来

这些软柿子问题似乎太容易了,所以我得承认,当我第一次开始问这些题目时,真的预期所有人都能轻松回答。不过却发现虽然每个人都解出问题,不过解题所花的时间差别很大。

这让我想起我为什么不能靠买卖证券来谋生。

Jared是个证券交易员。他总是告诉我他做了什么有趣的交易。有种东西叫选择权,还有卖权、买权以及市场陡峭(market steepens),所以你要加注steepener,这一切就让人混淆,不过疯狂的是我知道这些用语的意思,我知道卖权确实的意思(以一定价格卖出某物的权利,而不是责任)。另外如果你拥有卖权而市场上涨,我也能在三分钟之内想出会发生什么事。不过我需要整整三分钟才能想到,而当他告诉我更复杂的故事时(卖权只是其中第一小节,整个故事还有很多其他环节),我马上就投降了,因为脑袋已经晕了(「我们来想看看,市场上涨,表示利率下跌,而卖权是卖出某物的权利...」)要等他拿出图纸开始逐步引导我才会搞懂,我的眼睛呆滞无神,实在很难过。虽然我了解每个小环节,但是我理解得不够快,无法了解整体大局。

程序设计的世界也会有相同的状况。如果对你来说,基本概念没有简单到无需思索,你就无法获得整体的观念。

耶鲁大学的数学教授Serge Lang习惯在微积分第一堂课出一题很简单的代数问题给学生做,这题目几乎每个人都会解,不过有些人解的速度和写字一样快,而其他人则需要一些时间。Lang教授宣称,解这个问题的速度和写字一样快的学生,都会这堂微积分课拿到A的成绩,其他人则拿不到A。解出简单代数问题的速度可以准确预测微积分的学期成绩,预测低效果相当于整学期的作业、小考、期中考加上期末考。

你看,如果不能以每小时一百英里的高速飙过简单的东西,你永远都无法得到进阶的东西。

不过就像我所说的,好的程序员会站起来在板子上写出答案,有时还加上一些巧思(哦!符合Unicode规范!棒啊!),整个过程只花了三十秒,于是我得看看他们是否真的够好,这时就得拿出重武器:递回和指针。

interviewing7.jpg

15年面试程序员的经验让我深信,最好的程序员都有本事能轻易地同时处理多个抽象层次。以程序设计而言,具体的意思是他们能轻易处理递回或使用指针的复杂演算法,前者必须让你的脑袋同时考虑呼叫堆迭中多个层次,而后者中对象的地址有点像对象本身的抽象表示。

我终于明白了解C语言的指针并非技能而是天赋。在第一年电脑科学的课程中,学期开始时总是有大约200个小孩,每个都曾在四岁大时,在自己的PC上用BASIC写过复杂的冒险游戏。他们在大学里学C或Pascal也学得很快乐,而突然间他们就学不会了。他们就是无法再多学会任何东西。九成的学生会退选改修政治学,然后他们会跟朋友说电脑科学课里好看的异性太少,所以才会转换主修。基于某些原因,大多数人似乎生来就缺乏能理解指针的天赋。了解指针需要一种复杂的双重间接思考,这是某些人所做不到的,但对好的程序设计来说却极为重要。很多「脚本语言高手」学写程序都是把JavaScript程序代码片段拷到自己的网站开始,然后再学习Perl,从来没有碰过指针,而他们永远没有办法产生你所需的高品质程序代码。

这就是你曾听说过的这些著名面试问题的根源,比如「反转一个连结串列」或是「在一个树状结构中侦测循环」。

虽然我总认为所有优秀程序员都应该能处理递回及指针,而这的确也是辨别某人是否好程序员的极佳方法。但事实却令人悲哀,现在的程序语言几乎已经完全不需要这种技艺了。在十年前,很少有电脑科学毕业生没修过递回及functional programming,或没上过用C或Pascal的数据结构,而如今很多原本的名校可能都只用Java了。

如今面试会遇到的程序员中,很多都会认为递回、指针甚至数据结构都是呆板的实现细节,它们在很多现在幸福的程序语言中都已被抽象化掉。他们会窃笑著说:「上一次你必须写排序演算法是什么时候的事?」

尽管如此,我并不是真的很在意。即使急救我的医生只需要把电子式电击器的电极放在我胸口,然后按下大大的红色按钮,我还是希望她懂解剖学。同样的,即使Ruby on Rails真能知道你的想法,让你只要点三下滑鼠就能建出完整的Web 2.0社群网站,我还是希望程序员能了解深入到CPU层次的各种程序设计。

interviewing8.jpg

虽然在表面上,面试的形式只是让应征者在白板上写一些程序代码,但我真正的目的在于衍生与程序代码相关的对话。「为什么你要那么做呢?」「你的演算法的效率如何?」「你有没有漏掉什么?」「你的程序错在哪里?」

这意味著我并不真的担心提出的编程问题太难。只要让应征者有些机会开始上路,然后我会很乐意沿路给些小提示,或者说是些小踏脚石吧。比如说我可能会要某人把三角形投影在一个平面上(一个典型的绘图问题),我并不在意提示一下三角函数,提醒他们sin, cos, tan等的定义。而当我要他们想办法加速时,也可能会提示用查表。注意这些我乐于提供的提示,其实都只是琐碎问题的答案,那种用Google就能找到的东西。

你难免会在他们的函数里看到错误。所以我们就来到我面试计画的第五问:「你对这段程序满意吗?」你可能会直接问:「好,那么这段程序错在哪里?」这是标准的开放性烂问题。每个程序员都会出错,这是很正常的,只要他们能找出错误就可以了。以C的字串函数来说,大多数大学生都会忘记替新字串加上结尾的0字符;另外几乎写任何函数时都会有差一(off-by-one)错误。他们有时候会忘了加分号;写的函数不能处理字串长度为零的字串;配置内存失败时会出现内存保护错误...只有极少的机会能遇到第一次就完全无错误的应征者。万一遇到这种状况就更好玩了。当你说「这段程序里有个错」时,他们会仔细的审视程序代码,然后你就能看出他们能否不冒犯面试官,圆滑地声称那段程序代码没有问题。

最后询问应征者是否有其他问题作为面试的结尾。记住,虽然说你正在面试他们,但是好的人选有很多工作机会可以选择,所以他们也是在利用这一天判断是否想替你工作。

有些面试官(interviewees?可能是typo)尝试以所问的问题是否「有智慧」来判断应征者。我个人并不会在意他们问的问题,因于这时我早已有定见。这个作法有个难处,应征者在一天内必须与五到六个人面斌,对他们来说很难问出五六个不重覆的好问题,所以如果应征者没有问题也没关系。

我总是会在面试结束前留五分钟,向应征者推销这家公司和这个工作。即使你不想录用对方,这一点还是很重要。如果有幸找到一个非常好的人选,这时候你会尽你所能确保对方愿意来与你共事。即使对方并不适合,你还是希望他们能喜欢你的公司,而且带著正面的印象离开。

啊,我刚想到应该多提供一些烂问题范例。

首先是要避免违法的问题。在美国询问任何与种族、宗教、性别、原国籍、年龄、兵役义务、退役状况、性倾向、婚姻状况或身体残疾有关的问题都是违法的。如果履历上写著曾待在海军陆战队,就算你想闲聊也不能问对方是不是有去伊拉克。针对兵役状况的差别待遇是违法的。如果履历上写著曾在海法读过Technion技术学院也能问,不管你是想闲聊,还是因为你太太是以色列人,或者只是你爱吃炸豆丸子(Felafel)都一样不能问。针对原国籍的差别待遇也是违法的。

再来是要避免任何可能让人觉得你会在意或会因而有差别待遇的问题,那些你其实不在意也不会有歧视的东西。我能想到最好的例子,就是问对方是否有小孩或是否已婚。这可能会让人有种印象,觉得你认为得有小孩的人无法在工作上投入足够的时间,或是有可能请产假。基本上只问与面试工作相关的问题就对了。

最后是要避免问脑筋急转弯,比如要用六根等长的棒子排出四个一样大小的等边三角形。也要避免问任何和海盗、弹珠、密码有关的题目。这种题目大多数都是那种「原来如此!」的问题,知道了就会,不知道答案时怎么样都答不出来。答得出这些问题,只是表示之前你曾玩过脑筋急转弯。应征者可能只是刚好灵机一动,但你却无从得知对方是否「聪明又能把事做完」。

过去我曾经用过「不可能的问题」,也就是所谓的「信封背面问题(译:在信封背面空白处演算,指没有答案,只能粗略估计的问题)」。典型的例子就像「西雅图有多少个钢琴调音师?」应征者不会知道答案,不过聪明的应征者不会放弃,而且会勇于尝试并估计出一个合理的数字。让我们想想看,西雅图可能有个...一百万人吗?其中假设百分之一拥有钢琴好了?一台钢琴几年要调一次音吧?调一次音应该要35分吧?这些当然全都是错的,不过至少他们有在攻击这个问题。问这种问题唯一的目的就是让你与应征者对话。「好吧,就算35分钟好了,不过在各台钢琴间的交通时间呢?」

「好问题。如果调音师能预先安排好预约时间,就能适当安排日程让交通时间减到最少。你知道意思,星期一把Redmond地区的钢琴全部搞定,而不是一天之内在520公路来来回回三趟。

好的信封背面问题能让你与应征者对话,帮助你评价对方是否聪明。而不良的「原来如此」海盗问题,通常只会让应征者瞪著你一阵子,然后说他们被难倒了。

如果在面试结束时,你深信对方既聪明又能把事做完,而且其他四或五个面试官都同意,那么录用对方应该不会有问题。不过如果你有任何疑虑,最好还是再等看看是否有更佳的人选。

决定是否录取应征者最佳的时点,是在面试结束后约三分钟加右。太多太多公司允许面试官在几天甚至几周后才交出意见。问题是时间过得愈久,记得的内容就愈少。

我会要求面试官在面试之后,无论「录用」还是「不录用」都要马上交出意见,还要附上一两段说明。截止时间是面试结束后15分钟。

如果你无法决定,有个很简单的方法。不录用。不能肯定的人就不要录取。在最初几次可能会有点胆怯,如果「永远」找不到好的人怎么办?没问题的。如果你的履历筛选和电话筛选程序都有作用,面试或许会有两成的录取率。而当你发现聪明又能把事做完的人选时,你会知道的。如果你没有因某人而兴奋无比,就再找下一个吧。

原创粉丝点击