连续两次职级晋升失败，分析一下原因

我们公司虽然不是知名大公司，但每个员工也有相应的职级，类似阿里巴巴 p6/p7/p8/p9 这种。每年我们有两次职级晋升的机会，报名后由相应的技术委员会进行评审，其实就相当于公司内部的面试，面试通过则升级，不通过则保持原有级别。员工的待遇福利和职级挂钩，一旦职级晋升，收入随之提升，因此职级晋升是每个员工都很重视的事情。

我申请过两次职级晋升，但是都失败了，失败的原因有一定的代表性，几乎是每个程序员在职业生涯中遇到瓶颈的缩影。

我是一名程序员，评审的标准很重要的一点是技术水平，于是我在那次晋升面试之前做了非常周详的准备，对跟我岗位相关的技术要点做了周密以及深入的温习，并预测评审委员会会问到的一些问题，事先寻找答案，其实就相当于猜题。在晋升面试的那一刻，我信心满满，觉得任何跟我岗位相关的技术问题都难不倒我了，然而评审委员会问我的问题却令我措手不及，完全打乱的我的计划与设想。

“请问你最近半年的工作给你所在的部门带来了哪些帮助？”评审委员会的一位成员问道

“我使我们部门所开发的一套系统速度提升了 50%以上，同时修复了另一套系统几年来没有办法修复的一些顽固 BUG”我回忆了一些我最近的工作成果作为问题的答案，这个问题在我的预料之外，因为这不是一个技术上的问题

“你说的这些是你的本职工作，是你应该完成的任务，并不是你对你部门带来的帮助。我的问题是指，你的工作对你们部门带来了那些帮助，比如说对整个部门所有成员的工作效率带来了多少提升？让部门对公司的作用带来了多少提升？”评审委员会的那位成员问道

“呃，你问的这个问题里面的内容好像是我领导做的事情”我被问的措手不及

“那你没有在这些方面有所成就咯”他继续问道

“是的，”虽然我很不愿意承认，但是我不得不承认这是事实“可是我只是个写代码的啊，这些事情根本轮不到我管”我不甘心的争辩道，因为这的确不是我的问题

“即使你没有实践的机会，那么如果这件事情真的让你去做，你会怎么做呢”

“呃…”我思索再三，还是没答出这个问题，这个时候我的专业知识、编程能力完全失去了用武之地，我的代码写的再好，程序跑的再快，在管理层眼里也不如让项目提前几天完成，让程序员加班加的更晚来的有用的多。“我暂时不知道怎么做”我回答道

“你平时没有考虑过这些事情吗”

“是的”，我也不争辩，实话实说

“好的，那我们知道，你的评审先到这里吧，我们会根据你的情况做出判断的”

“好的”我起身走出面试的会议室，心如死灰，大失所望，精心准备许久的技术问题储备居然完全没发挥威力，评审委员会问的问题根本不在我的格局之内，一个回合就把我杀的人仰马翻。一整天，我都没回过神来。

几天后，评审结果出来了，不出所料，我晋升失败。

这次评审几乎改变了我原本的职业发展规划，本来，我觉得程序员就应该好好研究技术，把代码写好，把业务吃透。但是经过这次职级评审，我发现由公司管理层组成的技术评审委员会对程序员技术有多好并不关心，他们更关心是员工给公司带来的直接价值，比如你完成的这项工作让公司节省了多少成本，而不是你写的代码有多块，因为现在公司业务发展的瓶颈并不在程序运行的快慢上面。

于是在这次评审过后，我改变了之前以技术为导向的工作风格，我的给自己的定的工作目标变的更偏向于业务以及部门整体的工作成果。比如在产品制定需求的时候，我会提出质疑或者向他们建议怎么做或许更合理；比如我会主动承担一些没有技术含量，但是又难以处理的繁琐问题，处理掉这些问题能对这个项目带来莫大的好处。换句话说，我现在工作模式是以大局为重了，而不仅仅只关注之前的一亩三分地，因为这更符合管理层的口味。

在以这种模式工作了一段时间后，我摸索出了一套与以往完全不同的经验，如果此时评审委员会再对我进行面试，相信我能游刃有余的应付，晋升到下一个级别不在话下。因此，我磨刀霍霍，等待下一次职级晋升报名的到来。

吸取了上一次失败的教训，面对这次评审我进行了全新的知识储备，一切以公司的利益出发，如何使团队发光发热，如何使公司业务增长是我重点关注的项目。评审开始，我信心十足。

“你们项目组用的 Java 吧”评审委员会一位成员问，这是一张新面孔，在上次评审中没有见到他

“是的”我回答

“数据库用的 MySQL 吗”他继续问

“是的”

“那么你是如何应对高并发场景的，MySQL 显然在这方面并不擅长”

怎么开始问纯技术问题了，也太不按套路出牌了，因为上一次评审的缘故，这次技术方面的内容我没有提前准备，所以只能临场发挥了

“我们的做法是，高并发模块的数据读写是在 Redis 上进行的，然后在某种符合要求的情形下再将 Redis 中的数据同步到 MySQL，从而减少 MySQL 的读写压力”我回答

“那如果最新的数据未完全同步至 MySQL，而 Redis 又因为某种原因突然挂了，那数据不是丢了吗”

“我们的 Redis 是集群的，即使有个别节点挂了，也不会造成数据丢失”

“如果所有节点都挂了呢”他追问

“不可能所有节点都挂的啊，不同节点分布在不同机器上，所有节点同一时间挂掉几乎不会发生”

“怎么可能不会发生，我以前就碰到过整个机房所有机器一起断电的。而且现在虽然用云服务器，但阿里云、腾讯云也时常会出问题。你不能让我们公司项目的安全性受到一丁点不确定因素的影响，你应该百分百保证数据的完整性，在任何情况下都不能让他丢失，哪怕是几秒钟的数据。”

“呃…”，我一下子无言以对，他说的也有一定的道理

“那么在你的这种方案中，如果所有 Redis 节点集体崩溃，你如何保证用户数据不丢失”他继续问

“我们的 Redis 会定时将内存中的数据持久化到磁盘，但不是实时，对于数据完整性的保障，Redis 无法跟关系数据库相比。所以，在所有节点集体崩溃的极端情况下，用户数据会回档几秒钟”，我实事求是的说出了我负责项目的缺陷

“好的，我们对你的情况已经有了解了，你的评审先到这里吧，我们会根据你的情况做出判断的”

“嗯”我起身走出评审办公室，这次的晋升结果显而易见，又失败了，之前的精心准备再一次没派上用场。然而，即使不考虑因为没有在技术层面进行准备的原因，这次的失败也挺冤枉的。在评审中讨论的方案从可靠性来说的确是一个失败的设计，我也知道这个问题。但是一来这个项目并非我设计，而是从别人手里接过来的。二来这种设计的确不完美，但是实际出问题的概率极低，因此我也没有动力去改进。再加上因为前一次评审没有涉及到技术问题，我先入为主觉得这次也不会有，然而评审的成员问的第一个问题就是技术问题，我被问的措手不及，乱了方寸，根本回忆不起完善的方案，毕竟写代码是确定一个方案需要仔细反复的思考，甚至写 demo，而我现在相当于要在旦夕之间完成这个任务，结果可想而知。所以，虽然因为技术层面准备的不充分，我没有一定能通过评审的把握，但是死在第一回合，还真的是冤枉。

表面上看，我两次内部面试都失败是因为踩错了点，但事后我仔细考虑，我所晋升的这个级别，既要具备专业的技术能力，又要具备在更高的层面上考虑和解决问题的能力，只是第一次评审和第二次评审的评审项目顺序对调了，所以，我两次都没晋级，其实也在情理之中。

总而言之，程序员在职业生涯之中，到达某个阶段后，想要更上一层楼，除了专业能力不能落下，从部门层面或者公司层面考虑或者解决问题的能力也要培养起来，否则你在某些公司，想往上爬，连那些只有硬性指标的关卡都过不了。