经历100多场面试之后，一位面试官给软件工程师的建议

有这么件事，相当棘手，给人压力，有点像希腊神话里赫拉克勒斯面对的12项艰巨考验——通过考验就能成为英雄，可是又有点像马戏团里的动物跳圈圈，没啥意思，这个事就是面试。

人人都讨厌面试，但它是我们职业生涯不可避开的一部分。

当作者带着几分天真，第一次勇敢地参加技术面试时，没过多久，他就觉得要在两三个小时之内判断一个软件工程师的能力，准确程度跟中世纪的刑侦手段也差不多。

但是，他一直好奇，怎么才能像桌子对面的面试官一样，了解一个工程师是否适合某个岗位。

过去几年里，作者作为面试官经历了100多场软件工程技术面试，虽然各家公司有各自流程，面试者往往会掉入一些共性的坑。

如何避坑？下面是他的诚实建议。

好的软件工程师

“成功之路与失败之路几近相同。

”

– Colin R. Davis

何谓“好的软件工程师”，并没有唯一的定义。

它与岗位的需求有关，与公司的多元性和成熟度有关。

一家初创公司无疑是要尽快让产品进入市场，而一家更成熟的公司，在客户群增长之后，可能需要面对的是尺度和架构上的挑战。

在理解业务的同时构建产品，这跟解决复杂的技术挑战不是一回事。

一个细节完美主义的工程师和一个快速迭代的工程师也是不同的。

你需要知道公司在找什么人，然后把自己的行为和话语框定在公司的思路里。

不要做一张通吃的简历，要根据实际情况进行调整。

如果你必须做一个自我推销（某种程度上，你总是要做一个自我推销的，不管是否正式），你要展示你将能成为这个公司的有用之才。

你应该了解一个岗位为何不可或缺，并问问自己这点能否激励你，如果能，就接受它。

你应该弄清楚在这家公司的语境下“好”是怎么定义的，然后来展示你的知识、经验和态度确实符合这个定义。

提前做功课

“在准备工作上的失败，已经为失败做了准备。

”

- Benjamin Franklin

去面试却对公司一无所知，就好像去约会却只谈论你自己，不敢说你就没戏了，但是人家对你印象肯定不会太好。

下点功夫了解公司业务，公司的宗旨、使命、战略和成绩。

作者表示自己不会因为面试者对此一无所知就把他挂掉，但这点反映出他的动机不足。

这也是HR评估面试者的一个标准依据。

在业务目标之外，如果公司有技术博客那一定要查看，了解他们的技术栈。

面试者并不经常表现出对公司的足够兴趣，但如果他们这么做，就是脱颖而出的绝佳方式。

具有批判性思维

“受过教育的头脑的一个标志是，能够审视一个想法而非径直接受它。

”

- Aristotle

在职业生涯中作者曾遇到过杰出的技术专家，这些人个性都不一样，但至少有一点是他们共同具备的：他们是那种挑战现状，使工艺和技术得到改进的人。

很多应聘者在被问到是否有问题时，都说没有要问的。

不去提问等于是浪费机会，应该抓住这个时机，问一下公司做出的技术决策和面临的挑战，讨论一下各项技术的利弊。

例如：

他们是否在考虑转向HTTP/3了？

他们是否正在转向事件驱动的微服务架构？他们在使用什么样的消息代理？为什么不使用 Kafka来替代RabbitMQ？

他们使用的是什么数据库技术？用例是什么？在该用例中，ElasticSearch是否是SQL的良好替代品？

等等。

对技术决策的问询将表明，你不仅了解这些技术、可以论证何时该使用这些技术，而且可以批判性地思考，并且你很在乎改进你工作中所用的应用程序。

技术挑战

再多的实验也不能证明我就是对的，但只要一个实验就能证明我是错的。

- Albert Einstein

当前的技术面试不近人情，存在着相当直接的不公，足以令人震惊。

大多数面试里都有跟计算机科学基础相关的算法问题，比如图搜索或排序算法。

作者听说过一个传闻，一个应聘者被要求以最小的资源来实现一个tree transversal算法，所以当他得到这份工作时，首先要做的是调试一个十年前的单片机。

经历过应聘者和面试官的双重角色之后，作者觉得这种自命不凡的试图美化我们工作复杂性的做法令人沮丧。

这样的挑战很可能会让对这些概念已经因长久不用而生疏的高级开发人员望而却步，尽管他们可能在这个岗位上拥有极丰富的经验。

作者同意这类练习并非完全无用；快速解决小问题的能力与解决跨度数天的复杂问题的能力是相关的，但两者有本质区别。

面试过程应该尽可能地反映日常工作的实际情况。

他觉得有些方式比刁钻的算法问题要合适得多，比如在真实的应用程序上寻找和修补bug，结对编程，或者实现一个自动化测试。

对于这类场景，面试者一定要对公司选择的编程语言能得心应手，不要害怕提问，以理解任务的全貌。

不过，在大多数面试里，你都会面对一些算法或数据结构的问题，这个没办法绕过，你得有良好的计算机科学基础知识。

像《Cracking the coding interview》这本书、Leetcode或者Pramp等等都是不错的参考资源。

无论碰到哪种问题，一定要把你的思路大声说出来。

通常情况下，问题都是层层叠加的，只要你能出色地解决剩下的问题，哪怕是中间有一步失败了也没关系。

如果你卡住了，面试官会帮助你。

对面试官来说，关键是看应聘者能否在经历一个不熟悉的题目后恢复状态，做好接下来的题目。

另外，有经验的面试官可能会在你解题吃力的时候，由提问题改为教你怎么做，不要把这种改变理解为失败，这种情境变化有助于大多数人跳出解题中的困境。

面试官这么做是为了帮助你，并在帮助的同时评估你，而不是一上来就评判你。

把他看成一个正在指导你解决问题的老同事，跟他讨论解决问题的不同方案和其间权衡，这将展示你对问题的了解程度。

别灰心

成功就是爬起来的次数比跌倒的次数多了一次。

- Oliver Goldsmith

作者曾经见过一个应聘者，在面试的时候很是战战兢兢，缺乏信心。

尽管他缺乏自信，总是怀疑自己，但他问题解决得很好，所以还是被录用了。

但是安顿下来之后，在日常工作中他非常自信，能够引领讨论，在技术课题上指导团队。

后来作者问他，怎么在面试的时候心态这么差？他解释说，他有过一连串灾难性的面试，当时面对可能的被拒，心态不是太好。

被拒是面试的一部分，不要让它掌控你。

用几个小时来评估与软件工程师相关的全部各项能力，本来就不可能。

所以每个面试都会选择公司关心的能力，用尽可能好的方式来评估。

面试官选的可能是你擅长的，也可能不是。

糟糕的雇员对公司来说是棘手的，尤其是他们所在团队的士气会受影响，同时人力成本也很高。

再加上很多公司没有一个标准化的流程（重要的是比较候选人，所以每个面试官应该给出同样的题目，同时应该有一个规定流程，每个面试官都走这个流程），你会遇到相当比例的假否定。

也就是说，面试结果不好，并不意味着你很差。

而是意味着你所表现的能力在那个特定时间里、特定流程下不是最好的。

作者称，如果自己面试失败了，然后读到或听到上面的话，肯定也觉得这都是扯淡。

在生活中，他一直试图成为一名拳手。

有一些时候，他输的太多，一个总输的拳手，充其量就是个沙袋。

然而，有时你必须找到内在的力量，把自己从躺倒的废墟中拖出来。

站起来，举起手来，再打一次，不要让失败掌控你。

激情关乎一切

“工作会填充你生活中的一大部分，要想让自己真正满意，唯一的方式就是去做你认为伟大的工作。

要做伟大的工作，唯一的方式就是热爱你所做的事情。

如果你还没找到，那就继续找，别停下。

跟随自己的本心，在找到的那一刻，你会知道自己找到了。

”

- Steve Jobs

当我们在日常生活的困惑和混乱中前进时，我们渴求那些清晰的时刻：在挑战或任务当中达到完全的忘我，时间弯曲，现实消隐。

在这些非凡的超越时刻，好像整个一生都会在不经意间流逝。

这就是编程对我们许多人所具有的意义，那是刻在我们内心深处的永恒而坚定的激情。

同样的激情，也是成功的秘诀。

作者见过一些应聘者在面试过程中表现出色，但被录用之后却表现平平。

他们并不差，他们有天赋，也懂行，但他们的表现只是平平。

有时候，你擅长的事情并不是你真正喜爱的，但唯有激情才会促使你成功。

要评价一个软件工程师是否有激情并不容易。

但如果他问你做过什么业余项目，或者你做过的最好的项目是什么，你可能会热烈地讨论若干项目，花上整整一个下午。

不管你的项目是一个百万用户级的平台，还是一个勉强运行的业余项目，这都不重要。

一个充满激情的程序员会热情洋溢地描述他用到的每一个方案，完成的每一次挑战，甚至是每一次搞砸和失败，带着喜悦和怀念。

然后，任何一个面试官都会知道，对面的人和他一样，是一个对写代码充满无可救药的激情的程序员，同道中人。

这是一种非常真实的反应，你几乎可以从他们的眼睛和肢体语言中看出来。

要么充满激情，要么没有。

如果你属于前者，一定要谈那些打动你的项目，这将区别一场平淡的面试和一场出色的面试。

结束语

作者一直觉得，作为应聘者的压力就是知道自己需要得到这份工作，需要证明自己足够优秀。

面试官的角色并不是完全没有压力，面试官要确定有充分理由认可或者拒绝一个人。

这样，做的决定才经得起审核。

对他来说，一直如此，对得起我的良心。

大多数面试官都要在某些时候被别人面试，所以他们是通情达理的。

作者希望从面试官的角度帮到大家，真诚地希望这些建议能助你获得心仪的工作。