Tech 公司面试杂谈

从大学找实习开始，断断续续面试、被面试了许多场，想来应该有三位数了，最近又作为 Senior/Leader 岗位面了一些公司，算是补全了一块人生体验，写篇文章谈谈 Tech 公司面试的感想。

算法

谈到算法面试，首先想到的是 LeetCode，这不是我想的，是 Copilot 想的。

算法是讨论到面试绕不开的话题，我懒得考古，但这股“歪风”应该是从硅谷几家 Big-name Tech 带起来的。这个选择是非常明智的，算法竞赛作为面试的核心部分有非常多的好处：

• 形式上标准化，可以避免很多不必要的争议（但也只在形式上）
• 题库非常大以至于不可能全靠死记硬背。通过面试的候选人下限有保证，具备能写 CRUD 的基础 coding 能力，有行动力且愿意花时间刷题，具有一个螺丝钉必要的品质
• 面试官完全不需要提前准备，在题库中随机 Pick 一道题就能面试，减少公司面试的成本

印象最深的是我校招时 Airbnb 北京的面试，面试官甚至不会给时间自我介绍。任何关于项目的沟通都必须在解完题目之后。那天有一面我状态不好，以至于我和面试官没有哪怕一分钟的时间交流题目外的内容。

但当将算法面试应用于 Senior 招聘的时候，事情就变得抽象了起来，算法面试事实上衡量的是一个人算法能力相对大学的退化程度。最能做算法题的人，一大半是现役高中生（或者本科生），而剩下的一小半，是曾经的最强算法高中生。90% 的 Senior 工程师，算法做不过 Junior 时候的自己，这是一个应该考察人成长的阶段，但是结果是人吃老本的水平，很难说是一个有效面试。这个道理曾经的我也不懂，刚毕业在旷视工作的时候 Leader 经常让我作为一面考察一些 Senior 的 coding，我常常讶异于他们为什么算法那么菜，直到最近我“接雨水”写了四十分钟才写出来 :(。

一个曾经我很认同的观点是，做 Infrastructure 对算法能力的要求更高，相比 CRUD 来说，各个系统都需要用到一些复杂的算法，因此，在这种情况下，算法面试就变得尤为重要。这个观点的前提是对的，但结论是错的。Infra 需要用到的算法很难，特别是在 RisingWave 工作的这段时间，许多常用算子的增量算法往往都要想不少时间。但这在整个 feature 落地的过程中无论是消耗的时间还是复杂度都占比不到 10%。同时，在 30-40 分钟里切题的能力和有充分的时间去思考工程上真正需要解决的问题和方案，中间也存在着巨大的 gap。

System Design

System Design 作为面试形式的上下限差异极大，事实上，对面试官提出了很高的要求。面试官必须有丰富的系统设计经验，且本身对题目已经有非常完善的思考了，甚至最好是项目上真实遇到的需求。System Design 的答案本身就是开放性的，更多的是对交流过程中思路的考察，互相之间的启发，而不仅仅是对答案。在之前的一场面试中，我遇到了一道性能优化的题目，它的背景大约是使用一台 8GB RAM 和 1TB 硬盘的服务器，优化某种场景的查询。而当我追问硬盘是什么类型，是 SSD 或者 HDD，读写性质是什么样的，面试官的回答是不知道。我猜测这不在那道题的考察点上，但在我看来这种去匹配答案的形式完全不适用于 System Design 的考察形式。

如果像算法题一样，面试官仅仅是从题库中 Pick 一道题并阅览一下参考答案就去面候选人，那么最终的面试效果甚至还不如算法题。一方面，候选人很多合理的设计思路会因为面试官的短视而被否定，另一方面，由于 System Design 的题库相比算法题要小很多，如果面试官不会做任何的变通，很容易被刷穿题库的候选人轻松拿到 Strong yes，而实际上完全无法达到水平考察的目的。

“共享面试”

“共享面试”是一个不存在的形式，确实一个客观存在的概念。在你投一家公司的第一天，HR 就会问你现在的总包作为参考，有些公司甚至会有一些离谱的规定，比如不允许给候选人涨幅超过一个固定比例。同时，HR 们也会互相追问友商给你的工资（尽管他们还会同时你 Offer 需要保密），作为一个基数来决定或者调整 offer。

这在很大程度上，就是因为一家公司三到四轮的面试太短，以及可能形式上存在上面所说的种种问题，很难真正地确定候选人的能力和匹配程度，因此借用了候选人的上家，以及其他认可的友商的面试成果，一种事实上的“共享面试”出现了。

而这个明面上不存在的面试形式，却是决定候选人最终 offer 的关键因素。

乍一看，“共享面试”并不是一个糟糕的 idea，解决了一家公司能占用候选人的时间过短的问题，从概率意义上增加了候选人匹配的程度，然而这是一种非常低效且不确定的形式。每家公司的面试方式是高度雷同的，相当于把在与 GPT 的对话中 temperature 调得很低然后多次询问试图提高结果的准确性，实际上的效果非常存疑。

Assignment

这是一种一直不温不火的面试形式，不火的原因是占用候选人过多时间，太容易被候选人挂上脉脉，被骂剽窃候选人的劳动力。这里也分两种，一种是将公司内项目的一些任务提炼一下得到一份脱敏版本，作为候选人的 assignment。另一种则是一些开源项目的商业公司，直接将 issue assign 给候选人，然后在 review 的同时对候选人能力做一个评估，顺便清理一些项目里低优先级的 backlog issue。

相比于 Assignment 本身，我更认可 Co-work 的面试方式。在这个任务的完成过程中，面试官也应该花费同等的时间，与候选人协作，通过保持连线甚至直接使用一些协作编辑的方式，共同完成这个 feature。在这个过程中，观察候选人习惯的阅读、编码、调试、解决问题等的方式；当候选人遇到一些项目本身的不足带来的困难时也及时给予指正，免得浪费无谓的时间。观察候选人是否能用合适的方式与同事沟通（例如请求是否足够清晰，让被求助人最快理解问题），获取帮助，也是工作内容中相当重要的一部分。

除此之外，作为候选人，在一些 Assignment 的完成过程中，我遇到的更多问题往往是 quick start 文档缺失、调试困难、一些配置项隐藏过深等。完整的审视一个新人参与项目中遇到的困难，对拥抱开源的项目来说也是很好的补充。

Show your contribution

面试始终是对工作内容的抽样调查，无论如何高效地利用，想在若干小时内对一个人的工作能力全面了解都是不可能的。这就是给开源项目打工的重要魅力之一。一个好的 GitHub 主页，是对个人能力的最好展示。我作为面试官时，如果候选人贴了 GitHub 链接且有一些个人项目或者对重要项目有贡献，我都会挑一些我比较感兴趣的 PR，真正地从一个 reviewer 的视角去过一遍。如果说那么好的面试就可以对候选人的工作能力了解达到 20% 以上，那候选人如果有开源的全职工作经历，了解程度就能达到 60% 以上。

不要吝惜时间

从一个候选人的视角来说，对于真正感兴趣的公司，我并不介意面试花费更多的时间去做一个自我证明。我反而会觉得只通过写两道题来了解我是相当可惜的，有很多信息可以互相沟通了解，而不希望最终拿到好 offer 的原因是另一个好的友商给了一个不错的 compete offer。

从公司的视角来说，用更少的成本快速找到合格的螺丝钉固然是 Big-name tech 的核心需求，却并不适用于大部分公司，让面试官在一个候选人身上多花费一些成本来提高匹配程度，对很多公司来说是很划算的。

这里可以看出面试官在面试过程中的重要程度，然而好的面试无论如何都需要面试官花费更多的时间去准备，从公司层面再细分来说，更详尽的面试对 Leader 来说自然是利益趋同的，但对普通的技术面试官来说，就未必愿意占用自己完成工作的时间来准备。这也是为什么标准化面试受欢迎的一个原因。如何设计对面试官的反馈机制是一个难题，这篇文章作为一篇碎碎念就不赘述了，等我理解加深的时候再来补充。

写在最后

面试形式与效果是非常多的 big tech、独角兽思考过的难题，同时它也像 system design 一样，是真正的开放性难题，根据不同的场景、需求自然会有不同的结论，所以这篇碎碎念没有答案，只是剖析一下现有的面试形式作为一些个人思考，也希望无论作为面试官还是候选人都能从中找到一些共鸣。