面试时,我会问你什么

最近由于需要在团队中增加人手,陆陆续续的参加了几场面试。于是便有了LinkedIn上“面试面的万念俱灰”的状态更新。依稀记得半年多前,自己也参加了一大批面试,当时也是为了扩充团队。但那时候的感觉貌似比现在要强一些。

“万念俱灰”只是一时间的情感冲动。事实上远没有到那个地步。但这批应聘者整体能力偏低确实超出了自己的想象。尽管已经被提醒过:永远不可能招到完美的人,但发现自己的底线实在是无法再降低了。

每个人去当面试官都会有自己不同的侧重点。但无外乎是考察应聘者的基本能力,对自己实际参与的项目的真实的掌握度,过滤掉简历和面试沟通中的水分。再多一些可能就是看看应聘者的沟通能力,学习能力甚至是抗压能力。

我通常会让应聘者先做个卷子。里面是一些相关技术的基础题,涵盖面比较广,但难度并不大。限时30分钟完成。英文试题但可以中文答卷。我们是个美国企业,对员工有基本的英文读写能力的要求。用英文出题就是为了检查这最基本的阅读能力。如果发现应聘者对题目的理解出现错误,那至少他在这方面没能完全符合我们的要求。理解错的题目可以在后面的面试过程中口头提问,这样也能避免因为他理解错而答错的情况。做卷子的另外一个目的是给到应聘者一定的压力。对于这个级别的招聘,不大可能有人能全部答出题目。如果应聘者在答完题后发现有一部分自己不会,那相对来说他在后面的面试部分会少些水分。其实我个人一般不太关心答案本身的对错。因为都是基础题,答对了不表示水平高,答错了也可能只是因为没接触过那部分而已。

面试部分我会让应聘者自己挑一个他参与的较深的项目做介绍。对我来说,我并不关心这个项目,或者说这个产品是做什么的,有些什么很酷的功能。我希望听到的是该应聘者在这个项目里参与了什么,做了哪些部分,有哪几个模块或者功能块是他做的。在做的时候考虑了什么,怎么设计的架构,怎么做的优化,遇到哪些问题,又是怎么去解决的。

这是个比较容易掺水的部分。很多人会把别人做的讲成自己做的,把别人的设计讲成自己的设计。而我会通过一问到底(通常是追问到代码级别的细节),找出到底哪些是真的,哪些可能不是真的。有些人声称使用了某某框架,多种设计模式。那我会想知道这个框架的架构是什么样子的,能不能画出相应的图例来简单表述。我也会问设计模式中一些比较常见的模式该怎么写,能不能给出示例代码。如果啥框架也没用,那我会要求通过类关系图来介绍整个项目的架构,通过序列图来说明某个行为的流程。(不是所有人都会画类图和序列图的!)

我通常还会问一些相关技术领域里比较常见的问题以及应聘者的解决方案。我会要求对比不同方案的优劣,以及什么情况下该使用哪种方案。

面试时应聘者的态度也会成为考量的对象。你别说,我还真遇到过应聘者趾高气扬,觉得你(面试官)啥都不懂,怎么这种问题都问的人。不过常见的应聘者一般还都比较谦虚,多见的是紧张,有的甚至紧张到结巴。我问出的问题,我并不一定都知道答案。我说我“不太了解”的未必我真的不懂。作为应聘者,能不能以最少的话,最简洁的描述把答案讲清楚,能不能耐心的为面试官细化答案是我非常看重的。我觉得一个无法进行有效沟通的人是会给以团队为单位的开发小组带来消耗的。

作为面试官,我希望应聘者表现的是最真实的一面。没做过,不知道没关系,直接告诉我就行。别在那里瞎忽悠,因为最终还是会被识破(我会把一切我不确定的内容归到“假”的那部分去),并且被扣上“忽悠”的帽子。

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s