讲真，我还没见过这么垃圾的软件公司！

见字如面，我是军哥！

上周，一位前同事（化名小李）找我喝酒吃烧烤，三杯下肚，他开始吐槽下老东家。“我算是开了眼界，"他苦笑着说，"都 2025 年了，原来一家软件公司可以烂得如此全面、如此彻底。"

他的故事，让我回想起这些年见过的各种不靠谱公司。

今天，就来讲讲这个"垃圾"软件公司的典型特征。

1、面试时：美好的幻象

话说，小李是通过猎头推荐进入这家公司的。

面试时，技术总监侃侃而谈："我们采用最前沿的技术栈，坚持工程师文化，给团队充分的自主权。"丰厚的薪资包加上诱人的技术愿景，小李毫不犹豫地接了offer。

2、代码库：一座无人维护的垃圾场

入职第一天，美好的泡沫就开始破裂啦。

小李接手的第一个任务，是修改一个简单的用户信息展示功能。当他拉取代码时，惊呆了：

50 万行代码的单体仓库，没有任何模块划分；

核心业务逻辑里充斥着各种hard code；

一个Util类长达 3000 行，被 200 多个地方引用；

单元测试覆盖率：0.27%。

最可怕的是，当他询问技术债务改进计划时，组长一脸茫然："先把需求做完，优化以后再说。"

3、开发流程：一场永无休止的救火

在这家公司，开发流程基本靠吼。产品经理随时可以冲到程序员身后改需求，理由是"这个很简单，就加个小功能"。

发布流程更是灾难：

没有测试环境，直接在生产环境调试；

周五下午六点准时上线，然后全员通宵；

回滚？不存在的，出了问题就紧急修复；

小李记得最清楚的一次，为了一个紧急bug，团队连续工作了 38 小时。

最后发现，问题出在半年前某次草率的上线。

另外，没有任何技术文档，再说一句，什么文档也没有，核心业务逻辑全靠口口相传。当某个核心成员离职后，他负责的模块就成了一座孤岛，没人敢动。

任何技术改进建议都被驳回。"能用就行"是最高指导原则。当你提出要引入代码规范或自动化测试时，得到的回复永远是："先把需求做完，这些以后再说。"

4、技术决策：外行指导内行的荒诞剧

公司的技术总监虽然是销售出身，却对技术选型有着谜之自信。

比如，某个周一，他突然要求全栈统一使用 GO 语言，理由是他看了一篇公众号文章。

三个月后，项目推进困难，他又下令全部用回原来的技术栈。团队这三个月的工作，全部付诸东流，哈哈，笑死人了。

5、团队管理：完全是程序员的血汗工厂

管理层把程序员当成流水线工人：代码行数成为绩效考核标准，加班时长决定晋升机会。

更可笑的是，公司引入了所谓的"敏捷开发"，实际上就是每天站会汇报进度，晚下班证明工作努力。

一位刚来的同事因为连续三天准点下班，被领导约谈"工作态度问题"。

6、那么问题来了，这样公司为什么还能存在呢？

经过深入了解后，小李找了本质原因：

a、商业模式取胜：公司靠销售驱动，技术只是辅助部门。只要能签单，系统再烂也无所谓。

b、管理层不懂技术：从 CEO 到技术总监，没有人有技术背景。在他们眼中，软件开发就是敲键盘，没什么技术含量。

c、缺乏技术领导力：技术总监只关心如何取悦老板，从不替团队发声。

d、人才流失恶性循环：优秀的工程师不断离职，剩下的要么是能力不足，要么是已经麻木。

7、那么如何识别不靠谱的软件公司？

各位在面试时，可以多问几个问题：

比如，公司的技术债务如何处理？

开发流程是怎样的？

有没有技术分享和成长体系？

甚至还可以观察细节：

办公室氛围如何？

程序员是朝气蓬勃还是死气沉沉？

技术领导在讨论时是据理力争还是唯唯诺诺？

公司是技术驱动还是销售/运营驱动？

最后，小李在坚持了八个月后选择了离开。

临走前，他和技术总监有一次深入交谈。当他详细描述了团队面临的问题和改进建议时，技术总监的回复让他彻底死心："你说的都对，但老板不会为这些看不见价值的事情买单。"笑喷了～

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

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

一个灵魂非常有趣的人～

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

---

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