一家IT公司烂不烂，看这3点就知道了！

见字如面，我是军哥！

我技术总监干了十年，见过好公司，也见过烂公司，本质就这三条。

我做了将近 20 年的技术，带过团队，也面试过无数从“烂公司”里逃出来的程序员。

最近很多人问我：怎么快速判断一家IT公司值不值得去？如何判断一家的公司烂不烂？

我的答案很简单：别听HR画饼，别信官网文化，只看三点就够了。

1、技术债务是主动偿还，还是被动堆砌

每家活得够久的IT公司都有技术债务。这不可怕。可怕的是——管理层对技术债务的态度。

烂公司的典型特征：只认功能上线，不认代码健康。需求永远“急急急”，排期永远“能不能压缩”，重构永远“下个季度再说”。架构腐化、代码烂成屎山，没人敢动、一动就崩。新人来了想优化，Leader说“别碰，跑通就行”。

这背后反映的是什么？公司根本不把技术当资产，只当工具。程序员在这种环境里，干三年不如别人干一年——你学会的不是如何写好代码，而是如何在一个烂摊子上缝缝补补，练出一身“补丁神功”。

而好公司会怎么做？给技术债务留预算，给重构留排期。哪怕每个迭代只花20%的时间做清理，说明管理层明白一个道理：代码质量不是成本，是杠杆。

判断方法很简单：面试时问一句——“你们上次主动重构一个核心模块是什么时候？”看对方的反应，你就全明白了。

2、出故障是先解决问题，还是先甩锅

任何系统都会出故障。真正区分公司好坏的，是故障发生后的第一反应。

烂公司的剧本高度统一：故障发生 → 所有人第一反应不是恢复服务，而是翻日志、找责任人 → 复盘会变成批斗会 → 从此没人敢改代码，谁改谁背锅。

我在曾经待过一家公司见过一个真实案例：一个线上P0级事故，团队花了两个小时在钉钉群里争论“这是谁提交的代码”，而不是先回滚。最后故障时长三个多小时，但复盘会开了整整两天——全是定性、追责、写检讨。

结果呢？技术团队从此变成“防御性编程”：能不改就不改，能加一层判断就绝不碰核心逻辑。系统越来越脆弱，人人自危。

好公司的做法恰恰相反：先止损，再复盘，最后才是责任划分，而且责任划分不是为了惩罚，是为了堵漏洞。

如果你面试时问“最近一次重大故障是怎么处理的”，对方回答时闪烁其词、充满政治正确，或者张口闭口“某个人犯了错”——掉头就走。

3、技术决策是基于技术，还是基于权力

这一点最隐蔽，但也最致命。

烂公司里，技术选型、架构设计、工具链的引入，不是看哪个方案更合理，而是看哪个方案来自“更高职级的人”或者“嗓门最大的人”。

我曾经见过一家公司，CTO坚持用一套小众的RPC框架，只因为他早期参与了那个开源项目。所有反对意见被一句“你不懂全局”压下去。结果呢？招人难、踩坑无人可问、社区基本死掉，整个团队被一套框架拖死。

这就是典型的权力驱动型技术决策——技术不再是解决问题的工具，而是巩固地位的手段。

好公司什么样？技术决策可以有争论，但最终拍板一定基于事实、数据、POC结果。架构师可以说服总监，资深工程师可以挑战架构师。技术面前，职级暂时失效。

判断这一点，可以在面试时问：“上一次技术团队推翻上级的技术提案，是什么情况？”如果对方愣住，或者告诉你“这种事从没发生过”——恭喜你，大概率是个等级森严、权力至上的地方。

写在最后：

很多程序员在烂公司待久了，会自我怀疑：是不是我能力不行？为什么项目总延期？为什么代码越写越痛苦？

不是你不行，是环境有毒。

一家公司烂不烂，不看工牌多漂亮、零食多丰富、团建多高端。就看这三点：

1. 它有没有勇气正视技术债务？

2. 它出事之后是解决问题还是解决人？

3. 它的技术决策讲道理还是讲级别？

如果你三条全中，赶紧走。中两条，谨慎考虑。中一条甚至零条——那这家公司，值得你认真干几年。

最后，愿每一位程序员，都能远离烂公司，写干净的代码，做体面的技术。

回见～若觉得不错，请点赞或分享，分享给你身边需要的朋友们～

关于我：一个 IT 从业 20 年的互联网老兵，1 号店架构师/前饿了么/贝壳找房技术总监，我叫程军，百度可查，目前一人企业，自由职业者。

一个灵魂非常有趣的人～

需要付费修改简历或者 1 对 1 陪跑请联系我或咨询职业规划或提升技术管理能力可以私信我。

---

更多精彩，关注我公号，一起学习、成长