程序员借助5道算法题轻松入职Leetcode

前言

开场先来标题党一下，和 Scott 聊天的时候正好说到我入职的经历，然后就有了这次分享，当时我随口报了一个，刷了 5 道题，不过后来我仔细的数了一下发现是 4 道题。

不过问题不大，这次半个小时的分享会从「招聘要求」、「怎么刷题」、「大小公司的区别」以及「*做业务和基础设施的区别」四个点进行分析。

那我们现在开始，首先先来一段自我介绍，网名敖天羽，目前是全干工程师，参与主站业务开发，Title 是后端，之前在饿了么做一些基础设施的开发工作，目前在工作中会用到 JavaScript（其实是 TypeScript）、Python 和一点点 Golang。博客基本上就是一些笔记，什么都有。

接下来是一段植入式硬广，在介绍自己之后，还得把公司推销出去，官方给了我 123 字的版本，我估摸着我也不是播音主持专业的。

所以总结了一下就是：我们是一个在线编程的平台，同时提供了算法竞赛和交流社区，提供了模拟面试场景，目前可能是找工作刷题的代名词，但是希望未来能够成为技术成长的代名词。当然偷偷告诉你们，我们还提供了企业服务，毕竟你们老从我们这里拉题多麻烦，直接用我们的企业平台就好啦。

招聘要求

自我介绍和植入式广告完了之后，开始我们第一个话题，从招聘要求开始，来看看在面试之前我们需不需要做一些额外的准备，顺便还可以通过 JD 了解一下公司的技术栈是什么。

比如全栈工程师，招聘涉及到了前端，后端以及一些基本功、开发思想上的内容，从技术上，我们大概能看到 Django / React / Redux / GraphQL / Redis / MongoDB / MySQL 等等，实际上这也是我们公司都在用的技术。

当然实际上我们公司在职位的最前面都会标明公司的技术栈，只是因为字太多截不下图所以没有截。那我们来看一下前端的要求。

前端这里字就比较少了，可以看到在上面就标明了技术栈，这是我们未来公司会用到的技术。当然对于大公司而言，有可能你不会用到上面所有技术栈，而且基本要求是技术栈的一种泛化，通常会默认一些主流技术的运用，但不一定是公司会用到的。

特别一提的是前端通常都会在加分项里写明，熟练使用一门后端语言。如果要应聘我们公司的话，做出了我们在 GitHub 上的面试题是特别的加分项。

看了半天，我们发现大家的招聘要求都是一坨一坨的字，是不是有一种面试造火箭，入职拧螺丝的感觉 —— 所以，招聘条件真的需要全部满足吗？答案肯定是：不是。

之前我说了一些主流技术，但这不代表你必须要全会的意思。尤其是我一直都在思考，怎么样才算熟悉，怎么样才算精通，又怎么样算理解呢？—— 最终琢磨了半天，我觉得撑死胆大的，投了再说。

怎么刷题

面试前的准备

研究完招聘条件，我们来看看面试前要准备哪些东西，当然这里只是简单的过一下，毕竟大家都懂的，这里说的是我的一个个人经历，并不代表普遍情况。

第一个就是要准备跳槽，其实相比投完简历面试，准备跳槽阶段可能才是一个最漫长的过程，大家虽然可能会待在一家公司，比如相处腻了，世界这么大我想去看看，又或者特别不爽想跑路，但除了少部分特别有勇气的裸辞以外，剩下的人都会先默默的憋着，先去准备准备。

这里我分享一下我在这次跳槽的准备跳槽阶段做了哪些事情 —— 我每天躺在床上想着，明天我一定开始努力的复习，明天一定开始每天一道算法题，总之，我明天一定努力。

然后不知不觉的就到了面试的前一天，我都忘了我是怎么在毫无防备的条件下投的简历，大概是被内推我的同学忽悠的。

不知道大家会不会有一种面试前一天很紧张的感觉，尤其是你要去裸考的时候，当时我内心悔不及当初，为什么不好好学习，像极了那种高考出榜才后悔的感觉。

当时我内心就是，卧槽明天就要去面试了，我是谁，我在哪里，我要做什么。不过还是要临时抱佛脚的，大概佛脚也分为三步走：

首先是自我介绍，就跟我前面做的自我介绍差不多，大概要讲清楚自己是谁，做了那些事情，因为简历的东西可能很多，面试官看到的和你想让面试官看到的重点可能不太一样，自我介绍可以做到一个圈划重点的作用。当然我觉得大多数大早上起来的人可能都挺困的，应该是来听我讲相声的，所以我没有做太多的圈画重点，大家吃吃早饭听我唠嗑就行了。

第二是基本功，大家在面试的时候八成都会被问到，双向绑定的实现，Vue 或者 React 的生命周期，或者是 Promise / debounce 这种，在 GitHub 上都会有一些面试类型的 Markdown repo，可以稍微看一下，我平时也有 star 了好几个。
然后我打开来一看，哇…… 真的太多了，算了一晚上肯定看不完。战略性放弃，靠命面试吧。

重点来了，算法题，如果说前面一个业务上的基本功可以靠嘴炮和口胡的话，算法题这种基本上都要你当场写代码，这就完全是硬核测试了，是驴子是马一试便知，因此算法最好还是需要安排一下的。

算法到哪里刷，大家都懂的。力扣（LeetCode）启动。

这已经是最后一天了，没得办法，明天就要去面试了，既然如此，只能尽可能少刷几道让效率最大化了。所以时间管理就很重要了，当然我说的是正经的时间管理。

所以，刷题的策略很重要，怎么样刷最少的题，能复习到最多的知识点，不是为了特别的增强自己的算法素养，而是复习自己已经会的，但是可能忘记了的东西。

算法总结

我在这里列了一些常见的考点，分为了五种：

• 冒泡 / 快排 – 排序类算法
• LRU / 排列组合 – 应用类算法
• 链表 / 堆 / 栈 / 树 / 图 – 数据结构类算法
• 分治 / 动规 – 算法思想
• 深度优先 / 广度优先

我在这里列了一些常见的考点，分为了五种。这五种基本上可以被称作算法中的基本功，而这些考题的优点在于，出一道包装好的应用场景的题，就算不用这种方法解决，用爆破可能也可以解决，但是懂的算法的人可以做出更好的解决方案，就产生了不同面试者之间的区分度。

总结的差不多，接下来开始在力扣找题目吧。这也就是我们标题上说的五道题了。重点是，找到一道题目，可以尽可能的用多种不同层次的写法去解决一个问题。

图算法

200. 岛屿数量，大家看一眼题目，这题目一看就是一个图算法。

数据结构题

622. 设计循环队列，实际上还会有一些翻转二叉树，链表之类的普通数据结构题，这里只是随便抽一道，大致实现一下找个感觉，这种题基本上熟悉数据结构的特点就不会有什么问题，只是编码行数会比其他算法题要多。

经典排序算法

其实我相信大部分初级岗位都会选择考冒泡，比如说我找实习生工作的时候就被考过冒泡排序，还有可能是写个快排（（）），这里只要随便找到一个需要排序的题，不用库中自带的 sort，而自己实现一个排序算法**就可以了，当时我并没有刷这一部分的题。

分治 / 动规题

这个在前端面试中其实也并不一定会被考到，只是分治法作为一个重要的算法思想，掌握不亏，这里选了一道简单题：53. 最大子序和。

数学题

最终还有可能被考到的是排列组合题，这里选了一道 39. 组合总和，这个也有可能会在面试中被考到。

刷完了五道题，用各种方法做完确认了一下自己想复习的点，接下来就可以洗洗睡了，毕竟充足的睡眠是成功的第一步。

面试中

然后就要开始面试了。这里流程其实差不多，无非也就是上面说的三要素：自我介绍、基本功、算法题加上聊项目。

其中自我介绍和聊项目都可以随便说，基本功和算法题就靠积累 运气了，俗话说得好，运气也是实力的一部分，运气好才是真的好。在力扣面试中，我本来以为算法一般会选择 Medium 难度，结果他们告诉我就给我考了 Medium，前端都不考算法，后端就考数据结构，可把我气坏了。

当然如果被刷了也不必沮丧，因为很有可能只是因为觉得大材小用，你来我们公司太浪费了，或者是完美避开了你会的题，毕竟大家从小到大经历过大大小小的考试，总会遇到一次你背的答案统统变成了题干的情况。

大小公司的区别

这里大家可能有个错觉，以为我们是跨国大企业，实际上我们的团队规模还是很小的，套用某人的话就是因为我们中国团队刚建立两年多一点，虽然在不断扩大团队规模但还是要保持精简……

总之，在刚入职的时候，确实有很多水土不服，因此我顺手总结了一些大小公司的区别，提供给大家参考一下。

• 首先就是基础设施，如果你在阿里、腾讯或者其他公司工作过，你就会知道，上到组件库，下到底层编译、发布等等，都有一套完整的内部生态等着你去用；而在小公司，可能会存在一些缺失，或者会选用一些开源的技术。
• 第二是历史包袱，我们可以每周升级我们的依赖，保持使用的技术都是最新的；但是如果是大型公司的主营业务，可能你只能一边使用老技术，一边在新页面运用新技术，有种迷之割裂感；实际上大公司面临的历史包袱是沉重的，甚至有可能不止是技术问题，而涉及到一些更深层次的问题，这里就不能多说了。
• 当然，在开发的重心上，也有一定的区别，在大公司，你可能是在某一个模块上转，而在小公司，你可能需要 handle 住的是整个业务，毕竟人手还是有一点差别的。当然，有一点相同，就是大家都对 ROI，也就是投入产出比非常的关注。
• 相信大家工作之后碰到最头疼的一个问题就是报销，尤其是在大公司，报销可能会分六七步，如果其中有一个审批不通过，结果就喜闻乐见了，但是在小公司，流程就非常直接了，甚至不懂就问，也能直接得到反馈。

当然还有一些关于我们公司的额外福利，比如说免费的下午茶和零食，所以导致我现在胖了很多（XD）。

做业务和基础设施的区别

再说说做业务和基础设施的区别，在我刚入职的时候，完全没有写过业务，这确实也让我尴尬了好一阵子。

服务对象

首先来说说服务对象，对于基础设施来说，服务对象是大部分的内部用户，而对于业务来说，服务的是你业务面向的人群。如果我把基础设施搞挂了，当然不是完整宕机的那种，可能只需要一个公告就能结束了，但是如果你在业务上写出任何一个小问题，都有可能收到用户的投诉。

需求来源

第二是需求来源，对于基础设施而言，需求实际上来自于业务、基础设施的使用方，也就是说，过去我基本没见过产品经理、需求文档，而写业务的时候就会遇到和产品经理对撕的情况，也不是自己想加什么功能就加什么功能了。
当然，基础设施也不代表高大上，业务也不代表 CRUD 和切图仔。

总结

结束了，到了要说再见的时候了，我来用八个字总结一下这次的话题：仅供参考，请勿模仿。

大家可以看到，实际上我并没有做多大的准备，如果我想要去面试的是 Google / 微软的话，这些准备肯定是不够的，至于正经的准备，相信接下来的讲师应该会带给大家满意的答案，但是我相信大家听完差不多也该吃完早饭刷好牙，醒的差不多了。