01
相信很多同学最讨厌的就是考算法题了，其实我也很讨厌，大厂的算法题也是找工作时被吐槽最多的话题。毕竟，在实际工作中，我们根本不可能从底层实现一遍经典算法。
但是，算法却是大厂面试考察的重点。甚至有一些大厂只考算法。
印象在我小初中的时代，微软公司的面试题目往往被我当做“科幻小说”来阅读，画风如下：
为什么镜子中的景象是左右相反的，而不是上下颠倒的？
如何井盖为什么是圆的？
如何把一座山从一个地方搬运到另一个地方？
5个海盗分100个金币。他们定了一个规则：从A开始给出分金币的提议，然后其余的海盗投赞同或反对票，如果反对票数大于或等于赞同票数，A就被丢进海里，否则就按此提议分金币；如果A被丢进海里了，接着就轮到B提议，然后同样按上述规则继续下去。假设每一个海盗都是绝顶聪明的，而且他们的所有行为都是对自己最有利的。请问这100个金币是怎么分的？
总体而言，这些问题和算法的关系不大，说他们是“智力题”或许更合适。因为当时计算机行业尚属新兴行业，每天都会面对很多全新的问题，处理这些问题的方式也没有一定之规。可能是在这种情况下，微软希望选拔出最具有创造性的人才，可以灵活，创新地处理工作中遇到的各种问题。
随着时间的推移，计算机行业逐渐成熟，程序员也在呈指数级上涨。虽然创造力依然很有意义，但并不再是唯一的选拔人才的指标了。一个逻辑思维强，基本功扎实的人，也能够非常好地胜任程序员的角色。
至此，互联网大厂的面试进入了第二阶段，以算法问题为主。
实际上这并不是件坏事，因为这样以后，普通人通过训练学习也可以进入大厂，意味着计算机行业门槛降低。一个行业门槛的降低，意味着这个行业可以成规模的扩张，呈现出欣欣向荣的景象。
02
一个公认的人才选拔模型，由三部分组成：
通用问题思考能力；
专业能力；
人品，三观。
抛开第2、3条不谈，通用问题思考能力就是把专业能力拿去，看一个人遇到一个非专业的问题，水平如何。
这是一个很大的范畴，想象力，创造力，记忆力等等，都能被包括进去。上面的“智力题”很大程度上是在考察通用问题思考能力。
不幸的是，当下大部分互联网企业比较认可的结论是：算法面试可以很好地同时顾及“通用问题思考能力”和“专业能力”的考察。
说算法问题可以很好地考察【专业能力】很好理解。怎么算法就能很好地考察【通用问题思考能力】了？
因为，解决算法问题是一个典型的“学以致用”的过程。对于计算机专业的同学来说，近乎大学前两年，就已经将基本的算法和数据结构学习完了。数据结构大体就那么多，经典算法大体就那么多。但是，面试者能否综合这些知识，解决一个一个算法问题？大家都懂这其实并没有那么简单。
我们在工作里也会经常面对类似的情况，各类语言就摆在那里，各种 API 文档上写得一清二楚，各种开发工具都唾手可得，github 上各类开源项目应有尽有。我们能否合理组合这一切，完成我们想要的功能？
解决算法问题，近乎就是这个解决问题模型的小小缩影。
03
当然，还有一类面试问题，可以更好地模拟这种“真实的问题”，那就是系统设计类问题。比如：
如何设计一个淘宝？
如何设计一个百度搜索？
如何设计一个抖音短视频？
如何设计一个微信？
如何设计一个消息投递服务？
如何设计一个通知系统？
但如果仅仅考察系统设计问题，最大的缺点是容易流于表象。
比如，面对性能问题，我们可以使用缓存机制。但是，具体在实现一个缓存机制的过程中，可能会出现什么问题，仅仅靠说肯定是不够的。
面试的时间是宝贵的，所以面试官不可能让每一位同学都真正实现一个完整的缓存机制。因此，对于系统设计问题的考察，通常很难触及到代码层面。
对于程序员来说，正确地实现代码，比知道几个诸如缓存这样的名词重要多了。很多人说起这样的概念头头是道，但真的写起代码来，就原形毕露了。
算法面试相较而言，虽然问题规模会更小，问题本身也更有局限性，但能考察出程序员真刀真枪写代码的能力。
04
就算是算法问题，相信大家也都有体会。对于一个问题，描述它的解决思路是容易的，但真要落实到代码，就不那么容易了。
对于一个具体的工程设计问题，没有受过专业训练的人很容易忽略复杂的细节，将问题想简单。盖一个房子不过是建四面墙，上面加个屋顶而已，这里面包含了诸多复杂的工程问题。所以外行看来很简单的问题，实际上是很复杂的。
比如：
排行榜不就是排个序吗？
但能否达到性能标准？
搜索引擎不就是把互联网上相关的信息展现出来吗？
但是怎么定义“相关信息”？
微信支付不就是扫码然后付款吗？
但是怎么避免网络波动带来的支付失败问题？
Kruskal 最小生成树算法，思想非常简单：对所有边排序，之后从小到大选边，只要和已有的边没有形成环，就选择，否则抛弃。
落实到具体代码中，怎么判断“是否和已有的边形成环”？
在历史上，Kruskal 算法的思想很早就出现了，直到人们意识到可以用并查集进行环检测之后，它才成为了一个实用的算法。
所以，程序员的核心价值，是具体用代码实现出功能，而不是侃侃而谈思想或者概念。
05
当然如果遇到真才实学的面试官，面试者随便吹几个概念，其实也不可能蒙混过关。有经验的面试官一定能深入问出面试者的水平。但这对面试官的要求太高了。
高水平的程序员，他的主要时间应该用来完成工作，而不是去面试。
这样一来，算法面试的另一个优势自然而然就出来了：面试官好准备。
对于系统设计问题来说，面试官的水平要远远高于面试者才能真实地鉴别出面试者的能力。算法就不一样了，即使面试官的算法水平低于面试者，也可以进行考核。因为面试官可以直接看答案，理解清楚解题思路和代码就行。
正因为如此才会出现：
一个算法面试官问你一个算法问题，你没做出来问题不大，这并不代表他比你强。因为你们处于信息不对等的位置。
06
当然算法面试还有更多优点。
和语言无关：不管是编译型语言，还是解释型语言；不管是前端还是后端语言，都能用来解决算法问题；
对硬件条件要求低：并不需要非常特定的环境或者配置；在公司的会议室可以完成，走在路上能完成，面对面可以完成，远程也可以完成。拿张纸都可以开始；
使用算法问题，可以很容易地比较面试者的水平差异。其他领域的问题，很难像算法问题一样，在不同难度级别上，产生这么多看似完全不重复的问题。不管是深度还是广度，不管是简单的还是难的，总会有合适的算法问题让面试官选择，以测试出你的水平上限；
正因为算法问题的选择很多，所以使用算法面试，非常容易成规模地进行招聘。在一段时间里进行几百场面试，题目不会重样。这样，避免了泄题的问题。
但是算法题最大的缺点，就是容易漏过人才。不擅长算法的人不意味着不胜任计算机专业的工作。
那大厂错过了人才怎么办？
他们可能并不在乎
反正有简历源源不断地涌进来，他们只要招聘到足够数量满足自己需要的人就可以了。
通常来讲，擅长算法的人，近乎都能够很好地胜任软件工程师的工作。反之，不擅长算法的人，虽然有可能是人才，但更加可能不是人才。
07
很多小公司面试不考算法的原因，是因为他们不需要考察通用问题解决能力。小公司更注重专业能力的考察。能干活最重要。他们并不会接触到那么多创造性的问题。
招聘领域专家时虽然也有算法，但难度明显降档，最典型的就是 Google 在面试 Homebrew 的作者 Max Howell 的时候，给出的算法面试题“翻转二叉树”。这个问题在 Leetcode 上就是一个 easy ，然而他并没有写出来
08
所以就要揭晓我们究竟要怎么样才能不考算法就进入大厂，当然就是成为领域专家。让企业不能把你当做是一个普通的求职者。
之前有一个清华一个学霸，在自己写的CPU上运行自己写的操作系统，这样的人才，大厂这不分分钟给抢了，谁还在乎你算法题写得好不好啊。
不过话又说回来了，成为领域专家还是比掌握那些基本的算法面试问题要难的。但很多时候我们对现实不满，苦苦追求其他捷径。
再但是，其他的路其实是更艰苦的路。而我们总容易忽略摆在眼前的，其实已经是捷径了。
（不说了，我去练习算法了）
