一点面试感想

最近参与了一些面试, 想到了一些问题, 简单记录下.

面试就是企业方尝试在短时间内考察候选人的能力, 这种模式下肯定不能做到绝对公平(确实也没有更好的方式). 因为这些事情都是通过人来完成的, 不同面试官对于不同候选人考察是不同的而且也不能完全相同. 所以很多时候都说运气也是很重要的. 当然面试失利 90% 以上的原因肯定是在自身的.

技能点问题 #

计算机技术一直都是高速发展的, 从一年一度的 developer roadmap 来看, 一个岗位包含的技术是非常多的. 但是每个人的经历都是有限的, 所以每个人感兴趣的方向是不一样的, 就像游戏里不同人点的技能树是不一样的.

因此, 在选择岗位上面肯定得选需要的技能和自己擅长的匹配度高的. 否则就会发现你擅长的对方压根不感冒, 也不会去考察, 这样相当于禁用了你的一些强力技能.

其次, 如果你和面试官技能重合度高, 你会发现聊起来会很顺利, 因为两个人对于问题的上下文是一致的, 思路就很容易互相理解. 例如面某潮流 app 公司, 面试开始才发现是云原生部门, 但是我对这方面比较了解, 因此没怎么准备都聊得很顺利.

关于算法 #

算法到底能不能反映出一个人的逻辑能力和编码能力这个问题一直有争论. 我的观点其实更倾向于 反映不出来.

现在算法基本成为了大厂考察的必备项目, 很多面试者在准备过程中都会大量 刷题, 从这两个字可以看出算法考核是被当做考试题目一样的东西, 刷题仿佛让人回到了上学时候, 也反映出了一个问题这些题目和实际场景距离太远. 因此很多人刷题其实是没有思考的甚至是背题解的, 面试结束就会扔掉, 真正工作写代码时甚至不会注意 O(N^2) 这种简单问题, 当然这里说的是部分人.

还有一个问题是, 我们平常人其实都是没能力重新 发明 出很多经典算法. 解答算法问题大多时候都是从脑子的题库中找原题或者相似的题目, 然后判断出使用哪种已经被归纳总结好的方法来处理题目.

久而久之就变成了, 面试官害怕问到候选人准备好的题目, 候选人害怕碰到没见过的题目, 所以就会出现经典的面试让写红黑树的例子.

当然通过我刷题经历, 发现算法确实对思维是有所帮助的, 例如 树 类型的题目确实锻炼了递归解决问题的能力, 而且某些算法设计得真的让人赞叹, 例如使用快速排序 partition 结合二分搜索解决第 k 大数组元素问题.

大小公司共情问题 #

面试基本都会问候选人过往解决的 实际问题, 但是实际问题这个定义对于大小公司的人可能是完全不一样的. 而且我也认为考察一个人在一个确定的场景下解决当下问题的能力比考察他在虚拟的场景下解决设定好的问题要更加真实, 因为后者更类似是在做题. 大多公司其实技术是没法决定业务规模的. 大公司的实际问题就是大流量问题, 而小公司则是相反. 大公司各司其职解决高并发问题, 小公司可能需要多种技能解决小流量问题. 但是知识广度也应该是能力的一种反映.

例如我说了一个参考 go-zero 缓存, 唯一索引缓存不存完整数据而是像 mysql 那样存主键 id, 这样同一条记录在 redis 中只会存储一份完整数据, 在仅使用一个唯一索引缓存时就能省下 50% 的空间. 结果面试官觉得 redis 内存不那么值钱. 其实这个问题抛开钱使用简单的代码优化掉 50% 以上的空间消耗不应该是件意义重大的事情吗? 算法基本不也是为了优化时间和空间么. go-zero 的作者我本人是非常尊敬的, 看他的代码真的学习了很多知识, 当初看到缓存设计这里其实是我真的很惊叹.

后面问我消息队列时, 我说当初用过 kafka, 后面为了省成本换成 redis 了, 因为消息队列场景对于数据完整性要求没那么高. 面试官还是觉得成本应该没差多少, 问了句为什么不把 redis 配置省下来的钱部署一下 kafka 呢? 这个问题对于小量级来说费用消耗会相差很多的, 而且我们的 redis 全局只有一个.

上一个问题其实也牵扯到了基础服务的问题, 业务有些场景其实会用到队列限流, 重试, 延迟执行这些场景, 但是小公司基本没有中间件团队, 所以我们选择了一个实现了这些功能的开源库, 它是基于 redis 的, 当然这一点我觉得没必要说了.

服务的限流熔断降级问题, 我们小规模其实是用不到的, 不过我对这些感兴趣, go-zero 框架的实现我都很熟悉了. 特别是他选择尽可能使用自适应的算法减少配置, 我都觉得是很好的实现, 因为它参数少下限高.

剩下的一些小公司提效的工具, 面试官不在意, 因为大厂应该会有部门做这些事情甚至会有多套工具, 我想说的是使用工具解决重复性问题其实是程序员很重要的能力之一, 这里又不得不提 go-zero 了. 但是大厂业务面试官可能会觉得这些东西和业务无关就会忽略掉.

剩下的我对于 k8s devops 还有 cloud native 的了解显然和业务更没有关系, 对方更不在意所以肯定更不会被问到.

对于这些所谓的 不匹配 的能力我觉得也是完全能够反映出一个人的能力和学习能力, 工作中不可能一直解决自己知识体系之内的问题. 我在做面试官的时候会将很大一部分比重放在考察候选人擅长的问题上面.

总结 #

我当然不是在抱怨, 以后面试大厂可能需要从这几点提高自身:

1. 尽量选择技能和需求匹配的岗位
2. 多刷题总归是好的
3. 多去学习一些经典场景架构问题, 甚至更套路的学习某些面试宝典
4. 持续学习, 持续积累, 学习还是不要那么功利性, 不要让面试占用我们太多学习时间, 这样就本末倒置了

当然也可以选择不卷进这个游戏, 但是 持续学习 应该是一个有追求的人的永恒特质.

最后抛一个问题给大家: 你在作为面试官考察候选人的时候, 最看重的是哪几个点呢?