银行软件工程的冷门观点 | AI生成和翻译
问题：在银行业担任软件工程师，有哪些不那么受欢迎的看法？
回答：
以下是一些曾在银行（投资银行、零售银行以及传统银行的金融科技部门）工作的软件工程师们，真正不那么受欢迎（但私下普遍认同）的看法：
-
银行业薪资丰厚，但却是工程师工作效率最低的行业之一。 薪水很高（尤其是在投资银行），但你将花费 30-60% 的时间在合规表面文章、变更管理文件和等待零技术价值的审批上。
-
大型银行的大多数“金融科技创新”是营销噱头，而不是真正的工程实现。 银行喜欢在包裹着 React 前端的遗留 COBOL 系统上随便贴个“数字化转型”的标签，并称之为革命性的。实际的绿地项目很少见，并且通常会被风险/合规部门扼杀。
-
技术栈通常比“普通”科技公司落后 10-20 年，这是有意为之的。 稳定性和可审计性优先于性能或开发者体验。你将维护 Java 8 单体应用或大型机，不是因为领导层不懂，而是因为监管机构喜欢一成不变的东西。
-
工作与生活的平衡通常比 FAANG/初创公司要好，但人们不愿承认。 尽管有刻板印象，许多银行 IT 职位都有严格的朝九晚五（甚至朝十晚四）工作时间，无限的带薪休假你真的可以休，并且与科技公司相比，几乎没有随叫随到（on-call）。其代价是令人崩溃的官僚作风。
-
许多银行工程师都在“混日子”，并以此为荣。 高薪 + 低压 + 工作保障 = 黄金枷锁。高级职称，总酬劳 40 万美元以上，只写 SQL 和参加会议是很常见的。付出努力反而比得到奖励更容易受到惩罚。
-
监管限制使得良好的架构无法实现。 你无法拆分单体应用，因为每个系统都是“关键的”。未经 6 个月的法律审查，你无法使用开源软件。未经 17 个签字批准，你无法部署。结果是：技术债务不是一个 bug，而是一个特性（feature）。
-
真正的产品是合规，而不是软件。 你的客户不是最终用户，甚至也不是业务部门——而是监管机构。如果软件运行完美但未能通过审计，你就输了。如果软件勉强运行但文件完美，你就赢了。
-
多元化招聘举措有时会比纯科技公司更明显地降低技术门槛。 由于银行业在监管审查下急于达到 DEI（多元、公平、包容）目标，而且面试流程本身就不如 FAANG 严格，因此能力差异可能非常大。
-
承包商和海外团队完成了 80% 的实际编码工作，常驻员工主要负责治理。 “受人尊敬的”全职角色通常是将业务需求转化为发送给印度或波兰团队的任务工单，然后审查他们的工作。
-
大多数人宁愿降薪 50% 也要离开，但从未这样做——因为他们凭借过时的技能无法在其他地方获得同样的薪水。 你呆的时间越长，就越容易被困住。
这些观点在公开场合（尤其是在领英上）很少被大声说出来，因为薪水太高，而且行业圈子很小，但它们在匿名论坛（如 Blind、Reddit r/cscareerquestions、银行 Slack 频道等）中非常普遍。
参考文献：