我参加过几十场技术面试，其中作为面试官的次数要远多于候选人。

说起来在我第一次做面试官之前，并没有人教过我应该怎么做，我则一直将面试视作通过一小时左右的沟通，对候选人形成一个整体的印象，最后给出一个主观的评价的过程。在这么多次的面试中，我也总结出了一些经验可以和大家分享。

验证简历真实性

首先花一些时间聊一聊简历上提到的项目，请对方进一步介绍这个项目的业务、自己在其中承担的职责和遇到的问题。然后针对其中自己了解的部分提几个问题，如「据我所知这类项目的难点是某某方面，请问你是否有遇到、是如何解决的」，确认对方的项目经验是否真实、是否比较深度地参与了项目。

围绕简历提问

尽量提问对方了解和擅长的话题，让对方有足够的表达机会，发挥出正常水平，考察候选人擅长的部分要比不擅长的部分更有价值。

开放性问题

避免问有标准答案的问题，而是可以问「遇到某种情况时可能是什么原因、你会怎么做」或「请解释一下某个事物是如何工作的」这样开放性的问题，给对方足够的发挥空间、主动提到一些自己的知识和经验。

也许有些候选人不喜欢这样的问题，认为缺少安全感、不知道该说什么，但我觉得开放性问题才有足够的区分度，才能在短时间内对候选人形成立体的印象。我们可以在候选人实在不知道从何说起时，对问题再做进一步的解释和提示。

围绕话题由浅入深

应该针对同一话题准备多个难度逐步增加的问题，让对方回答时思路能够相对流畅，更容易考察对方在这一话题上的深度；反过来应该避免大量零散、无联系、无难度区分的小问题。

没必要执着于答案

有时在反复提示下对方的答案仍差那么一点，在面试时间大多比较紧张的情况下，我们没必要花更多的时间去让对方答出答案。在候选人表示无法准确回答问题时，也可以引导他做出一些合理的猜测（这时的重点在于猜测是否合理而不是是否正确）。只要候选人在这一问题上说足够多的话，我们就可以考察到其水平了，不一定要等他说出最后的答案。

自己不懂也没关系

在一开始，我会担心问出的问题我自己也不了解，对方回答之后会把自己问倒或者无法考察对方水平。但后来发现完全没有必要，因为面试官没有义务即时地对候选人的回答做出评价（告诉对方对还是错），即使对于不了解的话题，自己也可以从对方的自信程度、逻辑层面，对回答有一个大体的判断的。

现场编码可以很简单

候选人在现场会非常紧张，面试时间也有限，在现场编码环节没必要出太难的题，重点在于考察候选人是否有最基本编程思维和编码能力。例如我觉得一些难度不高，但适合用递归解决的题目会比较合适，可以考虑在候选人编码的过程中一直保持沟通，注重过程而不是结果。

同时我反对为候选人在面试前或面试后布置编码的作业，这会让候选人付出不对等的时间去准备面试，也很容易从「考察候选人的能力」变成「考察候选人的诚意」。

重复使用一套题库没什么问题

可以自己建立自己的面试题库，在一次次面试中对其进行反复地打磨，让问题更准确、考察更全面。有些话题可能是永远都不过时的，例如对于后端工程师可能是并发模型及与之相关的线程、内存等话题。

给对方提问的机会

一般面试的最后一个步骤是让候选人提问，不要把这个过程敷衍掉，可以引导对方提问，告诉对方都可以问哪些问题。如可以补充一下没有提及的技术话题、可以问我司的技术架构或选型、可以问所面试的职位和如果入职之后所参与的项目、可以问日常工作环境和时间等。这样可以让对方有一个主动打开话题的机会，互相判断需求是否匹配，即使没有通过面试也让对方对公司有一个比较好的印象。

有任何顾虑都可以 pass 掉

我们前面做了这么多都是为了让候选人有更好的面试体验、发挥出自己最好的水平。这种情况下如果仍对候选人某一方面的表现有顾虑的话，应该果断地拒绝掉，招进来一个不合适的人损失远比错过一个合适的人大。

沟通是否顺畅很重要

沟通是后续开展一切工作的基础，如果觉得与候选人的沟通不顺畅，对方总是不能理解自己的意思，那么即使候选人的技术水平满足要求，也应该慎重考虑。

留下面试的记录

我每次面试结束后都会尽快开始写对候选人的评价，大多在一两百字，先列出面试聊到的内容、觉得好和不好的地方、了解到的对方的技术栈，然后总结一下对候选人技术水平和沟通情况的评价。这样可以帮助自己整理思路，在候选人比较多的时候也不会记混，最后给出通过与否的评价，同时还能给下一轮的面试官提供参考。