100 lines
13 KiB
Markdown
100 lines
13 KiB
Markdown
|
# 答疑课堂02：面试实践篇热点问题解答
|
|||
|
|
|
|||
|
|
你好，我是四火。
|
|||
|
|
|
|||
|
|
又到答疑课了，这一讲主要是围绕第二大板块的“面试进行/实践篇”的主要内容叙述的。这一讲中，我将回答一些专栏正文内容之外的热点问题，因为从面试角度看这些问题也相当重要。
|
|||
|
|
|
|||
|
|
**问题 1：面试官对候选人谈及的业务或技术不甚了解时，如何把控局面？**
|
|||
|
|
|
|||
|
|
好，我们先谈一个频繁出现的问题。在面试官和候选人的沟通过程中，一旦把话题谈论深入一点，特别是在候选人介绍项目、介绍系统的时候，就很容易出现候选人大聊特聊，面试官却听不懂的情况，那么，我们该怎样把控这样的局面呢？
|
|||
|
|
|
|||
|
|
**首先，摆正交流的心态，正视彼此认知的交集与盲区。**每个人背景不甚相同，你有你的领域，我有我的专长，既不需要惭愧，也不需要惊慌，这非常常见。
|
|||
|
|
|
|||
|
|
其实反过来也一样，某一方面内容，也许你觉得它是“常识”，甚至觉得理解它是“理所当然”，那么假如对方不知道，你也请继续保持谦逊平和的心态，保持“职业修养”。也许这的确是一个很简单的道理，但要知道自卑与自负同样来自人性，因此有时候这一点并不容易做到，需要时不时提醒自己。
|
|||
|
|
|
|||
|
|
**其次，判断为什么觉得自己“不了解”或者“听不懂”，是因为自己对通用的业务或技术领域缺乏认知，还是候选人的思路与表达有问题？**
|
|||
|
|
|
|||
|
|
比方说，假如候选人介绍他做的项目，那么通常他需要说明，这个项目的背景是什么，系统的用户是什么，他在其中做了哪些事，最后有着怎样的结果等等。这些内容，对任何一个“外人”说，都是不了解的，面试官也不例外。
|
|||
|
|
|
|||
|
|
这就不是一般意义上的“缺乏认知”了，面试官可以通过几个问题介入，通过有来有回的“沟通”，而不是单纯地听候选人的叙述，理解他介绍的内容。
|
|||
|
|
|
|||
|
|
**再次，谈及具体的业务或技术的时候，把“请候选人介绍”，变为“向候选人请教”，即便自己对它相当了解。**近似的问题，问法不同，可能效果会大不相同。
|
|||
|
|
|
|||
|
|
举个例子，候选人说，他优化了某个缓存的开源库中，锁竞争的逻辑，使得它在高并发的场景下，实现了更好的性能。那么面试官无论对这个库是否了解，都可以这样问：
|
|||
|
|
|
|||
|
|
> 我听说过这个库，能否趁此机会向你请教一下，它原来性能上的缺陷在哪里，而你又做了怎样的修改提升了它的性能？
|
|||
|
|
|
|||
|
|
为什么这样的方式有时会有更好的效果呢？因为一方面是“示弱”，面试官主动暴露给候选人自己的“无知”一面，而非高高在上，候选人会下意识提升信心；另一方面也能向候选人明确，面试官的知识背景，候选人会根据这一情况，调整他的陈述方式，以尽可能直白、充分和清楚。
|
|||
|
|
|
|||
|
|
事实上，一个好的面试官，不应该说太多，反而更应该成为一个倾听者。在候选人介绍业务或技术的时候，无论有多了解，都是一个很好的倾听的机会。**这样的方式能有效帮助候选人抛开顾虑，更“敢说”，尽其所能把这些问题表述清楚。**
|
|||
|
|
|
|||
|
|
如果面试官对这个业务或技术本来不了解，藉由候选人清晰的表述，依然可以获得更好的沟通，进一步了解候选人的真实一面；而如果面试官实际对它是有一定了解的，那么可以更好地判断出候选人是不是真正理解它。
|
|||
|
|
|
|||
|
|
据我观察，一些面试官无法放下身段，听不懂就“嗯”、“啊”过去了，候选人也就认为听的人知识渊博，相应地简化陈述，想避免啰嗦，这反而不利于面试官获得真实的考察数据。
|
|||
|
|
|
|||
|
|
**问题 2：面试过程中，发现候选人作弊，该如何应对？**
|
|||
|
|
|
|||
|
|
作弊或撒谎的情况其实并不少见，我在面试中就遇到过多次。有一次，在我们谈论一个算法的时候，候选人忙着敲键盘在互联网上搜索，无论是敲键盘的声音，还是视频里眼镜的反光，都暴露了他的“行踪”。
|
|||
|
|
|
|||
|
|
印象最深的是某次校招，有一个笔试环节，候选人线上答题，最后笔试得分排名靠前的十位里面，居然有好几个都是从某处拷贝了题解，整个粘贴到答题页面，然后再修改一下变量名、方法名、注释和格式。候选人可能以为代码提交前面试官一无所知，殊不知整个过程都被答题工具记录下来了。
|
|||
|
|
|
|||
|
|
如果在面试中遇到类似的情况，我们该怎样应对呢？**我听过许多不同的看法，我的建议是，不要戳穿，不要质疑，一如既往地继续流程，但在这个过程中注意收集事实数据。**
|
|||
|
|
|
|||
|
|
在面试后的决策会环节，可以首先提出这一点并与其他面试官交换意见，看看是否有类似的观察。作弊是品德问题，在一些企业中，遇到这样的候选人，是要列入黑名单中的，后续他的再次应聘，直接会被系统拒绝掉。
|
|||
|
|
|
|||
|
|
例如在我工作的公司OCI（甲骨文的子公司）中，除了Hire / Weak Hire / Weak No Hire / No Hire 这几个选项以外，还有一个很少使用的 Never Hire，就是为这种情况准备的。这类严重的品德问题在决策会一开始就可以在Bartender的引导下进行确认，一旦事实清楚，后面的流程就可以跳过了（这也几乎是实际操作中，唯一可以快速结束决策会的情形）。
|
|||
|
|
|
|||
|
|
**问题 3：如何在面试中“推销”自己的公司和团队？**
|
|||
|
|
|
|||
|
|
我在 \[[开篇词](https://time.geekbang.org/column/article/359007)\] 中说过，面试这个过程是双向的，很多人忽略了这一点。所以市场有些时候是买方的，有些时候是卖方的，这一点随时都在改变。因此我们在考虑考察角度的时候，也别忘了审视自己具备什么。
|
|||
|
|
|
|||
|
|
从公司的角度来说，不同的公司有不同特质，大公司在待遇上丰厚一些，小公司则能提供有挑战性和独立性的工作机会，而创业公司，则能够给以未来的期许。从团队的角度来说，也有类似的分析，即你的团队，能给候选人提供什么？
|
|||
|
|
|
|||
|
|
如果对方是优秀的软件工程师，通常不缺有竞争力的机会，那么如何在竞争中赢得青睐，这是面试中面试官需要向对方“推销”的内容。
|
|||
|
|
|
|||
|
|
对，你没有听错，在面试的时候，面试官绝不是一个高高在上的考官，而是一个平起平坐的工作伙伴，面试的过程就是一个互相体验工作氛围的过程，并且**遇到了优秀的候选人，一定要找机会向对方介绍目标团队，这样的机会比宣传册上的文字更接地气。**
|
|||
|
|
|
|||
|
|
举例来说，某团队有做分布式基础设施的机会，这更合候选人的胃口，而且团队规模和产品规模都还不大，属于较早期，工程师的工作更容易产生影响力，这就是很好的可用于“兜售”的内容。这件事情，不只经理面试官可以做，工程师面试官也可以做，而他们的角度是不同的。
|
|||
|
|
|
|||
|
|
你不妨回想一下，我们的专栏很详细地讲了怎样设计问题，怎样主导面试。别忘了这也正是一个展示自己团队的好途径。对于候选人来说，**能有一个不住回味的面试体验，能够在面试中和面试官讨论得充实、开心，这不就是一个理想工作机会的金字招牌吗？**
|
|||
|
|
|
|||
|
|
但是，反过来，我们也要坦诚告知公司和团队的局限。在沟通过程中，我们可以询问对方的近期目标、远期目标，对于公司和团队的要求等等，得到对方的期望，如果和团队能够提供的差得比较远，那么双方就没法具备合作的机会。
|
|||
|
|
|
|||
|
|
**这一点，不能光靠直白地询问，还要靠多次的旁敲侧击，因为有时候选人口中的期望，和他心中的期望其实不一致。**一般来说，我们希望这方面在电话面试的时候就已经大致确认清楚了，但是如果遗漏了，到了现场面试的时候就要补上。
|
|||
|
|
|
|||
|
|
举个例子，候选人说，他很希望做大数据的项目，而自己的团队却明确没有这样的机会，那么就可以进一步打探，对方对这个要求有多看重。如果这个愿望很强烈，那么我们的团队即使发了offer，也很可能是一个陪跑的角色，候选人加入了也呆不久，这种情况下，可以考虑公司其他团队能否为候选人提供机会了。
|
|||
|
|
|
|||
|
|
再有一个典型的例子，是关于oncall的，有的团队ops压力比较大，这一点不需要隐瞒，可以指明，给出诚实的预期，如果对方非常介意，那自然也没有办法继续下一步了。
|
|||
|
|
|
|||
|
|
**问题 4：怎样主导自由提问的环节？**
|
|||
|
|
|
|||
|
|
在面试结束前，我们尽量要留出两三分钟的时间，给候选人一个问问题的机会。不是说每轮面试非得保留这个机会，但是，这是一个进一步沟通和展示的好机会。有些时候，候选人有问题，但是没有机会问；有些时候，候选人能和经理能够进行充分的沟通，但是却没有机会和工程师聊一聊。
|
|||
|
|
|
|||
|
|
回答要得体，因为你代表的不是你个人，而是公司和团队。我觉得比较可信和诚恳的回答，都是面试官从自己的角度出发，举例而谈的。一般这种情况下，**不要使用夸张的表述，也不要去贬损其它公司和团队。**
|
|||
|
|
|
|||
|
|
有些时候，有些问题属于自己并不熟知的领域，那也可以增加一个“声明”，向对方表示一下自己并不熟悉，以免一面之词误导对方；而还有些时候，那些问题不适合回答，那就直接指出，不要越界。比如，可以说相对于自己，某位其他人更适合回答这个问题，像是候选人询问薪资，一些公司是要求面试官闭口不谈的。
|
|||
|
|
|
|||
|
|
在具体回答问题的操作上，我在这里给你提供这样几个小技巧：
|
|||
|
|
|
|||
|
|
* 首先，如果问题含义不清楚，先确认问题。一定要领会候选人具体想问什么，有时候，候选人会绕弯子，隐晦地表达；有时候，则是表意不清，或有歧义。无论是哪种，只要不清楚，就先确认清楚问题。
|
|||
|
|
* 其次，先评价问题，再回答。在问题清楚的情况下，可以对于对方的问题适当地表示认可。比如说，可以泛泛地说“这是一个很好的问题”，之后再回答。
|
|||
|
|
* 再次，在回答后，可以再次确认。比如可以说，“不知道我的这个回答是否解答了你的疑惑？”。
|
|||
|
|
|
|||
|
|
**问题 5：怎样在观摩的面试实践中指导其他面试官？**
|
|||
|
|
|
|||
|
|
观摩（shadow）是一种很常见的快速学习和上手的形式，开会可以观摩，oncall也可以观摩，面试实践也一样。
|
|||
|
|
|
|||
|
|
具体怎么操作呢？就是新手面试官寻找一位有经验的面试官，像影子一样观摩其组织和参与面试流程的整个过程，从中学习并加以思考。因此，如果有别的面试官希望shadow你的面试，或者说观摩你的面试过程，学习你的经验方法，那么祝贺你，这是对你能力的一种认可。
|
|||
|
|
|
|||
|
|
具体操作上面，我相信你会有自己的“套路”，我在这里给你分享一下我的做法。**简单来说，就是把自己的面试流程完整地呈献给对方，并提供面试前、面试后和决策会后的三次沟通机会答疑解惑。**
|
|||
|
|
|
|||
|
|
首先我会跟该新手面试官做一个简短的沟通，叙述一下大致的流程，从面试计划、面试进行到决策会，都有大致的哪些内容。如果他有问题，也顺便做一个解答。面试计划等过程中的邮件传递、材料发送等，也要抄送给他。
|
|||
|
|
|
|||
|
|
在面试过程中，主面试官需要向候选人介绍这位shadow的面试官，但他在面试过程中，通常是较少参与沟通的，而是在一旁安静地观察和思考，并做记录。这主要是因为，一旦参与了沟通，就容易影响到主面试官的计划安排。在面试之后，可以和这位新手面试官一起快速碰个面，趁着面试的过程在脑海中还新鲜，交流一下彼此的想法。
|
|||
|
|
|
|||
|
|
在决策会的环节，shadow的面试官通常是不参与投票的，但是可以表述他的观察，但是大家需要清楚，他的表述和主面试官的表述，针对的都是同一轮次而得到的反馈，不能算做两个独立的数据点。在决策会之后，两位面试官还可以第三次碰头，在沟通中做个回顾，这三次交流的用时都很短，也许每次10分钟，但作用却很关键。
|
|||
|
|
|
|||
|
|
今天，我和你聊了聊我对面试实践环节的几个热点问题有什么看法，希望这些内容对你有所帮助。如果你有问题，也欢迎在留言区提出来。
|
|||
|
|
|
|||
|
|
好，我是四火，我们下一讲见。
|
|||
|
|
|