普通码农如何“C位出道”冲进BAT？

这篇文章，跟大家聊一聊很多很多很多人问我的一个问题：中小公司的 Java 工程师应该如何规划准备，才能跳槽进入 BAT 这类一线互联网公司？

80% Java 工程师都有的迷茫

之所以我用了三个 “很多” 来形容这个问题，是因为实在这个问题太普遍了，因为国内 Java 工程师至少好几十万，但是在国内互联网大厂里干过的码农可能也就十分之一，或者五分之一的比例。

所以，其实这个也是符合 28 法则的，少部分人在大厂里干过，发展的很好。但是大部分人还是在中小型公司，或者外包类传统IT公司里工作。

这些同学可能对自己的技术成长，职业发展感到非常的迷茫，自己有点追求，也想去一下大厂，但是又不知道怎么规划。

我个人在国内几个最大的互联网公司先后有着十余年工作经历，面试和招聘过大量各种水平的开发人员。包括初、中、高级开发，技术专家，高级技术专家，都面过。

同样，也指导过很多同学的职业发展规划，看过大量的同学不顺利的职业发展，所以打算从我个人的角度来聊聊这个问题：中小公司的同学应该如何一步一步实现逆袭进入 BAT。

我相信以下情形很多同学应该都有类似体会：一直徘徊在各种中小公司里开发一些没技术难度的 Java 系统，主要就是 CRUD。

哪怕是用了 MQ、缓存、分库分表，但是也没什么并发量，数据量也不算特别大，自己的技术成长极为缓慢。

然后就是三五年，七八年，甚至十多年，职业发展和技术水平都停滞在这个状态，无法有更进一步的发展。

现在寒冬到来，到处裁员，中年码农的危机，加不动班，体力越来越差，孩子压力越来越大，对自己何去何从很迷茫。

有一些同学是一直徘徊在那种中小型互联网公司里碰到上述情况，有一些同学是在一些外包类的 IT 公司里碰到上述情况。

你的技术为啥十年八年都无法进步？

先来搞清楚一个问题，你的技术到底为什么十年八年都无法进步？拆解一下，你的能力集中在哪几块：

技术广度

对 MQ、缓存、NoSQL、大数据、高并发、高可用、微服务，等一系列的相关技术都有一定的了解，熟悉常见功能 在自己的项目里落地使用过，有一定的技术使用经验，这可以解释为技术广度。

技术深度

读过 Kafka 的底层源码？对消息中间件的架构设计思想有深刻的理解？对分布式事务框架/中间件的架构设计有过研究？在每秒百万并发场景下做过底层系统的深入优化和故障处理？

如果你有类似这种过人之处，那么你才能说你有某些技术深度。

项目经验

你有没有整体负责过几亿注册用户，几千万日活用户的大规模、高并发、分布式、高可用、高复杂度的系统架构设计？

或者你负责的一直都是那种公司内部使用的，几十个人用的 OA 系统，CRM 系统？这些就是你的项目经验。

团队管理

你在互联网公司里带过 20 人的团队？ 或者你在一个传统 IT 公司里带过 3 个人的小组？ 这都是你的团队管理经验。

拆解过后，再来看看，如果你在一些小型互联网公司，或者是做一些传统软件开发，为什么技术无法进步？

其实道理很简单，可能你的公司推出了一款 App，但是不好意思，用户量总共就 100 万，日活用户就 10 万人。

那你觉得你的系统有技术挑战吗？没有。

既然没有技术挑战，你把系统搞那么复杂干嘛？或者你的架构师搞那么复杂干嘛？不需要。

大家简单做一做，主要 CRUD 写一下功能，最多现在 Spring Cloud 流行了，上一下拆成微服务的就够了。

然后这套系统就稳定支撑你公司的业务了，那你接触不到很大的技术挑战，所以技术进入停滞状态，不是很正常么？

或者你做一些传统的软件开发，比如说建筑类软件，办公自动化软件，类似这种的。总共就几十个人用一个系统，或者几百人用，那你就更是如此了。

可能都不需要 Spring Cloud，直接单块系统，单机部署，就是在里面填充业务代码就好了。

所以根本原因，就是很多同学平时的工作环境，他没有什么技术挑战，所以只要把系统技术做的简单一些，低成本就可以支撑公司业务了，那既然这样，当然技术就进展很缓慢了。

然后可能你工作了八年十年，技术广度还可以，对流行的技术自己都看过一些书，简单用过，玩过 Demo。

你的项目经验积累了不少，但是都是一些各个传统领域的系统，业务理解较为深刻，没有极高技术挑战的项目经验。

有的人工作时间长，可能就是带过一些人，有过一些带团队的经验，能管人。

大概就是如此了，每次换工作，还是只能换类似的公司，干类似的技术，依然没有进步，依然是类似的项目经验。

所以大伙儿先梳理清楚，迷茫的根源究竟在哪里。

求卓越，自己设立技术挑战

通常来说，我个人站在公司角度是很反对架构的过度设计的，因为平白浪费很多时间，而且很多架构过度复杂没有必要。

但是如果是站在个人的职业发展角度而言，那么你的 Leader 必须要有对技术追求卓越的思维。或者你是 Leader 的话，就得有对你的团队技术追求卓越的品质。

什么叫追求卓越呢？举个例子，现在你开发了一款办公自动化系统，服务了某个公司，几百人在用，那么技术一般，就是一个单块系统，直接 Spring MVC + Spring + MyBatis 就搞定了。大家都做着没意思。

好，现在 Leader 为了大家的幸福和未来，咬咬牙说：

Leader：兄弟们，现在系统满足公司的发展了，但是我们不如来大胆的追求一下卓越。

兄弟们：领导你是啥意思啊？？

Leader：这样，咱们首先为了提高系统的开发效率，避免 30 个兄弟开发一个单块系统效率太低，我们来实践一把最流行的微服务架构吧。

咱们一起来把系统重构成微服务的架构，把 Spring Cloud 整套东西都用进去。

兄弟们：（认真听着）

Leader：咱们先得做技术调研，小 A 你来研究研究 Spring Cloud 核心技术组件，小 B 你来研究研究配置中心，小 C 你来研究研究服务链路追踪，等等。

大家分头行动，都开始学起来新技术。但是呢，咱们平时已经很忙了，要是占用工作时间搞这个，老板会骂人，大家看，每个人每天额外加班抽 2 小时一起来搞一下，怎么样？

兄弟们：领导，为了大家的幸福，那肯定得赶紧上新技术啊，大家都学点新东西。

最后大家辛苦了 2 个月，一起把系统重构成了整套的微服务架构，每个人都学到了东西，领导也学到了微服务整体架构设计的能力。

Leader：兄弟们，还想不想继续为未来的幸福努力一下？

兄弟们：一切都听领导安排。

Leader：现在这破系统就几百人用，忒没意思了，咱们来大胆想象，假如说以后这个系统要做成 SaaS 云产品，会有几百个公司来用，有几万人，甚至几十万人同时使用一套后台系统。大伙想想，那时会怎么样？

兄弟们：贫穷限制了我的想象力。。。。

Leader：那小 A 你去根据现在系统的访问量估算一下，如果有几十万人用，系统每天的并发量会有多少，数据库能不能支撑住，需要用哪些高并发的技术来支撑？

小 B，你去调研一下，如果有几十万人用，我们会存储多少数据量，性能会有多差，怎么支撑海量数据存储？然后看看用什么技术来支撑一下？

兄弟们：好，领导一句话，上刀山、下火海。

几个月后，大家研发了一套系统，完成了测试，系统集成了缓存集群、MQ 集群、分库分表技术，还有很多其他的一些东西。

这个时候领导就想办法了，能不能跟老板建议一下，咱们就把产品做成 SaaS 云的模式呢？然后是不是可以就把这套系统给部署到生产环境里去？

到此为止，就通过一个例子，给大家阐述了一下，自己在公司里，如何通过想办法不断的追求系统的卓越，提高研发效率，支撑也许可能会存在的更高的并发量，更多的数据量，尽可能把系统做的更好一些。

多想想为了解决自己设想的一些技术挑战，如何尽可能把一些业界常用的技术都学习一下，比如缓存、消息、分布式、微服务、大数据，等等。

然后都尽可能进行相关的实践，积累相关的项目经验。

实际每个人在经历落地的这个过程的时候，方式肯定是不一样的：有的人也许人微言轻，只能对自己负责的模块设想一些技术挑战，然后只能自己在本地拉一个公司代码分支，尝试对这些分支加入一些技术，自己练习思考。

还有的人，可能是个小 Leader，无法左右公司产品发展方向，但是可以尽可能跟上级沟通，阐述自己对系统架构追求卓越的一些构想。

然后，争取到一些时间，尽可能把系统多融入一些技术，给做的好一些。

每个人都有每个人的方式，但是归根到底一句话：如果你本身工作没有技术挑战，那么尽可能多给自己设立一些挑战，多学一些技术，多做一些尝试和实践。

这总是可以尽可能帮助你在一定程度上提高技术，扩展技术知识的。

在这个阶段，我见过最多的人犯的最大的一个错误就是：觉得自己这样倒腾一些技术是没用的，没有实际的真正的经验。

然后他们着急忙慌，心浮气躁，自怨自艾，总想着必须得先进一个好的公司，才能锻炼技术。

实际上，这是一种很浮躁的想法，你要进好的公司锻炼，你必须先打磨一下自己的技术，然后才能有资本去一家更好的公司。

幻想一步登天？那只是你的黄粱美梦

很多人多学了一些技术，有了一些经验，很容易开始有点膨胀，老是想着一步登天，一下子就进入 BAT。

关于这个，其实是有类似的一些成功经历，比如有的人是大专学历，通过自己的努力学习，加上一些机缘巧合，直接一下子就从中小公司跳入了 BAT。

但是就现实情况来看，不是每个人都一定可以一步登天，复制这个经历的。

在你学习了一些技术，同时自己多做了一些尝试，积累了一定的经验之后，此时应该做的是：做最坏的打算，抱最好的希望。

你完全可以去试试 BAT 的面试，TMD 的面试，尽可能去争取机会，但是如果没面上也无所谓。

你可以降低期望，人只要跟自己比就好了。

比如说你现在在某小型的传统外包软件公司，那么接下来如果你能面进一家小型创业互联网公司，有个几百万用户量，日活用户有几十万，比之前的公司技术挑战多一些，用的技术也更多一些，那么你就可以去了。

只要你每一步跳槽，都比之前好，都让自己有进步，那么整体的大方向就是没错的。

也许你先进一个创业型互联网公司，然后下一家就可以进入一个市值几十亿美金的上市互联网公司，再下一步就可以进入 BAT。

在这个阶段我见过很多人犯的最大的错误就是：老是觉得自己刚学了一点东西，就必须立马进大公司。

这些同学往往心态着急的不行，而忽略了自己的学历、背景、经验导致了起点较低。能立马进 BAT 当然很好，但是有时候机缘巧合缘分没到，进不去也正常。

在这个阶段最需要做的，就是跟自己比，别跟别人比，只要每一次跳槽都比上一次好，公司更大，薪资更高，职位更高，技术挑战更大，就可以了。

不断提升自己，最后进入 BAT

一旦你开始做到跳槽进入一家比之前更好的公司，有更高的技术挑战，那么公司本身的技术挑战就会促使你快速成长，还是举个例子吧。

比如说你本来就在做传统软件的开发，用的都是单块系统涉及的一些技术，就是简单的 Spring MVC、Spring、MyBatis等技术做 CRUD 的业务开发。

但是呢，你通过追求卓越，自己业余不停的学习技术，然后对自己负责的一些模块多设立了一些技术挑战，自己构思了很多更高挑战的场景下，可以给自己的模块加入哪些更高阶的技术。

接着你带着自己学习的一些技术，还有积累的一些实践经验和思考，进入了一家创业型互联网公司。

这家公司的好处就在于，互联网公司技术氛围更好，比如 ZooKeeper、Redis、RocketMQ、Sharding-jdbc，等各种技术，在公司生产环境的系统里，都有落地和使用。

那么你此时是不是就不用停留于一些技术挑战的构思，可以开始真正做一些有点技术挑战的工作了。

但是，此时你还是需要继续不停的学习技术，学习更多的架构上需要的技术，深入的学习技术，同时积累实践经验。

然后带着这份工作经历，同时加上你不断加强的技术学习，你进入了一家比如 30 亿美金估值的独角兽公司。

这家公司有 2000 万用户，日活用户达到百万级，高峰并发量可以过万，每天数据库里日增数据量达到了数十万。

此时你开始真正接触一些所谓的：高并发、高可用、高性能、海量数据的实际处理。

基于你开发的业务系统，你开始更多的实践，同时你还对各种涉及到的技术有了更加深入的研究，比如对一些核心中间件系统进行了源码级别的阅读和研究。

最后你终于等到一个机会，BAT 里某家公司让你去面试，经历了四五轮面试之后，对方给了你一个 Offer，是年薪 40 万的高级 Java 工程师的职位。

然后你进去之后，可以在最顶尖的互联网公司里学习开发流程、规范、架构，接触到最大规模的用户量，每天都有解决不完的技术挑战，在这个过程中，你又可以继续成长。

最后可能你再次跳槽，就可以进入 TMD 中某一家，拿下技术专家的 Offer，在大公司里拿下技术专家的职位，带一个团队，达到人生第一个巅峰。

接着你再跳槽，可能一些创业公司就开始挖你去做一些技术管理层。

大家别以为这个仅仅是笔者捏造的一个故事，在笔者指导过的同学中，确实有同学按照这个路线，实现了人生的逆袭！

最后的寄语

最后，送大家一句话：九层之台，始于垒土；千里之行，始于足下。

这里面最难的就是开始的那一步，也就是大量的人都停留在一些完全没太多技术含量的技术工作的情况下，这个时候是最难熬的。

其实只要能把第一步走好，自己拼命的积累技术，努力跟其他工程师竞争，技术远超跟自己同情况的其他工程师，那么你就有机会率先脱离这种困境，开始慢慢第二步，第三步。

到了后面，就是让公司的技术挑战 Push 你不断努力和进步，最后进入 BAT 这类一线互联网公司。

中华石杉：十余年 BAT 架构经验，一线互联网公司技术总监。带领上百人团队开发过多个亿级流量高并发系统。现将多年工作中积累下的研究手稿、经验总结整理成文，倾囊相授。微信公众号：石杉的架构笔记（ID：shishan100）。