Java现在真的不好找工作了吗？

昨天有个朋友给我分享了一个知乎链接。

我点进去一看，是一个小伙子提出的这个问题：Java 真的现在不好找工作了吗？

我觉得这个问题很好回答啊。

“是的，没错，不好找。”

回答完毕。

这个问题下面有一个高赞回答，看完之后怎么说呢？

个人感受是：难怪人家敢开口要 70w 的年薪，人家是有货的啊。

如果是我的话…

这篇文章分享一下这个问题下面的这个高赞回答。

在正式分享之前，先放个防杠声明：

同样的事情，由于每个人的经历和认知不同，就能发掘出截然不同的观察角度。而这些截然不同的观察角度得出的结论，就很容易产生激烈的碰撞。在这样的碰撞里面，没有人绝对的错了，也没有人绝对的正确。

美美与共，和而不同。

以下是正文。

作者：技术王链接：https://www.zhihu.com/question/612836951/answer/3266773572

先介绍下背景

从我的观察和自己面试来看，不好找，而且是越来越不好找，同时，招聘也不好招，尤其今年特别奇怪，我就谈谈今年的情况吧。

年初的时候有个小伙要走人，事情非常突然，当然肯定是找到更好的下一家了，但是我们这边就不好做了，本来团队中是一个萝卜一个坑了，人员冗余你是别想了，总之一句话，少了谁，其他人都会压力倍增，都不会好过。

那么少了一个就得补上啊，上面的意思是不补了，只出不进，然而压力太大了，每个人都忙到晚上十多点，是真的事多，一个人挂好几个任务。

我们是云原生的监控平台，平台性质决定了我们肯定是要服务好业务部门的，大家都比书记还忙，同时对接好几件事情，这么说吧，白天你就别想正常干活，终于懂了为什么人家要配秘书了。

不过对于这件事，头头还是费了不少脑筋来争取的，最终上面终于松口了，但是必须要非常全面的人才，能独当一面的，行业经验丰富的。

毫无疑问，这件事落在了我们身上，我去找 HR 小姐姐沟通吧，需要招聘一个后台，然后我把 jd 都写上了，要求 5 年以上经验，jvm 调优，高并发，微服务，响应式等常见技能吧，当然，由于我们是做监控的，如果有监控相关经验，可以加分，比如做过调用链、拨测、日志中心、主机、容器，告警，异常检测，网络监控等相关监控的，更是我们的香饽饽，于是我把 jd 发过去了。

第二天，小姐姐反馈我这个 jd 写的不行，简历一上去，就好几百人投了过来，已经收到上千份简历了，就为了我们这边招聘个人眼睛都花了，其他的工作不用做了吗？她说我说的这些技能，大家都掌握，而且个个说自己精通，让她怎么选？

我说不是有加分项吗？

如果有监控相关经验的，会给加分项，你重点看看有没有监控相关经验的不就行了？

她说：我哪里知道什么监控相关经验，看了这么多简历都没写这方面的经验，我问他们，他们都说会监控这方面的技能，让我怎么挑选？

我说监控系统的开发确实比较小众，不行就这样吧，挑选几个大厂的，项目经验稍微复杂点的，经验相对丰富一些的，这样好选了吧？

她说，我肯定是这么干的啊，上千份简历，大厂就三四百份，项目经验我也不太懂，但是都写的挺复杂的，经验我是完全按照你的要求来写的，5 年以上经验，还有两百多份简历，要不都推给你？

都推给我，我心理肯定是抗拒的，我这边的事情都焦头烂额，我肯定没时间去筛选这些简历，再说，筛选简历我还真不一定有 HR 的眼力准，毕竟掌握的技能大家都差不多，5 年以上经验的，简历也是写的很成熟了，都有亮点。

这里主要是有个难题，我们想要监控系统相关经验的开发，但是又找不到，只能从其他方向的招人，其他方向的都很优秀，人也很多，这个挑选可真是难倒我了。

最后实在没办法，挑选了几个，你可以这么理解吧，随机挑选了 10 份简历。

那么这几个人，我就都来介绍下面试情况吧。

面试者 1

某手机厂商相关经验，经验非常丰富，8 年工作经验，做的是金融业务，不过大厂做金融也没啥奇怪的了，让他来面试，主要是看他技术栈是异步编程、异步框架、时序数据库、elastic 等方面比较自信，这些东西跟监控的技术还是比较重合的。

我们对这个人的要求，当然是独当一面。

但是也得先来点面试题热热身，否则这么多人我怎么挑选？

出了一道大根堆排序，10 分钟被粉碎，我挺满意。

问 jvm 调优经验，居然扯到了 g1 垃圾回收的内存不可观测性，看来确实有过这方面的经历，问为什么要用 g1，回答说主要考虑卡顿毛刺小，尤其是很多金融业务响应要求小于 50ms，用默认回收器是会有很多问题的，Java 在做高响应问题的时候会存在很多诡异的问题。

当然，他们用 g1 能减轻部分这样的问题。

同时还扯到了 arthas 的不准确性，尤其是统计一些小于 50ms 的请求，arthas 也不一定能完全统计准确。

我问原因是什么，回答并没有找到什么原因，当然我也是头一次听说。

其他的八股文，如 es 分词器底层原理？druid 自动聚合性能问题？异步框架如何监控？异步框架如果出现线程阻塞这种大麻烦怎么办？也是根据简历上问的，基本上回答的八九层吧。

其他的，问一些工作相关处理能力，需求方的业务如何对接？稳定性保证的一些手段？生产频繁出问题的解决手段？如何对模块的工作进行规划？如何制定 okr 等等。

这些问题，没有标准答案，但是要有自己的思考和套路在里面，我的目的是想知道他有没有站在一个更高的维度去考虑问题，显然他做到了。

最后问他期望薪资，他反问我们的薪资结构，这一点让我很不舒服，我直接回答了一句不知道，然后他说大概要求年薪 60 个 w 以上吧。这个要求当然不过分，放在几年前企业抢着要，估计他前面面试了不少家了吧，估计要求放低了，这个还是挺中规中矩的，比正常略微偏低。

当然，对不起，最后没要。原因后面会提到。

面试者 2

这位面试者，找他来，主要是看到他的项目中有 javaagent 相关经验，这是非常宝贵的经验，虽然不是做调用链这方面的吧，但是原理其实都一样的。

也是 8 年经验，大厂同学，目前待业状态，当然，待业状态的我会重点考虑，原因你懂的。

这位朋友是做云原生方面的，也是 to b 方向的，这也是看中他的一点，不过他做云原生主要是做 cicd 方面，根据我对公司 cicd 的了解，要求对技术的理解还是很深入的。

他们用 javaagent 主要做代码扫描相关，测试覆盖率相关，以及他提到的改造了阿里的 ttl 的 javaagent 让我很感兴趣，好了，说说面试情况吧。

上来同样手写一道大根堆算法题，为什么又是这道题？

因为其他的我不熟练了，如果选快排序他们肯定准备了，所以只选这道题了。

这个同学可能没复习好，算法题磨蹭了半个小时，我说好了没关系，说说你的思路吧，最终他说的思路基本上正确，这一关我也就让他过了。

重头戏是 javaagent，所以我也不废话了，直奔主题。

问他字节码装配的时机是什么时候，回答说 main 方法执行之前会注册装配，main 方法之后，类从磁盘加载到内存的时候会发生装配这个动作。

确实是这样，看来理解比较到位了，我又问如果发现某个类装配不上去是什么原因？

他说是因为类的加载发生了在装配器注册之前，就会出现这样的情况。

我问什么时候会发生这样情况，他说比如在 premain 里面就加载了类，或者多个 javaagent 相互冲突的情况，看来是经验比较丰富了。

我问冲突的原因是什么，怎么解决？

他说冲突的原因就一个，多个 javaagent 破坏了类加载的顺序，要么调整 javaagent 的顺序，要么进行合并？

哟？我头一次听说还有 javaagent 合并的说法，我问怎么合并？

回答说就是两个 javaagent 的代码写到一起，比如我们针对 jacoco 的代码覆盖率，就跟阿里的 ttl 相互冲突了，所以我们把 ttl 整合进了 jacoco 里面，说到这里，我真是醍醐灌顶，这个合并操作还真可以解决这个问题。

接下来，我问了一些关于 ASM 和 bytebuddy 以及 javaassist 等有关字节码编辑框架的问题，当然，他是比较熟悉 bytebuddy 的，因为他们自己的 javaagent 里面，直接使用了 bytebuddy 做了一套动态代理。

你可以这么理解吧，就是做了一套 Spring 的自动注入，我问为什么不直接使用 spring，回答说，他们公司目前的 jdk 版本存在很多版本，甚至还有些是 jdk7 的版本，为了相互兼容，不得不自己用 jdk7 以及 bytebuddy 去实现一套依赖注入，我听着好像有点道理，不过具体的原因我也不太明白，没有继续问下去了。

至于八股文，那是必须的，从响应式、大数据、异步编程、数据检测等监控相关的技术栈问了，回答的很一般，估计是刚从大厂毕业没多久，很多技术八股文没准备好。

为了给他多一点机会，我还问了会不会 go 语言，有没有做过数据采集这方面的工作？

回答并没有。

还有是他们工作上的 cicd 的跨机房上传、文件安全性检验、代码热部署、流水线冲突、构建迟钝等等问题，我都问了个遍，这些回答，满分 100 分的话，最多只能打 75 分，好像他只熟练 javaagent。

最后肯定没要，在我这里就决定了不要了，我连期望薪资都没问他了。

面试者 3

某世界 500 强企业毕业，主要做的项目是 iot，物联网确实是非常火爆的一个项目，也是未来的大方向，真不懂这种好方向的人为什么还要转行来我们这边做监控。

让他来面试，主要考虑几点:简历确实优秀，经历也多，技术栈匹配程度相比于其他同学高一点，其次工作空档了半年了，估计是很想找到一份工作，现在形式这么差，也不怕他进来后就走人。

6 年工作经验，iot 方向 4 年，经历都是大家知道的大厂，简历上还这了从 0 到 1 做了这个物联网方面的项目，这一点我最看重，这样的人应该综合能力比较过硬吧。

没得说，大根堆算法伺候好了，不过也是磨磨蹭蹭了半个小时没写出来，好吧，没关系，同样我问问思想，含含糊糊也回答不上来，估计没专门复习过。

那么既然是 iot 项目，我就不啰嗦了，直接从设备到移动端来看看能不能整蒙你。

我问你们设备有多少？

回答同时在线 400+ 的 w。

那么这个设备量还是可以了，这个接入层是怎么做的？

回答是用阿里云的 slb，其实用别人的云，在我心理是降分的。

所以我又问，为什么用 slb，原理是什么？阿里云的 slb 有什么特点？

支支吾吾回答不上来，只回答了一些关于四层负载均衡的原理，我反问不是你从 0 到 1 做起来的吗这个项目，你怎么会不清楚？

他回答说那是上上家公司，那家公司的设备量没有这家的大。

当然，我瞬间明白了。

既然如此，那么我在问接入层后面的应用层，怎么做的？

回答说应用也有个接入层，大约 100 来台机器，每台机器维持 5 个 w 左右的 tcp 长连接，与设备是 tcp 长连接的。然后指令上报和指令下发都是通过这个连接。

接下来问了一些项目设计的问题，如下发指令的时候，怎么知道哪台设备连接的是哪台机器？

回答说使用了 etcd 这种配置中心保存设备连接到的机器，问为什么用 etcd，为什么不用 zookeeper。

回答 etcd 是 key value 模型，性能要好，一致性算法的效率更高，易用性和容易维护等等。

接下来就扯了 etcd 的原理和 zookeeper 原理，给了他张 a4 纸，徒手写了 raft 协议和 zab 协议，勉强能过。

简历写说接入层用过 netty 写，问了 netty 相关东西，不过我不太熟悉 netty，稍微问了下。

综合判断下来，对他们的项目理解还是比较深入，他自己强调综合能力，其实我看综合能力一般，我本来就是看他简历上写综合能力强才让他来面试的。

主要是技术点太狭窄，比如八股文方面，除了关系型数据库，其他的一窍不通，比如没有监控和云原生的概念，比如大数据方面直接就跟我说不懂，比如一些监控的原理也没有去了解过，比如 Linux 相关的优化经验也没有等等，这些原因主要是因为他们的项目中基础设施非常简陋。

最后肯定没要。

面试者 4

大概面试了七八个人，我就不多说了，我最后说一个我们最终要的吧。

某大厂程序员，7 年工作经验，某电商企业毕业员工，说句实在话，对于电商方面的项目及其毕业的学生，我是真看烂了，铺天盖地的秒杀活动，层层限流，动辄高并发高可用，架构设计，微服务，大家都是这么写，所以看到电商方面的项目经验，真的有点审美疲劳了。

但是，为什么我还是会要这个电商小伙呢？

主要是这几个原因，首先是技术栈，除了电商必备的什么微服务、什么高并发等，他还知道 flume、flink、Hadoop 等大数据技术，而且还在他们的电商项目中做过这样的项目，而且他还参与过团队中的一些基础性的建设，比如采集一些主机和 DB 的数据，主要使用 Go 语言，如果他的回答能够达到八分以上，我肯定是要了，实在太疲劳了。

首先，大根堆算法走起，他没有让我失望，20 分钟左右写出来了，可能有些边界不太准确吧，这个不影响。

首先从项目开始，不上八股文。

问你们那边的订单这么多状态，光是退货就好多种状态吧，而且涉及到的系统如此之多，那么一致性是如何保证的，会不会存在订单货退完了钱没返回给用户的情况？如何避免这种情况？

回答我相当满意，涉及到多系统、多状态的问题，一致性是个非常鸡肋的问题，不可能所有订单都能保持一致性，所以有一套系统是专门监控业务的，比如目前系统有多少订单是已经完成了款项还没到商家的，比如当前系统多少订单退货完成了款还没有退回给用户的，比如现在多少订单是下单了还没收到付款信息的，每分钟收到付款多少，每分钟下单数量又是多少，库存与订单的数据差异是多少等等，有个非常大的 dashboard 看板，可以时时刻刻观察。

那么，如何确定出现了不一致性呢？

那就要通过不同的角度来监控了，然后根据不同的角度观测到的数据进行比对，如果双方对不上，肯定是出现了不一致的现象。

比如对于订单测来看，发起了多少笔退款请求，从退款测来看，又收到多少笔退款请求，两者一对比，就知道是不是一致了。所以业务监控非常重要。

虽然我是专业做监控的，我也是仅仅对基础设施进行监控，对业务的这种监控还是第一次这么完善的听说过。看来电商业务是一门比较深的业务了。

问为什么要用到大数据，回答是因为需要给商家做很多数理统计，方便商家做数字化运营，比如流量来源方面，使用了超大规模图数据库 Nebula ，通过 ETL 和 flink 等计算单元，将流量整合进入到库里面，至于这个库，他们对其中的源码还进行了改造，主要是考虑集群性能方面，做了一些裁剪。

我没经历过没具体问了。

比如对商品流量来源的特色统计，需要大规模的 flink 单元计算，统计每个商品的各个维度的流量特性等等。

存储方面呢？

使用了 elastic、druid、TSDB、hdfs 等等技术，算是很高端了，接下来询问很多细节方面的问题，也能正常回答上来。

问采集数据主要是采集什么数据，目的是什么，用什么技术。回答主要是采集 DB 的特性数据，也是为了订单的一致性服务的，如订单入库的数量和服务端发起入库的数量，数据双向对比，使用的技术是 Go 语言，通过采集 MySQL 端口的方式来解决，因为这种需求比较个性化，所以基础平台部并没有做，只能自己做了。

说到 Go 语言，我问是否使用过 Prometheus，回答使用是基础，对 Prometheus 的源码研究是比较深入了，问介绍下源码，他从 Prometheus 的采集数据、数据清理计算、存储、异常检测、可视化、告警策略等多个方面进行了阐述，细节方面也考虑到了，对 Go 的理解也很深入。

几乎是无懈可击了，然后是问了几个八股文，包括 jvm 方面、mysql 索引优化方面、Linux 性能诊断方面，八股文回答大概八分左右吧，还是很不错的。

最后问了下关于对模块的建设经验、架构的定义标准、性能的评判准则、效率的提升手段等等方面，虽然这方面的看法认知还差点意思，但是都有一定的看法，只要以后稍微多往这方面去靠，两三年就能达到一个非常高的水平的，可塑性比较强这个同学。

最后我问了期望薪资，要了年薪 70 个 w ，说实话，算比较合理了，但是我们这边估计很难给的到，毕竟才 7 年经验。

主要考虑到是研究生学历，最终公司给出了 65 个 w 的年薪，我以为他不会来的，他这种人在市场上是很香的，要是几年前，再吹嘘和包装一下，70 个 w 是绝对没有问题的。