我希望这才是35岁危机的真正原因。

这是why的第 84 篇原创文章

思想碰撞

前几天在某平台发布了《面试之后，扼腕叹息》这篇文章。

没看过的小伙伴可以先看一下原文，很短，2 分钟就能看完（顺便关注一下）。

可能是由于我表述的有问题，也可能是每个人看问题的角度不一样。引起了该平台广泛的讨论。

首先，给那些看了我的文章，留言批评我的朋友们说一声不好意思。

没想到开开心心逛个技术论坛，想学点有用的东西，结果还动了怒。

我写那篇文章的出发点仅仅是分享那次面试经历带给我的一点思考。

了解到面试者的经历之后，在我本人有限的经历和认知里面，让我觉得很惋惜，发生在他们身上的事情本可以不是这样的，仅此而已。

但是，同样的事情，由于每个人的经历和认知不同，就能发掘出截然不同的观察角度。

而这些截然不同的观察角度得出的结论，就很容易产生激烈的碰撞。

在这场碰撞里面，没有人绝对的错了，也没有人绝对的正确。

所以，马斯克，这个观察问题的角度是星辰大海的男人，说的这句话，我觉得的很有用：

必须要再次说明的是，每个人看问题的角度不一样，所以看这句话的感受也不一样。

也许你能解读出一丝丝“阴阳怪气”。

但是，相信我，我放在这里，绝无此意。

在那篇文章里面我说：很多技术问题回答时浮于表面，甚至简历上写的技术点都答不上来。

然后，我举了一个例子：

必须要先说明的是，我这只是举的面试中的一个小例子，并不是因为这个小问题没有回答上来就否定了他。

只是他从那次面试整体展示出来的技术能力，岗位不匹配不高而已，或许有更适合他的岗位

首先，我为什么会问分布式锁呢？

因为他简历上写了“分布式相关技术”，而且我们的项目真的是在用分布式锁。

然后他只回答了一个几个字：可以用 Redis 来做。

他这个回答，从我的角度看来，是觉得不好的。

给我一种戛然而止的感觉，因为他没有说用 Redis 到底怎么做。

我怕他是知道具体的实现方式，但是属于那种问一句回答一句的人，所以我才追问了一句：能不能稍微具体一点。

他没有回答上来，所以在这个问题上，我也就不再继续聊下去了。

因为我知道了关于这个点他的技术深度，我理解，就限于知道分布式锁这个概念而已。

也许看过几篇相关的文章，但是对于其中的一些细节忘记了。

一个有五年工作经验、具有分布式项目实战的程序猿，说不清楚 Redis 分布式锁。

从我的认知里面，我觉得这个地方有点“浮于表面”。

但是在该平台的文章下面，有几个人觉得这个回答还行，至少说明他知道有这个技术。

于是我开始思考。

也许其他人的认知里面是这样的：我知道 Redis 可以做分布式锁，如果真正要用的时候，我可以很快的把这块知识拾起来。

你能说这个观点是错误的吗？

这没有错呀。

甚至我之前的文章中也出现过类似的观点：

但是，为什么当这个观点，具象到“你只知道 Redis 可以做分布式锁，但是不知道具体怎么做”的时候，我就觉得不行了呢？

我想了想。

也许只是我主观的认为：工作了 5 年，你应该清楚的知道这个知识点。

而且，这是在面试。

我必须从你的简历出发，看看上面写的技能点你掌握程度到底如何。

整个面试的过程中，我都是基于面试者的简历提出问题，而且已经尽力把主动权交给面试者了，但是他真的没有好好把握。

其实，只要能好好把握这个主动权，把自己尽量多的展现出来，让我知道你是具备我们岗位所需的技术且人是热情大方的就好了。

现在很多人面试之前都喜欢看一些面试技巧相关的东西。

这没有问题，我自己也看。

但是面试技巧只是锦上添花，你的真实实力才是锦上添花的对象。

在绝对的实力面前，任何的锦上添花都会显得苍白无力。

好了，再回到平台发布的那篇文章下的评论。

那些我觉得不太好的评论，就不讨论了。

观察角度差异过大，短时间内很难对齐。

所以，发展到后面很容易变成口舌之战，意义不大。

主要说一下我看了之后觉得值得思考的评论。

值得思考的评论

首先申明一下，下面的观点全是基于我目前仅五年的工作经验得出的看法。

也许，当我再过五年、十年之后再看会得出截然不同的看法。

甚至几年后的我，对此时此刻的我表达的看法嗤之以鼻、并报以尴尬且不失礼貌的微笑。

但是，没关系，先记录一下，几年后再回来打自己脸的事情在我身上发生过太多次了。

评论一：

换成他问你，照样可以挖掘出只流于表面的技术点

我觉得这个是肯定的。

闻道有先后，术业有专攻。技术是无穷无尽，学不完的。

但是，我能做到的是，写在简历上的技术点，如果面试官问起来，总是应该有几个可以交锋的地方。

至少，在实际生产工作的过程中需要用到的技术点，比如某个框架。

首先应该做到知道怎么用，此时它对我来说是一个黑盒。

然后应该知道它为什么能用，也就是去学习的它的内部原理，从而可以更好的使用的它。此时它对我来说就是一个脉络清晰的框架，达到了知识点的深度。

最后应该知道为什么用它而不用其它的框架，也就是触类旁通，做对比学习，扩展知识面的宽度。

评论二：

但现在的面试就是这样，用不用的到的，都要问一遍，问完之后还会深挖，大公司问的更深

我上个月裸辞后，就开始准备面试，准备了一周才开始刷简历，之后就是一个个的面试 从准备面试，到后续面试中，都一直在学习，看面经，做一些对应知识的储备。

下班后，晚上回家学到12点。周末不出门、元旦不出门，学习。

如果你要想换工作，想进入一个好的公司，你不做充足的准备，谁会要你。

你所做的付出，就会变成你的收获。

目前已经拿到了字节、京东、好未来、好大夫的offer。百度2面中，美团2面中，阿里3面中.

总结一句就是，多做准备。

在我的认知里面，这个评论者才是绝大部分面试者的真实状态。

就像他说的：如果你不做充足的准备，你能进入你想要的好公司吗？

我理解充足的准备其中就包含大量的刷题，刷面试题没有什么不好意思的。

不乐意刷题，又回答不上来问题的人，才应该不好意思。

从网络上的各种面试信息可以知道，绝大部分情况下都是八股文面试，都是面试造火箭。

大家都在抨击它不好，我也觉得它不好。

但是，主流如此。你又有多少办法来抵抗呢？

最行之有效的方法就是刷题，大量的刷题。见的多了，也就能应付各种刁钻、冷门的面试题了。

然后再整理、结合一下自己真实的项目经历，做好充足的准备。

你也有机会变成一个 offer 收割机。

也有机会在各大平台上发出“凡尔赛”式的求助问题：offer 求对比！

评论三：

我工作快四年了，你如果问我一个深入、详细的技术问题我也可能答不上来。

这四年我觉得自己的收获是：

对系统业务的逐步了解、熟悉；

独自分析、解决问题的能力逐步提高；

向前辈们学习到了对工作细致、认真、负责的态度；

最后才是写代码的规范性有了一些提高

我觉得这个评论比较中肯，其实他的回答也是我工作这几年得到的一些收获。

甚至，是每一个工作了五年左右的人的收获。

会写代码，属于技术中的“技”，而他前面说的三点属于“术”，其中对业务的了解尤为重要。

我认为，当你通过面试，进入职场后，“术”比“技”重要一些。

我觉得，当我不再崇高技术，而真正意识到“技术是为业务而服务”的时候，才是我职场中一大进步的时候。

但是在进入职场前的面试环节，由于时间有限，主要还是考察的“技”。

所以，提升“术”的时候，也请不要落下了“技”。

另外他说的第一句话我也很同意：我工作快四年了，你如果问我一个深入、详细的技术问题我也可能答不上来。

但是我想站在我的角度稍微改一下：我工作快五年了，你如果问我一个深入、详细的技术问题我也可能答不上来。但是，我一定有自己深入了解的、可以说的非常清楚的技术点，只要面试时你给我机会，我就能展示出来。

评论四：

后生可畏啊，做一个技术，还是要有点追求的，如果一直在做crud，就会陷入一个知识的怪圈，在这个圈里，做1年和做10年没有差别。

另外我面试时，向来是你简历敢写，我就敢问，因为你写了这些东西，都是和你期望薪资挂钩的。

这个评论者既然叫我“后生”，那么我应该叫他一声前辈了。

这个前辈的看法，和我的看法不谋而合。

而且这也是非常多的人，包括我的一个困境、一个怪圈：我是拥有十年工作经验，还是把一年经验用了十年？

这应该是一个时刻思考的问题，而这个问题的本质我觉得是另外一个问题：你打破自己的舒适圈了吗？

我想绝大部分做技术的人都不想只是做一个 CRUD Boy 吧？

就像是每个人都知道沉溺于游戏不好，但是就是不愿意承受不玩游戏这种改变带来的痛苦。

就像是每个人都知道一直写 CRUD 不好，但是就是不愿意承受主动去学习新的技能带来的痛苦。

另外，这位前辈说的最后一句话也很重要：好好打磨你的简历，因为它决定了你面试的过程。

评论五：

曾经我也面试过名校而技术水平很一般的人，也面试过工作很多年但“技术能力年限”很少的人，我当时的观点跟楼主一模一样。

现在回想起来这种观点是不正确的，因为当我成为被面试者被别人面试的时候，也会遇到一样的问题，然而我真的有那么菜么？

想想这个循环真是滑稽。

另外不得不说一句，多年的面人经验告诉我，能通过我严苛技术面试进来的人，90%的实际表现都远逊于我的面试预期，所以我后来觉得面试技术人一味的深挖技术问题其实没有多大意义。

相反，正直的人品，诚恳的工作态度比技术能力更重要。

再多说一句，现在招聘有一种不太正确的风气，就是要求应聘者必须要会招聘启事里面的N多技术要求，比如精通某某框架，使用某这个技术组件必须有几年时间，比如具体到某个数据库，具体到某个MQ产品，或者具体到某个RPC组件，似乎符合这些要求的才是合格的应选者。

这种招聘就是招熟练搬砖工，HR这样筛选，面试官再来核实一次，似乎你不真正的会就是技术不合格，我觉得这是很大的误区，会筛选掉真正有能力的人--能够很快学会你需要技能的人。

这个评论中的观点，现阶段的我认同一部分吧。

主要说一下不认同的部分。

其中的这句话：正直的人品，诚恳的工作态度比技术能力更重要。

我能理解到评论者是站在自己已经工作多年的角度得出的结论，也许有一天我阅历的变化导致我观察角度变化的时候，我也能得出这样的结论。

但是，在我目前这个阶段应该是：技术能力和正直的人品、诚恳的工作态度一样重要。

因为，首先得有过硬的技术能力，让自己进入职场，才能展现出自己正直的人品和诚恳的工作态度。

就像我《面试之后》那篇文章里面说的，我觉得面试者很真诚，他肯定有正直的人品和诚恳的工作态度。

但是，他的真诚不能帮他敲代码呀。

我们需要的是一个能快速上手，融入团队的人。

所以，才会有职场很复杂，面试别心软的忠告啊。

另外一个是：这种招聘会筛选掉真正有能力的人，也就是能够很快学会你需要技能的人。

我承认确实会有这样的人被筛掉，这样的人也会愤愤不平。

但是，我也相信通过这种面试筛选出来的“熟练工”，能尽快在团队中输出自己价值，也有相应的学习能力。

这样的人、这样的选人方式，对个人来说是残酷的，但是对企业来说是性价比更高的。

评论六：

其实实际能力和人的思维有关。

很多时候, 找到解决问题的方法才是正确王道。

很多人其实大概的原理是懂得, 因为平时少用或者基本上用不到, 看一遍基本会遗忘。真正要使用的时候, 才拾起认真了解原理。

世界大牛何其少, 大部分人只是普通人中的一员, 不要想着每个程序员都如求伯君一样的大牛。

如果你能把普通程序员合理分配好, 才是出色的架构师.

就如一个工厂, 有高级工程师, 专家, 普通员工, 普通程序员...... 合理分配调度安排, 才能得到出色的产出.

这个评论的前半段是我前面已经说过的：遇到问题的时候，能迅速的知道到哪个地方去寻找答案。

后半段是在说“普通”这个关键词。

是的，在人生的长河中，我们绝大部分都是普通人中的一员。

无论人生是多么的轰轰烈烈，或者是平平无奇，我们终将趋于平庸。

在短暂的职业生涯中也只是一个普普通通的职场人。

我们也终将被行业淘汰，但是我们可以努力让那一天晚点到来。

在短暂的职业生涯中，每个人的选择都不一样。

我特别羡慕那些把工作和生活可以泾渭分明的人。

但是程序员这个行业确实不一样，大家都说这行内卷。

确实是内卷，而我觉得逃避内卷的方法之一，就是一种“饮鸩止渴”的方法，那就是自己卷的比其他人更快一点。

而且我认为做技术，是一件非常严谨的事情。即使我是一个普通人，但是我也可以有工匠精神。

我以前看到过一句话：无论你哪所大学毕业，无论你的工种和职称，你身无匠心、手无技巧、提供不了精准、专业、享受式服务，你就不是匠人，而多半是个职场混子。

当你以工匠精神要求自己的时候，也许你就比普通人优秀了那么一点点。

评论七：

学东西，学技术可以，但是公司招人进来是要你干活的，不是让你来学习的。

虽说活到老，但是他这种在面试的时候直言学习的方式只适合刚毕业、涉世未深的。

对于混迹职场多年的老鸟，不管是以什么方式在混，就算公司愿意培养，给你机会学习，但是你要求的待遇可能又不是刚毕业的那种。

再一个老鸟有些东西、思维方式等已经固化，不像刚毕业的白纸一张可以培养。

这个观点，我深以为然。

社招，招人是来干事儿的，而不是让你来学习的。只要能把事儿干好，你学不学习和公司关系都不大。

当一个校招生说我想在这份工作中能学到很多东西的时候，我会觉得他是可树之才。

但是当面对社招的人，当他说自己想进来学习技术、学习业务的时候。

给我的感觉，不能说不行，只能说感觉怪怪的。

这样不太好，好一点的说法应该是：

我也一直从事相关行业，具有一定的技术和业务储备。虽然业务上肯定有一定的差异性，但是我相信通过我的知识储备，能很快的和公司的业务对齐。

评论八：

看到各种喷楼主喷面试要求的，但从面试官的角度来说，只能从你简历开始，然后抓你简历里面写的一些东西往深了问，这样能看出你对技术的态度。

“精通”的含义不是说一定要求你很懂很精通，更多的是你对这个工具的态度。

如果说你对自己简历里面用过的工具都只是一个略懂，只知道如何用，不知道为什么要这样用，没深度，那说明技术对你只是有的没的，这样的人应聘一个高级岗位，谁敢用？

高级岗位不是只有ABC敲代码的职责。

这个评论，是我想拿出来的最后一个评论。

其实没有其他想说的。

主要还是强调一下简历的重要性。

因为，总的加起来，我至少也看过几百份简历了吧。有的简历真的写的很差很差。

包括我前几天偶然发现自己刚刚毕业、求职的时候写的简历。

真的是没眼看，我都不相信这简历是我写的。

简历上怎么写，绝大部分程度上决定了面试官怎么问。

好了，还有一些其他的评论，我就不一一粘出来了。

有一位大佬甚至写了 2000 多字的评论。里面有对我的批评，也有对我的鼓励。

非常的感谢。

原文链接在这里，有兴趣的可以看看：

https://www.cnblogs.com/thisiswhy/p/14276573.html

最后，如果你真的要出去面试了，我再补充两个问题，你可以稍微准备一下，说不定会用上，希望能帮到你：

• 你觉得有没有什么你擅长的，而我没有问到的技能点？
• 你最近有在自学什么技术吗？

回答个技术问题

关于文章开篇，引战的 Redis 分布式锁，我之前也写过下面这两篇相关的文章，应该是比较详细且深入了，有兴趣的可以查阅一下，我就不再赘述了：

【求锤得锤的故事】Redis锁从面试连环炮聊到神仙打架。

面试时遇到『看门狗』脖子上挂着『时间轮』，我就问你怕不怕？

主要是回答一下评论中的这个问题：

我是没想到，在一片争吵之中，还有人在和我讨论技术问题。

好，那么我就把这个问题当做一个面试题，来回答一下。

一般来说我们的主流可选方案是基于 Redis、Zookeeper 做分布式锁。

稍微冷门一点的有谷歌的 Chubby 和基于 etcd 做的分布式锁。

但是面试官的要求是不引用任何中间件，上面的方案也就都不可选。

这个需求也是有真实存在场景的。

假设我的项目里面现在就是没有使用 zk 和 Redis 服务，我也没有能力去搭建这一套服务，而我要的这个分布式锁的性能也不需要那么高。

那么还有一个可选方案就是基于 MySQL 去做了，而且我还真的基于 MySQL 做过分布式锁。

基于 MySQL 去做，也有两个不同的方案。

一个是悲观锁方案，一个是乐观锁方案。

先说悲观锁的方案。

在 MySQL 中搞一张专门存储分布式锁信息的表。

表里面有一个字段是分布式锁的 key，而这个 key 是一个唯一索引。

当多个请求发起，先进行加锁操作。

也就是多个请求拿着同一个 key 来进行数据插入操作的时候，数据库可以保证只有一个请求插入成功。

其他没有获取到锁的请求，看功能需求：如果需要继续获取锁，就进行周期性的重试；如果不需要继续获取锁，则方法正常结束。

当获取锁成功的这个请求处理完毕后，再执行删除语句，对锁进行释放。

其他的请求就能继续竞争这把锁。

这就是一个最基本的分布式锁功能。

当然了，我们还可以对其进行功能优化。

比如，我们如果需要支持锁的可重入。

那么在表中需要再加入两个字段：一个是线程名称，一个是重入次数。

有了这两个字段，我们就可以做可重入的分布式锁。

同样，MySQL 悲观锁这个方案也是很有弊端的。

最简单也是最致命的，这把锁没有失效时间，如果删除语句执行失败，就是一把死锁。

解决方案也很容易想到。

弄一个定时任务，定时清理表中超时的数据，可以防止死锁。

当然了，还有 MySQL 服务单点问题，那么我们可以用集群的方式解决。

再说一下乐观锁的实现方案。

假设我们需要保证订单表中的一条数据，同一时刻，只能有一个线程能对其进行修改操作。

乐观锁其实就是在订单表中新增一个版本号（version）字段。

当操作数据之前，我们先拿出数据的版本号，对版本号进行加一。

更新的时候，带着原版本号进行更新。

简单来说，乐观锁就是一次 CAS 的过程。

其实我们不加版本号字段，用 select ... for update 对数据加个排它锁，也是可以的。

要是面试官对于这个答案还是不满意呢？

如果我们连 MySQL 服务都没有呢？

其实我觉得分布式锁吧，抽象来看，就是多个分布式的系统加一个共享的服务就行。

比如 Redis、Zookeeper、MySQL 都是多个系统共享的服务。

如果你连 MySQL 都没有，那你部署服务至少是有服务器的吧？

也可以基于服务器去做一个简单的分布式锁呀。

比如，让多个请求去一台专门的服务器上创建文件。

服务器可以保证，只有一个请求能创建成功。

当请求处理完毕后，再删除服务器上的文件，释放锁。

这个道理和 MySQL 不是一样的嘛？

只要有一个共享服务，我们就能基于共享服务去搞事情。

好了，面试官，以上就是我对于这个问题的思考。

最后说一句（求关注）

最后，用我《面试之后，扼腕叹息》这篇文章里面的置顶评论作为结尾吧，只是站在我的角度把前半句话补全：

当我 35 岁时，如果我还奋斗在编码的一线，我希望我被劝退的原因是因为技术能力、业务能力比不过年轻人，而不是因为精力和体力跟不上年轻人。

我希望这才是 35 岁危机的真正原因。