转载

我对技术面试的理解与认识

面试，特别是技术面试这个话题比较大。每家公司、每个技术团队都会有自己的一套适合于自身的面试手段、方法与流程。从这个角度来看，面试其实是没有什么既定路线可循的。因为不同的面试官提问问题的方式、角度与问题偏向性及质量都是有着巨大差别的。这一方面与公司对于面试的要求有关，另一方面也与面试官本人的技术特点、关注的角度以及自身能力水准有着千丝万缕的联系。鉴于此，想要通过一系列系统化的培训来准备面试我认为只能解决一些表面问题；毕竟，技术这个东西不是靠几天的突击就能搞得定的，还是需要依靠平日工作及业余时间的逐步积累，别无他法。

纵然如此，我个人认为技术面试，特别是一些重视技术的互联网公司的技术面试还是存在一些相通的地方。在平日的工作过程中，包括工作之余的时间中，不断积累，脚踏实地，实际上是对自己最好的回报。在做项目、做产品的过程中，除去完成工作所规定的开发任务外，自己多花些时间想想、多思考、经过一段时间给自己做一次系统化的复盘，都是促进自身成长的好方法。毕竟，个人成长才是我们应该重点考量的一个因素。个人成长不是公司给予你的、也不是周围人给予你的，更不是一种外在因素对你的施加，而是应该由内而外发自内心的渴望。个人成长包含的因素很多，比如说思维方式的升级、技术水平的跃升、工作效率的提高、家庭生活的幸福、正确处理好各种人际关系，健康的体魄等等，不一而足。这里将专门针对技术这一角度谈谈我的一些看法。

工作这么多年来，经历过大大小小的面试也不少了。印象最为深刻的当然还是研究生毕业找工作时的各种校招面试。其中尤为突出的就是毕业后所加入的公司理光软件研究所的面试了，时至今日，我对这场面试的各种细节还记忆犹新。一方面，理光是我毕业后的第一份工作，在那里工作了3.5年的时间，可以说我现在工作的很多好习惯都是在那个时候养成的，比如说严谨、良好的文档（文档不仅要给自己看，更要让其他人可以在不找你的情况下仅凭借文档就知道接口的含义以及应该如何去做）、重要的事项要通过邮件通知相关干系人，而不是仅仅通过口头表述、与协作者合作时要充分相信对方、跨地域的分布式团队该如何高质量通力合作（合作未必是每天面对面才能保证高质量，其实对于很多开发者来说，在理解了需求后更多时候需要安静地开发、测试，而不是周而复始地不停讨论，有相当多的时候讨论越多效率越低下）、节奏感的保持等等；又一方面，这场面试也是极其耗费脑力与体力的一次活动，印记难以磨灭。

由于当时在上海上学，因此北京这边的公司我基本没有投简历，可能就投递了理光这一家公司。一天下午，理光公司的人给我打电话通知我来北京面试，我想了想觉得太远了就说不去了。他们说给报销路费，由于当时的女朋友（现在的老婆）在天津上学，我想正好借着这个机会来天津看看她，就接受了面试邀请。面试定的是某一天（具体哪天忘记了）下午2点开始，我是前一晚乘坐上海到天津的火车（上海到北京的车没票了，那时也没有高铁、城际），早上7点多到的天津，然后又转车到了北京。到北京快上午10点了，下车后又坐13号线去清华（我的一个高中同学当时在清华读研）我同学的宿舍休息了一下。下午1点钟打车来到了理光公司。

首先进行的是笔试，拿到试题的时候我当时差点晕过去。笔试时间为4小时，光试题纸就好几十页，涉及到数据结构、网络、数据库、Java、C++、甚至还有一套完整的托业试题。长这么大，从来没有经历过这么长时间的考试。经历了近4小时的笔试后，开始了1小时的面试，面试更是把我震了。因为当时毕业找工作的面试有些公司是群面，所谓群面就是一两个面试官同时面试好几个学生，进而比较这些学生的水平和临场应变能力。理光也是群面，不过是8个面试官面试我一个人，此前从未经历过。面试全过程是英语表述，我首先准备了一个PPT（之前公司通知我准备好的），讲了大约20分钟，然后半个多小时的时间是8个面试官轮流问我问题，当然是英文来提问的，内容涉及到技术、人文、对一些问题的看法等等，这个过程我感觉所问的问题都不是太深入，我想还是主要考察候选者的英文表述能力和临场应变能力吧。经过了近5个小时的笔试和面试后，最后的结果还是不错的，我也就加入了理光。

在后续的工作经历中，同样经历了一些面试，当然也作为面试官面试过别人，感触还是比较深的。在被面的经历中，既有轻松搞定所有问题的时候，也有被鄙视的时候，我认为这都是非常正常的。作为面试官面试候选者也经历了形形色色的人，也有了自己的一些感受和想法，下面分别展开论述。

工作这些年间，有的工作是朋友推荐的，所以也就没有经过面试，直接就入职了，也有经历了完整的面试流程加入公司的。第一种情况就不说了，主要谈谈第二种经历，特别是将我亲身经历过的一些比较好玩的事情与大家做个分享。

当年面试某B公司，一个小伙来面的我，简单的寒暄后开始聊技术问题。他提出了一个问题后，我想了想说这个问题我觉得应该这样、这样问效果会更好:-)。他也想了想，说你说的对，改成这种方式来问效果确实更好一些。面试某J公司，两个小伙子来面的我，聊了10分钟左右时间，他俩说我觉得我们面不了你，我得叫我们经理过来，经理过来跟我聊了一小会说，我觉得得叫我们的架构师再跟你聊:-)。面试某L公司，填完表格后给了我一套试题让我做，我大致看了一下，说我觉得我不需要再笔试了，如果可以的话希望直接面试，要不我就走了。后来直接进行的面试，面完后面试官问我要QQ号码，我当时觉得挺奇怪，面试还要对方的QQ号码？出来后QQ收到一条消息，是面我的人发过来的，他说他们公司的情况不太适合我，他们公司技术这块还不是特别强，希望我别考虑他们了。面试某D公司，前台说面试的人在开会，让我等一会，结果我等了30分钟还不见人来，我说你们对待面试者太不尊重了，于是直接走了。面试某R公司，上来就问我MyBatis某标签中某属性的含义是什么，我哪里知道是什么，知道我也不告诉你。

当然，面试有成功的也就有失败的，也有几次面试回答的并不太好，自然也就没有下文了。

我认为，面试无论是成功还是失败，都是挺正常的事儿。成功了说明你的技术栈比较符合对方的技术要求；失败了说明你的技术能力还没有达到人家的要求，持续改进自己即可，切忌耿耿于怀，于人于己都没有好处。

下面我重点说说我作为面试官面试候选人时的一些基本做法和方式，一家之言。

首先，面试是双方对等的一次沟通过程。在这个过程中，无论是面试者还是被面试者都没有谁高谁低的问题，只是立场与身份不同而已罢了。那些不尊重面试者，特别是在面试对方时炫耀自身技术的行为是可耻的。

其次，面试是一次极好的沟通过程。我在面试时特别希望能够引导对方去思考，如果对方一下子没有想出来，我也会给足够多的时间并给予一些提示，主要就是看对方是否善于思考，而不是靠死记硬背的一些知识来蒙混过关。当然，现在有些简历写的也是天花乱坠，结果一问啥都不知道，这种情况我确实也遇到过不少。面试最重要的是能在较短的时间内（一般是30分钟）比较清晰地了解对方的技术水准以及候选人的性格是否适合自己的团队。对于有潜力但囿于过往的一些工作经历没有将潜力充分发挥出来的候选人，我也是比较偏爱的。面试双方应该是彼此尊重的，在平等的氛围下就像聊天一样聊技术，这样可以最大限度发挥出对方的潜力。

再次，还是平等这个问题。面试是一次双向选择的过程，即候选人选择公司并且公司选择候选人的过程。在这个过程中，真实性就显得特别重要。无论是候选人还是面试官都应该在这个过程中将真实的一面呈现给对方。比如，每次面试尾声，我都会问对方对公司与团队有哪些比较感兴趣想要了解的。在这个阶段，有些人就说没有了，我觉得这并不是一个好的做法，对于可能加入的团队如果没有任何想要了解的，会让我产生一些疑虑。大部分候选人都会问公司的业务发展方向、技术团队的人数、技术团队所用的技术栈是什么，未来可能还会使用哪些技术，对于这些问题，我都会如实回答。我认为，这是一个加深双方了解的好时机。

最后，关于面试的提问，我有一些自己的原则。

我一般的开场白都是希望对方针对过往的项目经历找出自己觉得比较有代表性的一个项目，然后针对项目的业务逻辑展开2分钟左右的介绍，在项目过程中遇到了哪些印象深刻的问题，是如何解决的，如果没有解决又是采取了何种规避手段。因为，让候选者根据自己过往经历展开讨论是比较容易消除对方的紧张情绪（不可否认，还是有相当一部分候选人在面试时会感到或多或少的紧张感），这样比较有利于接下来的问题讨论。

接下来，我会针对对方熟悉的技术展开讨论，对于一些比较有经验的开发者来说，我比较偏爱问一些基础的问题。因为我觉得基础好了，再去学习其他“新技术”都会是比较容易的事情。比如说在问到Spring相关问题时，我可能会问AOP在Spring中是如何实现的，对于IoC来说，单例的Bean Spring是如何缓存的，如果他回答了ConcurrentHashMap，那么我就会接着问ConcurrentHashMap如何确保并发不出问题的，它与传统的HashMap有何区别。如果碰巧对方使用过Struts2与Spring MVC，那么我可能会问Struts2的Action与Spring MVC的Controller分别是单例还是多实例的，为什么要这样设计？如果对方做过IM相关的开发，那么我可能会问如何确保消息的到达，系统角度的重复发送与业务角度的去重是如何实现的？Java并发相关的一些基础问题，以及JVM相关的一些基础问题，包括内存模型、volatile关键字、final关键字等一些基本问题；一些分布式相关的问题，MQ、缓存等等；对于前端我可能更偏向于问一些基础问题，而不是React、Angular等库或框架的细节问题，比如说ES6的掌握情况如何？对于JavaScript函数式编程的掌握程度、Node相关的一些问题等等。总之，都是一些比较基础但我觉得又能考察出对方是否花了时间去学习的问题。

当然，面试结束后，你可能觉得候选人不错，但人家没有选择你的团队，反之亦然。这都是再正常不过的事情，因为这本身就是一个平等的过程。

下面我想谈谈关于面试中的笔试问题。有些公司或团队喜好先进行笔试，然后再面试；有些公司或团队则直接就进行面试。这两种方式谈不上哪个好、哪个不好，本身就是做一件事情的两种手段而已。我个人比较偏向于直接面试而省去笔试环节，因为我自己就不太喜欢笔试:-)。

对于面试中问算法相关问题，我个人觉得如果在平时用的算法不多，那么无需在面试或笔试中重点考察这一部分，当然不是说算法不重要，只是要想在面试与笔试极短的时间内（同时还有一定的紧张感）想要完整写好一个算法并不是一件容易的事情。

之前，HomeBrew作者Max Howell在面试Google时因为无法写出翻转二叉树问题而被Google拒绝在Twitter等社交平台上引发了讨论的浪潮（据说后来去了Apple），尽管Google有大量工程师在使用Max Howell的软件。针对这一事件，RoR作者等一些大佬也发起了抵制“白板编程面试”的活动，支持者踊跃啊！当然，这是人家的事，可能与我们距离遥远，大家不妨搜索相关的帖子了解详情。

写了这么多，其实我想总结的有几点：

重视基础。无论是面试还是平时的工作，都不应该忽视基础的重要性，好的基础会让你走的更远，且更好。
没有多少“新技术”是所谓的全新技术，都是构建在已知的一些理论与实践基础之上的。比较深入了解底层的一些知识会让你更好地使用各种软件与工具。
在平日的项目与业务开发中，切忌不能将完成工作最为最终目标，它应该只是一个基本目标，否则连任务都完成不了，要你何用？在这个基础上，多思考、多想想还有哪些地方需要改进。
读书。我感觉程序员群里应该是一个比较爱看书的群体了。但还是有不少开发者一年连几本书都看不上，堪忧！
英文。好处不多说了。
复盘。经过一段时间，回顾一下自己在这一段时间的成长与收获及不足都有哪些，该完善完善、该改进改进，该保持保持。
节奏感。不要一下子用力过猛，保持稳健的节奏感会让你生活与工作都能在正轨上前行。
没了。