一个月前写了 软件技术领域就业大纲 ，到今天为止收获了2万多的浏览、1千多的收藏，很多同学找我私信交流自己在软件技术学习、实习、秋招过程中的种种问题。在交流过程中帮助大家，我也慢慢发现新的问题，于是就有了今天这个兄弟篇：

我会软件技术就业时的岗位维度，分前端、移动App开发、嵌入式、后端、数据、算法、测试、交付、运维、技术支持等几个不同的工作岗位，来介绍一个各个工种的主要工作内容、就业特点等。无论哪个岗位，它的好坏一定要放到具体的业务领域、公司、base地等场景中才能更全面地评价，希望大家在看文章不要被我的一些观点影响，形成非黑即白的看法，如果你有学习、求职的目标，或者拿到了offer，可以私信交流，帮你分析一下。

个人能力所限，无法一一覆盖，欢迎指正、完善。有任何问题，欢迎大家私信交流。

前端开发工程师

不管是我们日常用浏览器访问网站时看到的Web页面，手机上扫码打开的各种酷炫的活动页面，还是微信、支付宝上面的小程序，都是用JS、CSS等语言写出来的页面。负责一个软件系统中与用户交互的部分，所以我把他们统称为前端。

前端工程师的日常任务就是在浏览器、手机操作系统等平台上，用编程语言去发起网络请求从服务器上把数据获取下来，然后利用平台提供的UI控件，把数据转化成文本、图片、输出框、按钮、选择框、对话框、列表、音视频等用户可见、可交互的元素。当然，不同的平台可能会存在一些适配问题，比如，不同手机版本支持的音视频格式、图片格式可能不同；不同浏览器版本对摄像头、地图、录音录视频能力支持可能不同等。

我们来拆解一下，一个前端工程师的核心工作分为几个：网络请求获取数据、UI控件使用、大前端代码所在平台的适配。

如果要把前端的工作做好，每个领域都需要深入进去研究学习，这里我们举一些例子。

第一、网络请求

一般来说，前端用到的网络请求就是向服务端发起一个HTTP请求，把数据从服务端拉下来就可以了。但实际开发工作中会有很多的细节问题，比如：

请求数据量比较大，比如，请求几百M甚至几G的大文件时，如何保证不超时、断点续传、不出现设备存储空间不足的问题等。

网络流畅时一切好说，那如果弱网环境下如何优化？

每个设备承受的并发量是有限的，比如一台Android手机，可能最多承受同时并发几十个网络连接，分配我们的可能只有5~10个连接。如果我们短时间内发起大量请求，就可能阻塞住，用户就会看到一直在加载却出不来数据。

第二、UI控件使用

正常情况下，如果我们想显示一段文本，那就用代码操作把一个文本控件放到屏幕上指定的位置，然后把需要显示的文本内容传给控件就可以了。但如果文本过大超出了一屏，要怎么处理呢，是滚动还是省略？

还有图片，网络上的图片有大有小，大的可能几个屏幕显示不完，需要增加滚动、缩放等操作按钮，小的可能几个小素，比如一条修饰效果用的线条。

一个项目启动之后，通常会有设计师来画视觉稿，有的设计师会在视觉稿上提很多特效。比如，点击按钮时有平静的水中被扔下一个石子之后的波纹效果，可系统提供的按钮控件可能没有这种特效，需要自己手动实现。这也是体现前端工程师功力的时候。

第三、不同平台的适配

有的控件在不同平台上面表现不一样，比如，输入框这个组件，在Android上面默认只有英文键盘，而在iOS手机上面默认可能就是全键盘，根据需求这些可能都需要花时间定制。

同样时Chrome浏览器，不同版本对摄像头能力的支持可能不一样，申请权限的流程、系统返回的错误码可能也不同。同样是开发小程序，不同微信版本中安全机制可能不同。

以上这些一个个的小坑只有那些多年开发经验的人才能提前预知到并估算到项目的开发工期当中去。

除了上面这几大类日常工作内容之外，如果一个工程比较复杂，前端工程师还会花很多精力在架构优化、组件沉淀上面，不过所有的事情目标永远是那么几个：降低开发成本、提高开发效率、提升用户操作体验。

讲到这里，前端核心工作就简单介绍完了，下面介绍一下大前端工程师在日常工作中的基本工作流程。

开发工程师在日常工作中基本都是以项目为维度去干活的，一个项目接一个项目的干，有大有小，直到跳槽去另外一家公司，再重复相同的工作。当然，如果工程师晋升到了团队管理者，那一般就不需要做项目了，精力会专注到做好资源调配、关注团队的需求吞吐量、组织人力攻坚关键技术、优化工程架构、通过通用能力沉淀提高工作效率等事务方面。

一般来说，一个项目的核心流程有：项目启动、需求评审、交互评审、视觉评审、技术方案评审、测试用例评审、工程开发、代码Review、提交测试、灰度部署、正式上线等。

除了正式进入开发工作之后所有工程都要做的技术部分之外，这些流程中跟前端关系最大的就是PRD评审、交互评审、视觉评审。

需求评审时，涉及到用户交互的部分，PRD一般都是从功能、页面、组件、文案等几个视角描述需求，这里是前端工程师重点关注的，需要一行行的读需求、消化需求、思考实现方案。而交互评审、视觉评审则会时不时出现一些让人头大的交互方式或者视觉效果，有时一个重要而特别的效果可能会让一个资深的前端工程师花上几天时间才能实现。

到这里为止，相信你对H5、小程序等前端工程师的工作职责已经有了初步了解，接下来我从就业方面谈谈对这个岗位在就业方面的一些理解。

第一、坑位数量

程序员找工作时自然也会受到供求关系影响，而这个世界的绝大多数系统都是给人来使用的，那就少不了前端开发工程师的参与。小到刚起步的创业公司，大到世界范围内的Top大厂，不管是做toC的活动页面，还是搞toB的管控台，都有海量的页面需要开发。可以说，研发团队中的前端工程师都是数量仅次于后端工程开发的一群人。

近几年微信、支付宝这些平台类的超级App一统天下，很多中小型公司不再需要单独开发手机App，只需要前端工程师在这些超级App提供的基础技术能力之上做做小程序就行了。即使在超级App内部，为了节省资源、提高效率，也往往会大规模使用跨平台框架，做到一次开发、多个平台同时更新，而基于这类框架之上的开发往往前端工程师来完成的。

这个世界上的绝大多数软件开发出来之后是要给人使用，需要与人交互的，而只要与人交互，就少了前端页面。

第二、待遇

初、高级工程师的角度来看，前端丝毫不弱于其它类型的工程师。但到了资深开发这个层级之后，相比后端开发、嵌入式、算法等岗位，前端工程师的天花板比较低。

举个例子，市场上年薪50万以上的岗位中，极少有招聘前端工程师，但招聘后端开发、嵌入式、算法等岗位的却还是有很多。

第三、发展空间

前端工程师绝大多数情况下都是只关注交互效果，不关注业务逻辑，所以一般不会成为软件开发中的最核心角色。举个例子，一个软件、互联网公司如果想找个CTO，通常都是需要做后台开发出身的人，如Java。因为后台关注业务逻辑，是整个技术架构的核心。

在我经历过的大厂团队也经常会出现这样的情况，前端开发这个岗位做到基层技术团队管理者之后就很难再往上晋升了。

第四、技术深度

与后端开发工程师相比，前端的纵深、广度要弱很多。H5、小程序开发需要掌握的技术栈相对简单很多，之后的工作生涯就是在不停地按照PRD和视觉稿做一个又一个的页面。当然，如果有流行新框架了，还要再学习一下新框架。

最后，简单总结一下我的结论：

如果你对技术并没有太高的追求，做个普通的程序员，混口饭吃，那就选择前端开发。反正只要是与人打交道的软件，就需要前端工程师来写页面，市场空间是足够的。

如果你是跨专业进入IT行业想做软件开发，前端是个不错的选择，技术门槛要求比较低，技术栈也比较简单，相比后台Java开发来说，深度、广度要求都不高，大厂、小厂之间的要求差异也没有其它工种那么大。

如果你的目标是在某个技术领域成长为专家，不要选择前端，一定要去做后台、算法、嵌入式等。

移动App开发工程师

2007年苹果发布了iPhone一代，从此拉开了移动互联网的大幕。

无数中小创业公司盯上了这个风口，搞出了移动版搜索、移动版IM等，妄图在新的场景下面颠覆掉那时已经冉冉升起的几个巨头。我也在2008年毕业加入了一家移动互联网创业公司开始搞移动App开发。

随着智能手机的迅速普及，10年开始各大互联网公司开始从市场上疯狂抢压移动端开发工程师。那时几家大厂已经有了巨头的气象，校招985/211起步，社招也是开始掐尖，但在抢夺移动端开发工程师的时候，什么都不顾了。那些站在移动互联网前沿探索的中小公司培养出来的移动端开发工程师绝大多数都顶不住工资double+进大厂这样的诱惑，一个个被挖走了。

那几年人人谈移动互联网色变，腾讯北京研发中心的大老板给自己手下的管理干部开大会时说，你们所有的产品线有一个算一个，谁不搞移动端产品谁滚蛋。于是，手机QQ、手机微博、手机音乐、手机QQ空间一个个冒了出来，腾讯深圳总部的业务被北京研发中心拆成了一个个独立地App，搬到了手机上。

移动端开发工程师的待遇开始像被吹到风口的猪，不管是iOS还是Android，工作一年过万，两年两万，三年三万，四年四万，跳个槽如果不double一下都不好意思跟人说。到了13年，有大厂AllIn无线，甚至直接把一帮Java工程师拉过来转Android开发。

那时谁也没有想到，移动端开发工程师们的黄金时代在15年的时候戛然而止，因为微信这样的超级App开始垄断用户注意力，将一众五花八门的手机App挤出了手机屏幕。

也就是那时开始，Hybrid、Weex、RN、小程序、Flutter等跨平台方案开始一波波地先后冒出来。而不管是Android还是iOS，写原生页面的移动端开发工程师们越来越被视作降本的目标。简单的算法，同样的一个页面，用跨平台方案只需要一个前端工程师做一次开发就行，而且随时发版，而原生开发需要iOS、Android各写一遍，发个版还要一顿折腾。

于是，搞原生代码开发的移动端工程师们开始退守到性能、崩溃率、首页加载速度、网络优化等基础问题领域，甚至端智能等创新领域。一直到现在，看看大厂的那些移动端工程师们的日常工作，除了偶尔写几个原生页面之外，不是在造轮子就是在优化那几个指标。

过去几年，超级App越来越强势，虽然偶尔有一些新奇特的公司，甚至新的巨头冒出来，但市场上移动端开发的需求却越来越弱。主要有以下两个原因：

1、移动端的开源框架越来越丰富。早期一个图片加载器就需要一个高级开发工程师专门做一套，还被当作项目的核心代码，而现在把开源项目clone下来初始化一下直接用就可以了。甚至市场上面还有mPaaS这样的整套解决方案，每年花上几十万就可以用上大厂的移动端技术把App搭起来。同样复杂的项目，需要的人越来越少。

2、越级App垄断用户的手机屏幕之后，掌握了流量分配权，再通过小程序等技术经营开放平台，将流量留在自己App内不再外跳。中小企业的独立App想获取流量越来越难，干脆直接去微信上面搞公众号和小程序了，这导致市场上的坑位急速减少。

要知道，大厂就算给的工资再高，移动开发团队再庞大，才能招几个人？像微信、淘宝、抖音这样的超级App，每家几百人的移动端开发团队顶天了，赶上经济危机，企业收缩业务，不搞那么多创新产品，这个数字还可以再少一些。

坦白来说，市场上面真正创造就业并把平均薪水给托起来的是中小企业。

所以你看，开发门槛越来越低，做App的企业越来越少。市场需求变少了，工资变低了，找工作难度变大了，大家也就不愿意再学了。

但是，物极必反，据我观察，最近两年供给减少的速度已经大过需求减少的速度，也就是说市场上对移动端开发工程师的需求虽然少，但做移动端开发的人更少，所以移动端开发工程师找工作时的谈判能力比之前要变好了。虽然再也无法回到10年前的那个黄金年代。

移动端虽然供需都在减少，但并不会消失：一则是超级App有稳定的需求，二则市场上还会有不停地新产品冒出来，三则很多toB领域的需求存在，比如，外卖员、滴滴司机都需要App，四则市场上存在大量基于设备的Android应用开发需求，比如，像电视、快递柜、医院取号机一样可交互的终端设备。

作为面向用户的交互场景产品，移动端开发工程师这个岗位跟前端工程师有相似之处，即，没有站在产品或者业务的核心链路上。

一家公司，不管是开发系统支撑自己的互联网业务，还是做出软件来向客户售卖，大部分的重心都在于业务逻辑。比如，电商、内容、音乐、视频等，都需要庞大而复杂的后端系统来支撑，比如，推荐系统、内容管理系统、审核系统、交易系统、支付系统等，里面都包含了大量不同企业之间个性化的业务逻辑。

比如，同样都是做电商，拼多多、京东、阿里三家的商品、营销、交易、支付、资金、结算、逆向、供应链大不相同，都需要Java工程师一行行地码出来。

可是移动端开发工程师们并没有参与业务逻辑的开发。随着各种开源框架的成熟，他们除了还可以在性能、稳定性这些点状的地方发力之外，所做的无非就是发个网络请求从服务器把数据拉到手机上，再转化成UI控件显示到屏幕上，当用户点屏幕时，再重复同样的流程。这样一个下限很低上限很也很低的工作，如何能让他不被效率更高，一次开发页面Android、iOS两个系统都能跑的前端开发工程师替代？

所以，在这个基础设施越来越成熟的年代，作为一名搞应用层开发的码农，不管是做软件产品还是做互联网系统，最核心的永远是业务逻辑，一定要站在业务逻辑的核心位置才能保证自己不被技术革命给淘汰掉。

嵌入式软件开发工程师

电脑、手机、平台这种大众化的通用设备平台上，应用层软件百花齐放，因此，做标准设备的厂商少、技术和渠道门槛高，而市场上绝大部分是软件厂商，通过软件、互联网服务赚钱，只要能满足用户的某一个细分领域需求，在庞大的用户基数之下，就能活下去。

而手表、电视、冰箱、机器人、汽车、工业设备这类设备，厂商主要靠卖设备挣钱，软件只是为了让硬件设备功能更完善的附加品。因为与硬件高度绑定，在开发软件时，与芯片、存储、网络等硬件模块交互比较多。这个领域我个人归类为嵌入式开发。

“嵌入”指软件与芯片或硬件紧密结合。

嵌入式开发需要了解供应链厂商、硬件规格与架构、行业标准，与BIOS、Bootloader、内核、驱动、文件系统等打交道，做系统裁剪，编译内核，开发驱动，依据设备的硬件能力，做出与设备高度绑定的应用程序。

举几个例子：

工业场景下的嵌入式开发，除了常规的软件技能之外，还需要了解工业的标准，比如抗干扰，散热，还有工业上的协议，比如通信协议modbus。

航空航天，需要用国产芯片，涉及到抗电磁辐射的设计等。

汽车领域，需要了解CAN、AUTOSAR等各种规范和标准。

就业特点

应用层的App、Linux、Java开发之类的岗位因为都是通用技能，信息壁垒弱，中国市场人才供给量大，薪资相比其它行业又高，所以软件技术人员年龄大了之后很容易被年轻人替代。

而嵌入式开发与硬件交互，甚至和芯片绑定，除软件技术之外，还需要许多其它的实践经验积累，如，硬件设备、操作系统、设备工作环境、电路、供应链管理及成本控制、功耗分析等，因此，更依赖经验，就业面更窄，技术变动频率低，中年危机更晚。

我曾经对很多同学讲一个理论：软件技术市场是个倒金字塔，从上向下，应用软件、中间件、操作系统、硬件设备、芯片这几层，越向下市场需求量越小，就业空间越狭窄。

大家可以到社招网上搜索一下，数据库工程师、系统工程师、嵌入式开发工程师的需求远小于前端、Java、应用算法这些在通用平台上做应用软件开发的。

技术分类

嵌入式开发领域中，从技术角度又可以细分为以下几种：

单片机：单片机是可以编程的集成芯片，稳定性差、灵活度大、开发成本高、价格低。

PLC：单片机加上外围电路组成，厂商负责集成完毕，稳定性高、灵活度小、开发成本低、价格高。

嵌入式Linux：嵌入式设备资源有限、功耗低、体积小，要使用原生Linux的话，需要裁剪、优化，去掉用不到的功能和驱动程序，减少系统对设备资源的占用。不同的设备一般会使用不同的内核版本、驱动、应用程序，并做硬件的适配和调试。

驱动开发：厂商做出一个硬件模组之后，并不能直接售卖，需要开发对应的驱动程序，让硬件可以与其它设备通信交互，这就需要开发驱动程序。

GPU&CPU&FPGA&DSP&ASIC&SOC：芯片厂商往往会向上层的操作系统、中间件、应用软件厂商提供一些扩展指令集，提供的方式就是一些工具包，如，英伟达的CUDA，DSP厂商提供的音视频、图像、雷达信号、通信处理API等。

其它处理器类型：存储芯片、传感器、电源芯片、通信芯片等，要与其它设备交互，也都需要与之外配套的驱动开发、API工具包开发和集成等。

Android：虽然手机操作系统量最大，但还被众多的厂商移植到手表、电视、医院取机号等设备上。这些设备厂商在移植过程中需要做操作系统裁剪、适配、定制应用开发。可能涉及到，内核、Framework、App层的开发，工作分类比较杂，不是本篇文章重点，这里一带而过。

就业领域

消费电子

手机、平板、手表等消费电子设备方面，主要是Android系统的移植、扩展，驱动开发，内置App开发等。

汽车产业链

AUTOSAR：汽车系统最重要的中间件，没有之一，国内玩家只有华为、普华、百度、长城、东软等少数玩家

MCU：主要应用场景是汽车，一般用于做外围设备控制、数据采集、简单的数据解析、数据传递，改驱动、调参数，然后被AUTOSAR调度。一辆汽车里就包含几十个MCU芯片。国内外代表企业有：瑞萨电子、恩智浦、ST、华大半导体、士兰微、复旦微电子等。

MCU受限于性能，软件技术人员在开发上面发挥空间比较小，但是需要读原理图、了解外围设备协议、读各种元器件手册、甚至上示波器等，技术栈很杂。

智能座舱：三电将汽车变成了一个大号手机，除了PK体验之外，卖完硬件之后再卖软件和服务是一种更长久的商业模式，所以自动驾驶和智能座舱这类软件系统是所有厂商都要大力投入资源搞的，大厂自己弄，小厂找供应商。

IC厂商

如，德州仪器、三星、TI等，芯片出厂之前需要适配操作系统，开发驱动等，甚至提供从芯片到应用的一整套解决方案，对工具包、驱动开发、不同平台上应用开发等工程师都有需求。

工业软件

如，电梯、飞机、汽车、机器人、医疗/环境设备、工控主板/工控机等领域。

工业软件开发中，上位机负责从下位机读取数据，处理数据，并下发控制指令给下位机，职责类似：机器视觉处理，运动控制，数据采集、显示这样。

上位机开发，可以简单认为是工业软件领域中的应用层开发，比如，使用C#、C++、Java、Python等语言，基于WinForm、WPF、QT、MATLAB、LabVIEW来做一个运行在PC机上的软件。

搞上位机的时候，大量中小企业不需要像市场上主流的软件/互联网企业那样搞大型软件工程，甚至完全不讲设计模式也有可能，反正就是硬干，把页面拼装出来就行了。整体的门槛相对比较低，但领域狭窄，工业市场中逻辑变动不大，所以技术门槛和待遇会比较低，但也没有互联网和应用软件市场那么风云变换。

下位机开发，就是工业自动化设备、机器人、传感器、仪器仪表等，主要是PLC或者单片机，正经的嵌入式开发。

其它设备

当然，市场上还有大量形态不一、规模各异的终端电子设备，如：家电、安防、POS机、电子玩具、智能家居、空调、洗衣机、电源管理、蓝牙、WiFi、路由器、基站、存储器、平衡车、电动车等等。

只要涉及到终端电子设备，就少不了嵌入式开发工程师的饭碗。

后端（服务器）开发工程师

在软件工程中，所有业务或者产品都绕不开服务器开发。

打开手机，看看我们日常使用的软件，微信、音乐、手机淘宝、拼多多、支付宝、知乎、哈罗单车、滴滴打车、Bibili、天天基金，这些产品在开发过程中哪个岗位最重要最核心？我想所有做过软件开发的人都会回答：服务器开发。这些公司的CTO无一不是在服务器开发领域有深厚的积累。

前端、测试、客户端、数据等工程师如果没有经过服务器开发的历练，永远不可能独自负责掌控一个完整软件产品的技术工作。

我这里先讲一讲做服务器开发需要具备的素质。

第一，要成为一名合格的服务器开发，要对语言、API、运行环境本身做到精通。比如，关于语言特性、JVM垃圾回收等问题在Java面试中出现的概率绝对在90%以上。

第二，服务器开发工程师需要掌握比其它所有软件开发工程师都要深度更深、广度更广的技术栈。比如，数据库、应用框架、容器、集群、网络部署等，不光要知道如何使用它们，还要了解它们的原理，在线上出现问题是可以迅速地排查、解决。

第三，需要掌握做业务的方法论，这一点是其它岗位的工程师不需要关心的。我之所以说服务器开发是软件开发最核心的一环，也是这个原因，服务器开发需要对业务所有的细节了如指掌，并用工程进行实现。

当一个业务比较简单时，比如，仅于CRUD的操作，水平再差的工程师也能搞定。但当一个业务比较复杂时，比如，微信的大规模用户通信处理、抖音的海量音视频推荐、拼多多的交易系统、支付宝的金融核心等，系统无比复杂，需要几百、几千工程师的协同。这个时候，系统架构师必须有成熟的方法论，将业务在水平上进行分层，在垂直上划分为不同的域，每个分层又会进一步分层，每个域又会进一步划分出子域，最终还要能让每个架构分层和域之间互相协同起来。而工程师资源的排布就以这些分层和域的划分为依据。

举个例子，到双11了，那用户在淘宝上浏览商品、加购、下单、支付，简单的几个操作背后涉及了大量的系统调用。

浏览商品这个动作，会涉及到推荐系统和商品两域；加购会涉及到购物车域、营销域；下单会涉及到订单域；支付会涉及到支付、资金、结算等域。这里面每一个域可能都是一个几十上百号人的业务团队在负责，同时还有为这些业务团队提供数据库、应用框架等基础设施支持的基础技术团队。

将其中某一个域放大来看，比如订单，又会涉及到价格计算、订单渲染、订单创建、订单查询、订单搜索等，这些子领域每一个都需要一个小的服务器开发工程师团队来支撑，以保证这些核心链路的稳定、高效。

对一个初级服务器开发工程师来说，可能掌握了语言、API，再了解一些常用的应用框架就能干活了，这样的工程师大量存在于大大小小的公司，可能也是最庞大的一群人。

随着工作年限越来越长，接触过的业务、用过的技术越来越多，开发经验越来越丰富，工程师就要开始思考架构设计，完成向系统架构师的转变。大量在中小软件公司工作的工程师会终生停留在工程师的水平，只有那些经历过复杂业务场景，并主动思考、学习的工程师才能完成这一步转变。

这一步既是思考方式的转变，也是个人技术实力的升华。迈过去了，从此之后，语言、框架这些频繁迭代的工具就不会再限制你的发展空间。迈不过去，等你到了35岁，体力、精力大幅下降的时候，就会被更年轻的人给淘汰掉，因为他们比你投入工作的时间更长，学习新工具、新框架的速度更快，出活比你更多。

这一点是服务器开发工程师和数据、算法、前端、移动App、测试等研发岗位最大的不同，也是一般服务器工程师和系统架构师的最大区别。

像数据、前端、测试等岗位，做到5年之后就会发现个人技术水平到了瓶颈，机遇好的开始带团队，做做协调资源、沉淀组件的工作。但管理的坑位毕竟有限，大部分工程师就只能慢慢地变老，等着被新人淘汰。

但服务器工程师不同，只要你突破到了系统架构师这个层次，即使在一线，职业生涯会延长到40岁没有问题。

接下来，我从就业方面聊聊服务器开发。

第一、服务器开发是一个下限很低的工种。花钱去培训班学上几个月，熟悉一下语言和API，再了解几个常用的应用框架，像SpringBoot之类的，也能干活。市场上也有大量中小企业的业务和产品并不复杂，一个资深的架构师带着一堆初级工程师就能完成软件系统的开发。

如果你是跨专业转行过来的人，做服务器开发是个不错的切入点，原因就是坑位多。

第二、服务器开发又是一个上限很高的工种。成长为系统架构师之后，你可以继续挑战更复杂的业务场景，也可以深入到数据、网络、存储、容器、应用框架等某一个领域中去做技术设施。服务器开发中，有很多领域可以让一个人十年、二十年的投入进去。

第三、坑位特别多。在拉勾上搜索一下“Java工程师”，绝对会有一大堆的结果。不管是做互联网，还是企业软件，不管是大大小小各种规模的私企，还是银行、券商、运营商等国企，开发工程师团队中人数最多的往往都是服务器开发。

第四、待遇上限高。年薪50万以上的测试、前端工程师、数据开发等岗位很少，但年薪50万以上的后端开发岗位很多。

第五、使用的语言。

整个中国都是以Java为主，近几年go语言的使用也开始多了起来，在boss直聘、拉勾这类社招网站上搜一搜就能看到，国内基本每个大厂都会有些应用使用go来写。另外也有很多公司整体技术体系都架构在Go语言上，如，字节、知乎等少数公司。

但是，至少在可见的未来，Java还是绝对的主流。

说到这里，要单独提一下Python。

在商业公司用它来搞搞数据分析、算法开发、做个工具，在学校或实验室处理下数据、搞个demo都没有问题，真要搞大型工程的话，我工作这么多年只见过一次，还是DAU十万级别的小应用。

整体而言，Python只是个脚本语言，不是工程开发语言。虽然算法工程师、数据分析师也会用它，但招聘方在考核算法、数据分析师这类候选人时，是不会看他的Python水平的，因为无法靠它驾驭大型复杂工程。

以上，其实就想说一句：如果想走正经的软件技术路线，不要把Python当作一门主要语言来学，它跟shell、SQL、Lua等没有本质区别，只是个辅助性的脚本工具而已。

数据开发工程师

基本上每个大厂里面都有独立于业务、产品、研发部门的大数据开发团队，我们一般管他们叫BI，BI团队的工作职责有很多，但首先得收集数据，并进行建模。

数据来源于公司面向用户或者客户的产品。用户使用微信聊天、使用抖音刷视频、使用淘宝购物、使用支付宝付款、使用头条看新闻，客户使用钉钉或企业微信聊天时，会浏览、点击、购买、支付、评论，想想每个产品每天都有几亿的用户在使用，每一个行业都会被软件工程师收集、存储，这会产生大量的数据。

这些数据五花八门，举几个例子：

1、微信用户XXX早上8点钟第一次进入微信，先是在首页停留了10秒钟，接下来进入了朋友圈，浏览了100条信息，然后退出。

2、抖音用户XXX在社会热点频道点击播放了XXX小视频，播放了80%后退出，并给视频点了赞。

3、淘宝的用户XXX在618会场点击了XXX商品，进入商品详情页，浏览了XXX秒之后下了单。

软件工程师在收集这些数据时，通常会把当时的上下文信息全部一起采集，这会让数据中的信息量很丰富，但同时也杂乱无章，有的甚至因为软件系统问题而夹杂了无关的信息。

BI的工作就是将这些数据中的无关信息清洗掉，将有效信息按不同业务进行建模。像上面的那些日志，经过BI的处理之后，会形成一张张结构化的数据表，用户购买行为表、用户观看行为表、用户互动行为表等。

有了这些最基础的，以业务为单元的数据表之后，就可以在上面进行数据开发工作了。一般BI团队支撑的场景有两大类：

第一，面向决策人员提供数据分析服务。主要是公司管理层、各业务部门主管等。CEO可能是以月为单位关注公司的现金流、用户数等核心指标；业务部门主管可能是以周为维度关注自己所负责业务的核心指标，比如，淘宝的用户浏览商品量、点击转化、加购转化、下单转化、支付转化、退款退货率等等，抖音用户的每天打开次数、视频播放量、播放时长、视频互动次数、视频分享量等。

第二，日常业务项目支持。公司内日常的很多项目都需要用到BI支持，比如微信要新上一个“拍了拍”功能，在产品设计阶段就会给BI提数据需求，提出要统计的数据，像“拍了拍”上线之后的用户使用量、使用次数、群聊场景使用量、单聊使用量、各地理区域在使用上的差别分析等。软件工程师在开发产品时会做数据收集功能，等产品上线时，BI就要把收集回来的数据做清洗、建模，然后形成报表供产品经理分析这个功能是否达到了预期的效果。

这一部分很多其实并不需要专业的数据开发工程师，原因也很简单，一般情况下，只要不是处理起来特别复杂的数据需求，参与项目的软件开发工程师自己就把数据分析工作给干了。数据的清洗、建模说起来高大上，真正落地时就是写大量的SQL。软件工程师自己申写SQL跑一跑就出来了。

综上，虽然现在做事情都讲究数据驱动决策，但BI在大部分公司内的配比并不高，可能一个几百号人的开发团队才配置几个BI。

公司为什么不多配一些？这不正是我们大数据专业学生的机会么？

错！

在整个业务研发、运营的链路中，BI可以提供的价值很薄弱。就像我在上面讲到的，数据开发工程师的大部分工作都是软件工程师能搞定的。

而如果你选择了一个没有站在业务核心价值环节上的岗位，你的待遇、就业选择空间、发展空间就会比较小。就拿BI来说，最起码中型以上的公司才会设置这个岗位。放眼市场上，坑位数量少，50万以上的高薪坑位数量更少。

所以，综合来看，大部分公司内部，数据开发工程师也是一个门槛、天花板都比较低的岗位。

算法工程师

时至今天，算法已经融入到各个软件场景中，成为一个必备项，未来几年更是会被大模型将大量应用场景给重构掉。单列场景告诉大家算法可以在哪里领域中使用，并不是今天的重点，我简单画了上面那张图，给大家一个简单的感知。今天换一个维度聊一下。

我们先把算法岗位分为算法基础设施、算法应用两类。

算法基础设施一般只有顶级大厂、算法领域的公司、科研机构等会养一些团队，有的做算法研究，有的搞框架开发供上层业务算法工程师团队使用，门槛高、工作机会少。而且，因为本身不能给公司挣钱，一旦公司打逆风仗，裁员会先裁这部分团队，可以看看各大厂的AI实验室类似的部门在这两年的表现，有长期价值的事谁都知道很重要，但也得先活下去再说。

所以本文重心放在算法应用上，这个领域提供了市场上绝大多数的算法就业机会。

举个例子，现在市场上各大厂、创业公司把大模型搞得风风火火，但真正去训练大模型的还是少数，最终收敛到少数大型企业、科研机构等，市场上的绝大部分公司、从业人员还是会围绕着大模型的应用创新、商业化挣钱去做事。

实际商业应用场景中，算法对收益达到一定门槛之后，再往上每提升一点效果都会花费巨大的资源，而小公司数据量小，要求也简单，所以小厂的常规做法都是扒个开源项目，能跑起来，做到个七、八成，有点效果就够用了。我曾经面试过一个女生，211硕士毕业之后就在家门口找了个二十个人的小公司，公司就她一个算法工程师，每次遇到新项目就去github上扒代码，改吧改吧跑起来就能出效果，也混了好多年。

在大厂做算法一般都有成熟的平台支撑，专门团队负责平台研发和运维，从数据处理、特征工程、算法开发、模型训练、模型部署到最后变成在线服务对外提供，甚至AB实验、效果分析、模型评价、算法共享等一般都有成熟的平台体系。

毕竟，大厂动不动上游就几百上千个业务场景，每个业务都自建基础设施，成本可就太高了。让业务团队的算法工程师可以专注在分析数据、理解业务、特征处理、调用算法包、开发算法、性能优化、数据挖掘、实验效果这些真正产生业务价值从而给公司挣钱的地方，这样才能最大程度提升效率。

大厂的业务规模大，算法优化带来的每一点微小的提升在庞大的业务基数之上都会创造出巨大规模的效益，比如，抖音的推荐算法每提升1%的点击率、阿里云ECS虚化率提升1%、微信广告匹配效率提升1%，都会给所在公司创造巨额的广告收入。

正因如此，大厂才会花大价钱招聘最聪明地头脑，打造几百、上千算法工程师的团队，一刻不停地在打磨自己各业务场景下的模型，提升再提升，优化再优化，源源不断地把资本转变成智力资源，再转变成公司的竞争优势，最终变为公司的收入。

所以说，只要大大小小的公司公司还要做业务，就会养一批应用算法工程师，围绕着业务不断提升优化，市场行情就不错，工作、高薪都会有。因为业务跟业务之间差异很大，不存在标准的解决方案，必须要拿人来堆。

就业方向上来说，主要以下几类。

CV

OCR：各种场景下的文字提取，如，证照、文档、单据凭证、病历等。

人脸：人证比对、人脸1:N搜索、人脸1:1比对、活体检测、属性检测、宠物识别等等。

图片内容标签：提取特征，Embedding。用于内容推荐、搜索、广告、内容过滤等场景。

医学看片诊断：数据量不大，模型以残差为主。

动作识别：识别跳舞、手势等，以游戏、教育、直播等场景为主。

遥感：军事、农作物、大地遥感检测等。

SLAM

自动驾驶

NLP

ChatGPT出现之后，NLP是否已死？

知识图谱

知识图谱的特点：强约束、强规则、强逻辑。一般来说，我们通过知识图谱来约束模型，实现更可控的AI。

一些常见的应用场景，如：金融风控、搜推广、搜索引擎的语义搜索等。

比如，腾讯音乐搜索推荐时，输入音乐名，会通过知识图谱检索到音乐的演唱者、作曲、作词，并扩展搜索边界。

通过知识图谱给一个人、企业做出更全面的画像，比如，贷款中的征信问题。

隐私计算

机器人

测试工程师

在软件工程中，当一个项目的需求明确之后，就会以需求文档的形式流转到技术团队。技术团队一般包括开发、测试等角色，开发负责搭建工程，通过技术选型、系统分析、技术方案、编码、自测等步骤将需求实现，测试根据需求编写测试用例，或者通过少量的编程做白盒测试，或者通过人工做黑盒测试，最终负责保障项目的上线质量。

以前我在互联网大厂时，一般开发/测试的人员比例在5～10之间，即，一个20人的开发团队，根据业务复杂程度，配备的测试资源一般2~4个左右。

测试工程师两极分化比较严重，目前中国软件工程领域90%以上的还是属于黑盒测试，优秀的白盒测试工程师很稀缺，一般也就在大厂那些复杂的应用场景中才能培养起来。大部分公司测试岗位的日常工作都是先理解需求，通过Xmind把用例分解清楚，然后人肉跑就可以了。极少数的测试具备编程能力和全局质量&风险视野，从整体业务稳定性的角度来看业务，并通过链路梳理、自动化测试、流程规范等抓手来让项目顺利上线、稳定运行。

像我之前所在的大厂，一般都是一个测试工程师带着几个测试外包负责一条业务的质量工作。测试外包负责黑盒测试，测试工程师负责梳理风险链路、制定项目流程规范、参与重要核心模块的黑盒测试、开发测试工具等。有那比较猛的，甚至每次需求讨论会都可以把PRD中的问题挑得一干二净，为项目的落地执行节省大量的沟通成本。

当然，能力强待遇也会要求的高，白盒测试工程师的薪资水平不一定比同级别的开发工程师低。所以，对大多数中小公司来说，软件质量要求没有那么严格，也不需要这么牛的白盒测试，因为价钱太高了，没有性价比。同样的价钱，可以多招几个黑盒测试了。

就我认识的白盒测试，一般都是毕业进入大厂，在大厂内成长起来的，也一直苟在大厂，或者A大厂跳B大厂。至于像开发那样，在大厂升不上去了跳个小厂降维打击一下的，几乎没有。

开发工程师的培养周期太长了，而黑盒测试占了绝大多数比例的测试工程师则相对容易得多，做上几周就熟了，因此很适合跨专业的人进入计算机技术领域。

12年左右，移动互联网领域急速发展，很多非科班出身的人花上几千块钱参加个培训班，然后就能轻松找份手机App测试的工作。当时我在北京做手机App开发，好些人发现了这样的机会，都去参加培训然后应聘到移动互联网公司做黑盒测试。我周围就有好几对，男生做软件开发，女生以前可能是行政、会计等专业的，毕业后参加几个月的培训就被男生拉到自己公司做测试。沾了互联网普遍高薪的光，那时在北京，即使刚刚入职的测试新手，工资也有七、八千，远高于其它行业。

互联网公司中的测试岗位跟安全岗位很像，做的都是质量、风险类兜底性工作，可能做了大量工作来保障项目稳定运行，这时大家都无感，认为那是正常现象，也是他们应该做的。而一旦有质量问题时，大家的第一反应却是的他们的工作没有做好。

由于工作的重要性往往被忽视，再加上大多数测试岗位的黑盒测试工作比较简单，至少在互联网行业中，运营、产品、开发才是核心角色，测试的重要性往往会被忽略。

在待遇方面，开发岗位一般都是远大于测试岗位的。即使如此，测试工程师的工作强度却比开发工程师低不了多少。互联网行业讲究一个快速迭代、上线试错，研发部门基本上时时刻刻都是满负载运转，一个项目接一个项目的没完没了。如果对口的开发工程师技术水平比较强悍，设计技术方案时逻辑思考全面、自测充分、bug少，那测试可以跟着躺赢。如果开发工程师是个弱鸡，系统处处漏风，自测也不充分，交付到测试手里的项目随使跑跑用例就是一大堆bug，那就要跟着开发一起天天加班追进度了，等到项目上线时也是心惊胆战。

但从影响工作强度最重要的专注度上面，测试的强度比开发还是弱不少的，毕竟不用像开发那样聚精会神地高强度地coding。

服务类工程师

软件行业的服务类工程师，一般都在toB领域。比如，软件研发完毕之后的交付、运维、技术支持等环节，这里分别详细说一说。

拿我们日常接触最多的互联网行业来说，软件研发基本是服务于公司自己的业务，对于服务类工程师的需求极少。但toB领域的大部分软件产品却享受不到这种标准化的舒服姿势，为客户定制是个常态，尤其以面向金融、电信、政务等大客户的最为辛苦。

拿银行来说，限于监管合规的要求，每个银行都要建自己的机房，搞私有云，如果我们做了一个产品卖给银行，就要在软件研发完毕之后部署到银行的私有云（私有机房）中。这中间面临的问题就很多了，单拿数据来说，有的银行数据库使用MySQL，有的用Oracle，有的用OceanBase，甚至的有的部分系统用Oracle部分系统用SQLServer。怎么样把企业内部自研的产品部署到客户机房，让它跑起来呢？交付工程师上场了。

服务类工程师的主要就业方向为：

云计算公司，如，阿里云、华为云、百度云、腾讯云、移动云、天翼云、联通数科等。

软件公司，如，科大讯飞、恒生电子、广联达、金蝶、用友等以售卖PaaS、SaaS产品为主业的软件类公司，或者亚信、思特奇等项目制的软件厂商。

游戏公司，如，腾讯游戏、网易游戏、米哈游等游戏公司。

以下，介绍一下几个主流的服务类工程师岗位：

交付工程师

核心工作就是：驻场，对客，部署，培训。

交付一般发生在私有云项目中。什么是私有云，就是只能在客户内网访问，跟外网不联通，是没法远程安装、部署的。碰上这样的客户，交付工程师就会大量驻场。我曾经在面试中遇到过很多跳槽的小朋友，就是受不了这种长期异地驻场开发的日子，干了两年稍微有点经验就跳槽了。

交付工程师工作一般是：从自己的研发中心拿到打包好的软件，针对客户私有云的环境，如，数据库、注册中心、存储、消息中心等，来调整产品的配置，甚至写一些部署脚本，让产品在客户私有云中跑起来。

交付过程中会涉及到很多需要跟客户沟通的地方，毕竟，软件产品复杂度极高，没法洗发水、手机一样标准化，产品真正做出来的样子和客户的预期一般都会有或多或少的差异，交付工程师一般就会在产品交付到客户那里时做很多沟通工作。客户不懂的要解释，客户理解有偏差的要纠过来，客户没注意的要告诉他。

有些项目还会涉及到与客户的其它供应商打交道，比如，要和其它供应商的软件产品做API对接，或者开放API给客户的其它供应商，需要各供应商一起协同起来完成客户的订单。

产品部署起来之后，还要准备培训资料，给客户单位中那些日常使用软件产品的人做培训，教会他们处理日常工作，解决简单问题。toB软件产品有一个很大的特点就是，采购决定人大概率不是真正日常使用它的人，所以用户的使用体验往往不太好，甚至一些花了钱的政绩功能很少被使用等。

综合来看，交付工程师一个对沟通要求比较高的岗位：哪些话能说哪些不能说？怎么样协同好其它供应商一起完成任务？产品功能不符合客户预期要怎么解释？用户体验不好要怎么处理不引发大规模投诉？

市场上招聘交付工程师的公司以“乙方”为主：可能是那些从甲方客户那里接项目做开发，比如，亚信这类专做运营商定制项目的，也可能是卖技术产品的，比如，数据库厂商。

整体而言，交付工程师也是一个天花板、门槛比较低的岗位，工作3～5年之后，自身的技能就很快达到顶峰，再往后即使经验再丰富，但因为解决的问题价值不够大，对公司来说性价比也不高。反应到现实中就是，社招市场上招聘交付工程师时，很少能开出50万以上的年薪。

运维工程师

刚入行时，我进的是一家百人左右的移动互联网创业公司，研发五、六十个，其中就有一个十人左右的运维团队，日常办公网的管理，服务发布下线，机房的服务器问题处理等都要找他们。

其中一个兄弟是我的老乡，所以聊得比较多一些，他对自己的工作前景充满了信心：未来是互联网时代，每个互联网公司都需要有大规模的机器，这些机器都需要运维。他还和我讲早期百度创建之后流量大增时，有一大堆运维工程师天天拉着小车在机房换硬盘的段子。

后来几年，互联网公司的快速崛起，机器集群规模变大，运维成本上升，就开始了自动化变革，我这个兄弟因为不想写代码，而传统的运维工作坑位变得十分稀少，他就转行去搞别的了。

后来我到了大厂之后，发现软件开发完毕之后不用像在小公司那样人肉发布：编译、打包、登录机器替换、重启。只要新建个迭代分支，提交代码之后，内部的Dev系统会自动触发代码合并、拉分支、编译、部署。在线下环境验证完毕之后，只需要设定好发布策略，在控制台上点几下就可以了。发布过程中，系统会自动监控机器状态，像内存、CPU负载、网络、GC等，有问题随时报警，开发工程师在发布过程中如果发现了严重问题，一键回滚即可。

如果自己系统的流量突然上升了，运维系统上面点几个就可以在几分钟之内扩容大量机器；如果到了业务低谷期，也可以缩容把机器释放掉，为公司节省资源。

有一次我去拜访一家客户，听他们聊每周发一次，每次发一晚上，就给他们讲了我在大厂的devops经验，客户那边的工程师听得羡慕得不得了。

随着云计算的普及，虽然中小企业通过购买云资源来搞业务，不需要关注运维工作，但公共云厂商们使用大规模的集群服务了大量客户，面对这些集群的运维工作变得更多复杂，运维已经变成一个复杂的软件工程问题，比如我提到的，机器的扩缩、容调度，状态监控，网络管控，系统发布、回滚等。

这种环境之下，运维工程师的工作也从直接管理机器、网络，转变为使用这些复杂的系统来管理机器、网络，排查问题，传统意义上“面向机器”工作的运维工程师，岗位定义在不断发生变化，运维工程师的就业领域也就变得越来越狭窄。

就业市场上，提供运维工程师岗位的，一般有这么几类：

1、云计算厂商。因为有大堆模、五花八门的服务集群需要运维，会有大量的运维工程师，甚至面向运维做软件开发的工程师。

2、银行等自建私有云，同时又有大规模研发团队，经常做系统上线处理的单位。比如，各大银行分散在全国各地的数据中心，每年都会通过社招、校招的方式招聘很多运维工程师。因为，监管有规定，银行体系内的研发、上线要职责分开。

3、私企大厂。大厂的devops复杂程度超乎想象，一般都通过一套庞大的系统把研发工程师与底层资源做了隔离。这就需要有一批熟悉这套系统的人来维持运转，俗称SRE。

从职业发展的天花板、门槛角度来说，运维工程师和交付工程师很像，技术深度不足，3、5年达到顶峰，招聘市场上提供的坑位少、高薪坑位数量更少。

技术支持工程师

我们在开发软件时一般会依赖一些二方、三方的软件，比如，华为云、阿里云上的存储服务，百度的AI接口等，如果在按照文档使用这些接口时碰到了问题，就可以在他们的网站上提一个工单，这些云服务厂商就会安排技术支持工程师来联系我们，帮我们解决。

站在云服务厂的角度来看，绝大部分客户在使用时遇到的问题其实都是使用不合理，理解不到位、手误等引起的“低级问题”，并不需要开发这个云服务的软件工程师来解决，毕竟那些工程师的工资太高，让他们投入大量时间来解决这些低级问题有点浪费资源。

所以云服务厂商一般都会设置“技术支持工程师”这个岗位，他们可能并不懂多少代码，也胜任不了复杂的开发工作，但做做日常使用的答疑，检查一些API的调用方式是否正确还是没有问题的。

如果客户抛出来的问题确实比较复杂，或者发现了产品的bug，不是技术支持工程师能解决了的，就会向后抛给研发人员来对客户进行支持，或者发新版的时候解决。

所以，技术支持工程师对技术的要求并不高。但作为解决日常问题、提供一般咨询的岗位，耐心一定要好，一个是因为日常处理的都是一些看起来很傻，客户稍微注意一些就不会犯得错误；再一个客户在把问题提给云服务厂商时，心情一般都不怎么好，大家可以类比一下自己去找微信、淘宝客服时的心情。

一般有技术支持工程师需求的，以乙方公司、技术服务商为主。相比交付、运维来说，这类工程师处理的问题更加简单、琐碎，技术门槛更低。