看到阿里云招募的消息，很多人的第一反应是先投再说。投之前花十分钟想清楚两件事，通常比海投更省力：自己适合哪类岗位，以及简历怎么写，才能让招聘方在扫一眼的时间里抓到重点。下面从岗位理解、两个示例、简历写法和面试准备几个方面说一下。
先看清楚岗位在招什么人
云计算公司的岗位差别很大。写代码的研发、画架构图的解决方案工程师、帮客户把系统跑起来的技术支持和售前，要的能力几乎不重合。如果把三类岗位的材料混在一起准备，多半两边都不讨好。
大致可以这样区分：
- 研发类：看编程基础、数据结构和分布式系统原理，最好有某个方向（数据库、容器、网络或存储）的深入经历。
- 解决方案与架构类：要能把客户的业务问题拆开，再对应到云上的具体方案，技术和业务都要懂一点。
- 技术支持与运维类：排障能力、对操作系统和网络的熟悉程度最直接，能把问题讲清楚也很加分。
投递前打开官方招聘页面，把每个职位的任职要求逐条对一遍。很多人跳过这一步，简历里写的内容和岗位要的东西对不上，再好的经历也没人看到。
两个示例
下面两个例子是虚构的，用来说明思路，不对应任何真实人物。
示例一：从普通后端转向云原生
假设小林在电商公司维护订单系统，简历上只写了“熟悉 Java 和 MySQL”，投了几家都没有回音。他对云原生有兴趣，却没有把这部分经历写出来。
更好的写法是把订单系统迁移到容器环境的过程单独列出来，写清楚迁移前后的性能变化，以及过程中遇到的问题和解决方式。如果他还写过一次 Kubernetes 扩缩容的排查笔记，也可以附上链接。面试官通常关心的是他怎么定位问题，名词列表反而没那么重要。
示例二：从运维转向解决方案岗
假设阿杰做了五年机房和网络运维，技术基础扎实，但第一次面试时逐条讲技术细节，面试官听完仍然不清楚他能为客户做什么。
第二次准备时，他挑了一个帮客户把本地服务迁到云上的项目，按“客户原来的问题、方案选择、上线后的效果”三步来讲。技术细节还在，只是放进了每一步的理由里。这样讲，判断力就看得出来，他也顺利进了下一轮。
简历怎么写
技术岗的简历通常只会被快速扫过，下面几处改动见效比较快：
- 项目经历尽量写结果和数字。“优化了查询性能”信息量很少，“把某个接口的平均响应时间从 800 毫秒降到 200 毫秒”才会让人追问。数字要是真实的，面试时就得能讲出测量方法。
- 技术栈跟着岗位走。投研发就把语言和系统设计放前面，投解决方案就把客户场景和沟通经历放前面，同一段经历可以换一种写法。
- 名词别堆太多。罗列二十个技术名词，面试官随便问一个用法就露馅，不如挑三四个讲深。
- 开源项目、技术博客、竞赛都可以写，但要写清自己负责的部分，只写“参与”几乎没有分量。
面试准备的顺序
技术面一般先问基础，再往具体场景里追。比较稳的准备顺序是：先把自己做过的项目讲透，包括背景、难点、取舍和复盘；再把网络协议、操作系统调度、数据库索引这些基础过一遍；最后做几道和岗位相关的题，练习在压力下把思路讲清楚。
行为面同样要准备。面试官想知道你和同事意见不一致时怎么处理，项目失败后怎么复盘。提前备两三个真实经历，用“情境、行动、结果”的结构讲出来，比临场编一个可靠得多。
几个常见失误
- 简历千篇一律，同一份材料投所有岗位，结果哪边都不匹配。
- 只看岗位名称，不看职责描述，投递方向就容易偏。
- 面试时太紧张，回答只剩一个词。遇到不会的题，把自己的思考过程说出来，面试官通常会看这一点。
阿里云招募这类机会，最先要打磨的是简历和项目讲述。先把做过什么、为什么这么做、结果怎样说清楚，再挑和自己对得上的岗位投，通常比投得多更有效。
