为什么有些大公司技术弱爆了？

题主有年轻气盛的一面，但是你说的问题确实是常常存在的。

大公司常常会遭遇两种病症，我管它叫“滑坡与蒸发”现象。

具体病症如下：

1.滑坡：招聘标准持续降低。人资的硬标准或许在提高，但是实际技术标准在降低。s 级的老一辈面试官，能容忍 a 级的应聘者，过了几年这个 a 级的应聘者自己成了面试官，能力却没提高到 s 级（提高不仅靠个人努力，也要看历史行程），于是他能容忍 b 级的应聘者……所以叫滑坡现象。

尤其是当这家公司历史上经历过极速壮大时期的话，滑坡现象就更加明显。你甚至会发现一线员工技术水平远低于早已脱离一线的经理层。

2.蒸发：如果团队建设跟不上业务发展，大部分人都会处在疲于奔命实现需求的状态，技术水平和交付质量长期得不到提高。个别人由于努力和运气，技术提升较快。如果他没有一个清晰的通道将能力体现出来，就会出现两种可能——要么他会拒绝继续提升，反正现在也够用了，同事还不如我呢，大公司一般又不裁人；要么他觉得同事不行，跑了，蒸发了。最终留下来的人反而是相对平庸的人，那些利用公司资源达到较高水平的人反而让其他公司得利。

最终当你来到这家公司的时候，你就会奇怪为什么他们的技术不如你想像的好。其实不是没有能人，只是要么在经理室里，要么已经蒸发了。

PS：我补充一点，已经有相关领导澄清了，题主的观察可能有偏颇。但是我假设题主的观察没有偏颇，那么是不是你理想中的项目状态就一定好于你看到的“乱糟糟”的状况？

答案是不一定。

不说大道理，我举个例子，题主在互联网圈子里，可能没见过一个版本控制工具，叫 ClearCase，IBM 开发的。特点是极其严谨，极其强大，极其复杂。如果你只看流程图的话，那绝对是严谨到完美的版本控制系统。但是实际用起来的体验如何呢？只能说，让人挠头啊……所以，你想象的那种“清晰而优美”的项目，维护起来，可能是极其难受的。

只有单个程序员写的中小型项目的代码会很强。

两个程序员就会由强变弱。

三个程序员就会没水喝，啊不是，是会有屎山代码的出现。

所以，哪怕在二十二世纪，只要冯诺依曼架构还撑得住，

输入方式和中央处理器没有太多的革命性的进步，那么程序员的工作就永远吃香。

作为一个程序员，你应该感谢屎山代码，以及大公司必然屎山代码的工程本质。

如果代码工程跟造桥打灰一样是可以用工具集约化规模化，

用仪器保证精确性，从而保质保量的……

那他妈你就完了你懂吗？