银行职位排列顺序（银行里什么岗位比较好？）

一、银行有哪些岗位

银行的岗位和部门粗线条划分的话，可以分为前、中、后台。一般来说，划分的原则有这么几个：

前台部门就是直接面对客户的，那些直接和咱们顾客打交道的，比如你去存钱取钱时见到的柜台工作人员，帮你理财的客户经理，还有在大厅里指引你的大堂经理，他们都属于这一类。

中台部门不直接接触客户，主要是搞业务操作或者给前台提供专业支持，还有风险控制。比如，决定要不要借钱给人（信贷审批）、怎么控制可能遇到的风险（风险管理部）等等这些。

后台部门呢，就是给银行运营搞搞行政、后勤、技术支持的，比如像人力、办公室、纪检监察、工会、团委这些职能部门以及我们的信息科技岗。

银行科技岗位就是银行中的后台部门，其优势在于无需经历业务岗位常见的网点轮岗实践，即便初期有此安排，也仅仅是短暂两周的历练。相较于互联网行业的高强度竞争环境，银行科技岗在领导正常的情况，还是能够work life balance的。尤其是在近年来互联网行业频繁裁员的背景下，虽然银行信科岗的工作强度也有提升，但是你只要是银行校招进去的正式员工，一般是不会被开除或者解雇的，可以算是一个比较不错的避风港。

下面我们来分析银行里的信息科技岗有哪些以及哪些岗位比较推荐去。

二、纵向来看信息科技岗

纵向从总部到地市，可以分为以下几块。

总行 ：总行科技管理部门

直属单位 ：软件开发中心、数据中心

省科技岗 ：省公司信息科技岗

子公司 ：信科子公司

从仕途和钱图综合排序如下：

总行>研发中心=数据中心>省信息科技岗>子公司

由于个体差异， 总行科技管理部门也不一定比软开好 。总行信息管理岗招人很少，很多时候是做的一些材料性事务性的工作，而不是从事具体的产品研发。选择总行，就意味你就要放弃程序员的看家本领“编程”，这对于某些本来就厌恶写代码的同学非常适合。当然，如果你十分热爱代码、讨厌写材料、写事务性的文件，选择总行并算不上是一个“好”岗位。

在总行信息科技部和直属单位的选择过程中，我想强调一点：

每个银行对于信息科技部和软开的定义是不一样的

某些银行的信息科技部实际上就是软开，而中国银行的信息科技部那就是实实在在的管理岗。在offer选择的时候教大家一个好方法，招人少的就是管理岗，招人多的就是软开，好岗位永远不会招很多人，招人多的一定不是好岗位。

另外大家投递银行信息科技岗的时候，十分害怕被“子公司化”。事情的由头在于2018年建设银行开了一个头，把他的总行直属机构软开中心全部划转成了子公司建信金科，软开员工重新签订了合同，从建行总行机构员工的身份变成了建信金科子公司员工的身份，稳定性下降。

所以相比于子公司，还是要选择银行内企业编单位

在实际运营过程中软开等直属单位主要负责银行业务，子公司主要负责银保监会不允许银行经营的业务，但又是银行实际经营过程中所需的业务。常见的子公司有农银金科、中银金科、农银人寿、中银人寿等。说它是国企吧，也算是国企，但它还参与市场化竞争。说白了大家学计算机来国企这样的单位，主要就图一个稳定，国企都不稳定了，为啥不加把油去纯正市场化竞争的互联网公司？

两不像的结局就是两头好处都占不到，既没有市场化竞争带来的技术提升、也没有组织关怀下的工作稳定。

三、横向来看信息科技岗

信息科技岗主要可以分为研发部门、运维部门、算法部门等。一般部门的选择， 在入职后 公司首先会收集岗位志愿，比如你是想去软开、运维、数据、安全还是人力。再轮岗，去各个岗位熟悉业务流程。最后领导会结合个人的意愿和实际岗位空缺情况定岗。

下面 以软开为例 大致介绍各个岗位的特点。

研发岗

在银行日常开发中，技术一般不会特别新。一般前端是JSP，后端是Springboot那一套，逻辑都是表的设计和增删改查。在系统开发的过程中，有数不尽的文档，业务知识的梳理，以及一级又一级的审批确认。

运维岗

银行对于系统的稳定性，并发能力要求还是比较高的，所以对于运维岗的要求还是比较高。根据实际投产周期变化，可能会存在上夜班，24小时待命的情况。

安全岗

主要做安全评审，安全测试(渗透测试、漏洞扫描等)还有制定安全规范，配合监管等。

算法岗

大型银行及其他金融机构为了保持竞争力和创新能力，往往会设立自己的创新实验室或研究中心。这些机构专注于探索和开发新技术、新业务模式以及先进算法，以提升金融服务的效率、安全性和客户体验。研究啥，一般和国家和行业的前沿技术动态相关。比如现在大模型火，你就去搞大模型在金融行业的落地应用，举几个例子：农业银行人工智能研发团队推出类ChatGPT的AI大模型应用ChatABC，移动推出了九天•众擎基座大模型，都是来源于这个岗位。

上面说的都是直属单位内的岗位分布，个人建议既然想去国企研发，就要接受它技术栈落后、审批流程繁多、各种材料PPT等问题。

选择岗位时，要看哪些岗位能够最大程度与业务结合，这样技术+业务才是你的核心竞争力，不推荐加入低代码、运维等部门，长时间的重复以及不涉及业务，不利于自身技术和业务的成长。