(转载)连续两次职级晋升失败,分析一下原因
来源：v2ex
感觉挺有借鉴意义的
我们公司虽然不是知名大公司，但每个员工也有相应的职级，类似阿里巴巴 p6/p7/p8/p9 这种。每年我们有两次职级晋升的机会，报名后由相应的技术委员会进行评审，其实就相当于公司内部的面试，面试通过则升级，不通过则保持原有级别。员工的待遇福利和职级挂钩，一旦职级晋升，收入随之提升，因此职级晋升是每个员工都很重视的事情。
我申请过两次职级晋升，但是都失败了，失败的原因有一定的代表性，几乎是每个程序员在职业生涯中遇到瓶颈的缩影。
我是一名程序员，评审的标准很重要的一点是技术水平，于是我在那次晋升面试之前做了非常周详的准备，对跟我岗位相关的技术要点做了周密以及深入的温习，并预测评审委员会会问到的一些问题，事先寻找答案，其实就相当于猜题。在晋升面试的那一刻，我信心满满，觉得任何跟我岗位相关的技术问题都难不倒我了，然而评审委员会问我的问题却令我措手不及，完全打乱的我的计划与设想。
“请问你最近半年的工作给你所在的部门带来了哪些帮助？”评审委员会的一位成员问道
“我使我们部门所开发的一套系统速度提升了 50%以上，同时修复了另一套系统几年来没有办法修复的一些顽固 BUG”我回忆了一些我最近的工作成果作为问题的答案，这个问题在我的预料之外，因为这不是一个技术上的问题
“你说的这些是你的本职工作，是你应该完成的任务，并不是你对你部门带来的帮助。我的问题是指，你的工作对你们部门带来了那些帮助，比如说对整个部门所有成员的工作效率带来了多少提升？让部门对公司的作用带来了多少提升？”评审委员会的那位成员问道
“呃，你问的这个问题里面的内容好像是我领导做的事情”我被问的措手不及
“那你没有在这些方面有所成就咯”他继续问道
“是的，”虽然我很不愿意承认，但是我不得不承认这是事实“可是我只是个写代码的啊，这些事情根本轮不到我管”我不甘心的争辩道，因为这的确不是我的问题
“即使你没有实践的机会，那么如果这件事情真的让你去做，你会怎么做呢”
“呃…”我思索再三，还是没答出这个问题，这个时候我的专业知识、编程能力完全失去了用武之地，我的代码写的再好，程序跑的再快，在管理层眼里也不如让项目提前几天完成，让程序员加班加的更晚来的有用的多。“我暂时不知道怎么做”我回答道
“你平时没有考虑过这些事情吗”
“是的”，我也不争辩，实话实说
“好的，那我们知道，你的评审先到这里吧，我们会根据你的情况做出判断的”
“好的”我起身走出面试的会议室，心如死灰，大失所望，精心准备许久的技术问题储备居然完全没发挥威力，评审委员会问的问题根本不在我的格局之内，一个回合就把我杀的人仰马翻。一整天， 我都没回过神来。
几天后，评审结果出来了，不出所料，我晋升失败。
这次评审几乎改变了我原本的职业发展规划，本来，我觉得程序员就应该好好研究技术，把代码写好，把业务吃透。但是经过这次职级评审，我发现由公司管理层组成的技术评审委员会对程序员技术有多好并不关心，他们更关心是员工给公司带来的直接价值，比如你完成的这项工作让公司节省了多少成本，而不是你写的代码有多块，因为现在公司业务发展的瓶颈并不在程序运行的快慢上面。
于是在这次评审过后，我改变了之前以技术为导向的工作风格，我的给自己的定的工作目标变的更偏向于业务以及部门整体的工作成果。比如在产品制定需求的时候，我会提出质疑或者向他们建议怎么做或许更合理；比如我会主动承担一些没有技术含量，但是又难以处理的繁琐问题，处理掉这些问题能对这个项目带来莫大的好处。换句话说，我现在工作模式是以大局为重了，而不仅仅只关注之前的一亩三分地，因为这更符合管理层的口味。
在以这种模式工作了一段时间后，我摸索出了一套与以往完全不同的经验，如果此时评审委员会再对我进行面试，相信我能游刃有余的应付，晋升到下一个级别不在话下。因此，我磨刀霍霍，等待下一次职级晋升报名的到来。
吸取了上一次失败的教训，面对这次评审我进行了全新的知识储备，一切以公司的利益出发，如何使团队发光发热，如何使公司业务增长是我重点关注的项目。 评审开始，我信心十足。
“你们项目组用的 Java 吧”评审委员会一位成员问，这是一张新面孔，在上次评审中没有见到他
“是的”我回答
“数据库用的 MySQL 吗”他继续问
“是的”
“那么你是如何应对高并发场景的，MySQL 显然在这方面并不擅长”
怎么开始问纯技术问题了，也太不按套路出牌了，因为上一次评审的缘故，这次技术方面的内容我没有提前准备，所以只能临场发挥了
“我们的做法是，高并发模块的数据读写是在 Redis 上进行的，然后在某种符合要求的情形下再将 Redis 中的数据同步到 MySQL，从而减少 MySQL 的读写压力”我回答
“我们的 Redis 是集群的，即使有个别节点挂了，也不会造成数据丢失”
“如果所有节点都挂了呢”他追问
“不可能所有节点都挂的啊，不同节点分布在不同机器上，所有节点同一时间挂掉几乎不会发生”
“怎么可能不会发生，我以前就碰到过整个机房所有机器一起断电的。而且现在虽然用云服务器，但阿里云、腾讯云也时常会出问题。你不能让我们公司项目的安全性受到一丁点不确定因素的影响，你应该百分百保证数据的完整性，在任何情况下都不能让他丢失，哪怕是几秒钟的数据。”
“呃…”，我一下子无言以对，他说的也有一定的道理
“那么在你的这种方案中，如果所有 Redis 节点集体崩溃， 你如何保证用户数据不丢失”他继续问
“我们的 Redis 会定时将内存中的数据持久化到磁盘，但不是实时，对于数据完整性的保障，Redis 无法跟关系数据库相比。所以，在所有节点集体崩溃的极端情况下，用户数据会回档几秒钟”，我实事求是的说出了我负责项目的缺陷
“好的，我们对你的情况已经有了解了，你的评审先到这里吧，我们会根据你的情况做出判断的”
“嗯”我起身走出评审办公室，这次的晋升结果显而易见，又失败了，之前的精心准备再一次没派上用场。然而，即使不考虑 因为没有在技术层面进行准备的原因，这次的失败也挺冤枉的。在评审中讨论的方案从可靠性来说的确是一个失败的设计，我也知道这个问题。但是一来这个项目并非我设计，而是从别人手里接过来的。二来这种设计的确不完美，但是实际出问题的概率极低，因此我也没有动力去改进。再加上因为前一次评审没有涉及到技术问题，我先入为主觉得这次也不会有，然而评审的成员问的第一个问题就是技术问题，我被问的措手不及，乱了方寸，根本回忆不起完善的方案，毕竟写代码是确定一个方案需要仔细反复的思考，甚至写 demo，而我现在相当于要在旦夕之间完成这个任务，结果可想而知。所以，虽然因为技术层面准备的不充分，我没有一定能通过评审的把握，但是死在第一回合，还真的是冤枉。
表面上看，我两次内部面试都失败是因为踩错了点，但事后我仔细考虑，我所晋升的这个级别，既要具备专业的技术能力，又要具备在更高的层面上考虑和解决问题的能力，只是第一次评审和第二次评审的评审项目顺序对调了，所以，我两次都没晋级，其实也在情理之中。
总而言之，程序员在职业生涯之中，到达某个阶段后，想要更上一层楼，除了专业能力不能落下， 从部门层面或者公司层面考虑或者解决问题的能力也要培养起来，否则你在某些公司，想往上爬，连那些只有硬性指标的关卡都过不了。
选取一下有意思的评论
楼主还是能比较客观地从自己身上找不足，很是谦虚了。要我我就骂了，一个问题定生死，这不就是碰运气嘛。一般评委会一群人，一人一个问题，各有侧重，然后综合评分才对嘛！
了解下评审委员会的大佬手底下项目的方案，把改进点往他们得意之作上靠，拍马屁于无形
我以前的 manager 曾经反复跟我强调，做事情一定要将 business value 放在第一位去考虑，现在想想其实特别对…
如果平时和评委关系不错的话，你还是这个技术水平，提问不会这么尴尬，结果可能就是你晋升了。
可以考虑换家公司
百分百数据完整性，看到这个就知道这面试官脑子进水了，说技术能解决的，我问几个问题：
1、支付宝为什么说你敢付我敢赔，是因为技术再好，最好的硬件，三地五中心，顶级的团队，该出问题还出问题，那怎么办，投保呗，用户数据出了问题就是丢了钱，只要是不是敲诈，赔给他就是，当你做到了顶级的冗余时，还不能保证百分百不丢失，这个时候再加冗余就不合适了，只要赔偿到位没有什么解决不了的
2、网易炉石机房电源被挖断，数据丢失回档，怎么办，1 包无视发生 2 包洗地 3 包。。。你就是爸爸，你们团队一点数据丢失的预案都没有么
3、天津港爆炸，附近似乎也有数据机房，直接被炸了，这个应对要怎么处理
不想给钱没有预案还想要百分百不丢失，无异于痴人说梦
我上家公司 JAVA 同事晋级失败的原因是，产品总监说不认识他，觉得他工作不活跃没存在感。。。关键他们之间又没有工作对接，怎么认识啊
能不能晋升，在你去答辩几乎就确定了，你应该和你领导加强沟通
我只能说，可能你之后大概率也晋升不了。
先说下我的观点：
1 你先说明了自己并不是“知名大公司”，但却有大公司的体系。
2 从你连续两次晋升的问题来看，你们负责晋升的人并不专业。评测一个人要考虑一个人的综合素质，或者是否拥有这个岗位必要的要求，但从你的描述来说，基本上一个人问的问题，回答不顺畅，直接就完蛋了。真想晋升你的话，肯定是想要挖掘你的潜力，综合你的素质。说句小白的话，你过不过，完全看运气，看面试官的心情。这和大部分公司的面试流程是一模一样的。如果你跟面试官比较趣味相投，那你就过了，不然的话你再牛也过不去。
再回到那个 redis 的问题，你完全可以说什么异地容灾，实在不行全中国每一个省市都放一个机房，吹牛逼么，有能力公司就做这样的方案。任何一个通电的机器，都有可能发生这种问题，问题是成本能不能划得来。
有些晋升名额是内定的，即使你很优秀（优秀到无法替代的人真的很少）
国内面试官的水平真的有点水，大部分都是站在自己的角度和知识范畴来考量应聘者
楼主 redis 上的问题其实可以回答的更好一点，这确实是不足
其实说白了就是楼主不会包装，到了高级岗位技术能力已经不是最核心或者最重要的要求了。
第一次，技术的意义，不是改变世界。而是服务资本。
第二次，缺乏应用视野面。当说到 mysql 不擅长高并发读写时，策略是 mysql 层面的分表分库为首选方案，涉及数据区块划分策略。当涉缓存时，缓存读写日志+日志收集中心也是构建应用必不可少的组建。集体掉线或内存断电，可以通过到达服务器的请求日志数据来恢复 /补偿数据。
还是蛮欣赏这俩面试官的，目的明确，各有所思。
站在领导的角度思考工作的意义，在公司眼里，技术永远是工具，解放和发展生产力的
问题是在于为啥两次晋升答辩都只问一个问题，一个问题就就能判断或者否定一个人了？
总是有不足的。那只看到不足，看不到优点，无法发挥长处的地方。留着干嘛