今天正好看到两个技术面试相关的分享。结合自己这十年来的面试或者被面试经历，谈谈自己的想法。
难得的面试分享
首先我们来看看 ReactJs 核心开发 Dan Abramov 的面试视频。这不算是正式的面试，是一个 Youtube 主播和 Dan 进行的模拟面试。Coding Interview with Dan Abramov - YouTube
这个面试将近持续了一个小时，但是主要是后面的那个算法题耗费时间，前面几个问题都是很八股的前端面试题：
- let 和 const 区别
- 什么时候使用 redux
- dangerouslySetInnerHTML 是什么，该怎么用
- 把一个 div 居中
- 把一个 binaryTree 镜像翻转
- Bonus Q: 一个找兔子的算法题，兔子出现在数组的某个位置，但是每次可以跳向相邻的位置，用最快的办法找到兔子的位置。
这里面有意思的点是：
Ben: There is a library called ‘redux’
Dan: “Hmmmm heard about it”
Redux 最初版本是 Dan 2015 年发布的…….. 面试官小哥羞涩地笑了 🤣
然后，把 div 居中算是前端中的经典梗了，Dan 花了好一会时间在面试官的提示下才把一个 div 居中。如果对方不是 React 核心开发，手熟的前端可能就会开始鄙视这位“初级前端”了。这让我这种一直觉得 css 很难的前端学习者觉得信心大增。
反转二叉树问题 Dan 很快就答出来了，但是从面试过程中可以看到他对怎么尽量少代码 swap 两个变量还想了一会儿。我后来看他的十年总结的博文中，职业生涯初期的一次面试也提到了这个点：
At one point I freaked out and panicked because I couldn’t write three lines of code that swap two items in an array. I asked Jing to look away for a few seconds. She said “I know you can swap two items”, and that gave me the confidence to finish the answer and make it through the interview. I probably didn’t pass with flying colors, but I got the offer.
最后一个算法题比较新颖，这不算红黑树式的八股算法题，倒像是一个 IQ 测试题目。可以看出 dan 也很少碰这类算法题。他花费了近半个小时在面试官的提示下，按照自己的直觉一步一步推出了答案。但是他最后写的代码是有点小问题的 (没有用 2 来递增 index)，面试者看他思路是对的也没有指出来了。这里可以看到，其实结果可能并不重要，而是在解决这问题中所展现出来的思维方式方法很重要。
除去 Bonus Question，可以说这轮面试的题目大多比较常规，难度小于很多国内外大厂的面试。Dan 作为前端大咖，愿意参加这样的直播分享很难得。我感觉看到的是一个真实的工程师，在未做过八股训练下的真实表现。
这是今晚看到的另外一个面试分享， 经历了人生体验最棒的一次面试 · Issue #228 · yihong0618/gitblog (github.com)：
我觉得比较难得的是第一面面试官的面试方式，选择一个面试者的开源项目，然后提一个小需求让他实现。这得很花面试官的心思和时间，也确实能很好地考察应聘者的编程能力和工程能力。国内这种认真面试的公司太少太少，而且一线大厂几乎不可能出现这种面试方式。
我的一些经历
在我十年的职业生涯中，经历过多次技术面试，作为应聘者被面试或者面试他人。
我经历过的最差的面试体验是在 2014 年。面试官没怎么看我的简历，首先让我挑两个主题，然后我能看到他在屏幕前点了点鼠标，从题库中挑选了几个题甩给我。这种感觉就是高中时候的考试体验，我需要在纸上写程序和公式。面试官全程严肃无表情，即使我主动需求交流也无果。这次面试可以说是深深地伤害了我，并给了我很大的心理阴影，导致我后来面试就会忍不住祈祷千万别再碰到这类面试官。
一些小而美的技术公司倒是更尊重应聘者。前两年我参加过一个新加坡小外企的招聘。首先第一轮面试是双方自我介绍，对方会和我聊他们公司的主要业务和技术栈，以及目前这个岗位的工作内容和职责，确定我感兴趣之后才会约第一轮技术面试。第一轮面试就是一个小的项目，需求都写清楚，但其中也留了一下自由发挥的空间。我一周的时间来完成，然后把代码发过去。第二轮技术面试首先是从那个小项目聊，为什么这么写等等，然后会引出一些技术问题，但是会从深度和广度不断地追问下去。这就有些像是平时工作中，两个同事探讨问题的状态。
算法有什么用
面试的难点在于，很难在短时间内了解这个人的全部技能和特点。这些包括编程能力，工程能力，技术视野，沟通能力，应对挑战的能力等。
刘未鹏曾经在怎样花两年时间去面试一个人中提到，用 Github 和书单的方法来面试。这当然是一个不错的面试方法。而大公司采用比较标准的面试，主要是为了节省时间。因为应聘者多，面试的场次多，不可能让面试官在工作之余花大时间主动了解应聘者，通常情况是面试官在面试之前匆匆扫上一眼简历。而且八股文式的面试很容易让面试官得出结论，即使这个结论包含了不少偶然性因素。
面试造火箭，入职后拧螺丝是行业常态。这也说明，我们工作中极少极少去碰这些基础算法类的东西。工作久了，我能看到很多面试官拿出一个公司的面试题，在不看答案的情况下自己也做不出来。
算法又是很多程序员所惧怕和不擅长的部分。Programming Pearls(《编程珠玑》) 一书的作者 Jon Bentley 曾经说过：“90% 的程序员无法正确实现二分查找算法...”。2014 年我在广州参加一个技术聚会上，因为一个一时兴起的赌局验证过这点。当时我们那个会议室 20 多个程序员，其中有工作多年的，也有刚毕业没多久的，能在规定时间写出一个无 bug 的二分查找的确实寥寥无几。
那面试出这种题目有何意义？
算法当然对程序员很重要，特别是某些特定的领域，比如图形学、机器学习、高性能计算等等。另外如果一个程序员啃过算法这个硬骨头后，会觉得学其他都不算太难。在学习编程阶段，大量地实现数据结构和算法就是一种很好的提高编程能力的方法。我在学校最后一年刷了 POJ 500 道算法题，自我感觉编程能力大幅提高。
但我认为面试中的算法题可以当作一个下限标准，使用相对基础的、简单的编程题，会有助于筛选出编程能力不适合的应聘者。另外来自实际工作中的一些算法问题也是很好的面试题，比如上次我碰到的输入自动补全算法。这种问题没有唯一解，而且也很容易理解实现，通常有一定编程经验的程序员都可以实现出自己的版本。
对于绝大部分岗位来说，算法题测试不适合当作上限标准，因为专门训练过的应聘者和没训练过的差别太大。较难的、八股式的算法题对于初步筛选不太有用。一个应聘者如果能很快答这种题，可能是他刷 LeetCode 比较多，或者是刚好之前碰到过这个题。对于资深的应聘者，往往只能通过以往的项目来考察深度和广度。我认为深度比广度重要，因为如果一个人能把某个领域做得很深，如果他花时间换个领域很可能会做得好，反之则不然。
总而言之，很多大公司的面试看起来八股，也有一定道理。作为应聘者，专门针对这类面试做一些针对性训练结果就会好很多。
我认为好的技术面试有如下特点：
- 对应聘者尊重、真诚，面试是一种平等的沟通和交流
- 拒绝八股，更多考察实际解决问题的能力
