社招简历评审里有一个很常见的判断这个人写了三年经验但读完之后感觉他第三年做的事和第一年没什么区别。这不一定是事实很多人确实成长了只是简历没写出来。技术简历默认的写法按公司分块每块下面列做过的事天然不擅长表达成长它表达的是「做过什么」不是「变成了什么样的人」。评审者在找什么招一个三年经验的工程师对方想确认的不只是「会写业务代码」还有处理问题的复杂度有没有上升影响范围有没有扩大自己的模块 → 整个服务 → 跨团队有没有从执行给定方案走到参与决定方案遇到过多少种真实故障这几条构成一条曲线。曲线往上走你就是三年经验曲线是平的读起来就是一年重复三次。平铺式写法为什么表达不出曲线看一个典型的写法某某科技 后端开发工程师 2023.07 - 至今 - 负责订单模块的开发与维护 - 参与优惠券系统的开发 - 使用 Redis 优化查询性能 - 参与日常需求迭代与线上问题排查这四条都是真的但它们是并列的、无时序的、没有量级的。读的人无法判断第一条是第一个月做的还是最近做的也看不出难度差别。改法一给经历排序把复杂度高的放前面同一段公司经历里条目顺序不必按时间按重要性和复杂度排。第一条应该是这段经历里你最拿得出手的那件事。多数人的顺序是按记忆顺序写的第一条往往是日常需求迭代这种最没信息量的。而读简历的人给每段经历的注意力是递减的第一条最可能被读完最后一条经常被跳过。改法二把「做了什么」换成「解决了什么问题」- 负责订单模块的开发与维护- 订单超时关闭原用轮询扫表实现单表 800 万行后扫描耗时超过任务间隔导致堆积 改为延迟队列RocketMQ 定时消息 状态机幂等扫表任务下线堆积问题消除第二种写法长但它包含了问题背景、量级、原方案的缺陷、新方案、结果。这一条就能撑一轮追问而且它自带难度读的人能判断这不是新手能做的事。一段经历里有两三条这样的曲线就出来了。剩下的日常工作可以合并成一行带过。改法三显式写出角色变化如果职责真的变过写出来。2023.07 - 2024.06 后端开发订单方向 2024.07 - 至今 后端开发兼任支付链路 owner带 2 名实习生在同一家公司内部的角色演进很多人不写觉得没换公司就没什么可说的。实际上这是最直接的成长证据比任何形容词都有效。改法四把跨越性的东西单独拎出来有些经历不属于任何一段公司经历或者跨越了多段比如主导过一次技术选型写清备选方案和决策依据处理过一次重大线上故障写清现象、定位、止损、复盘产出推动过一项工程规范落地代码规范、CI 流程、监控体系有对外输出技术分享、内部文档、开源贡献、技术博客这几类最能体现「不只是执行者」。如果有可以在项目经历之外单开一小块或者放在最相关的那段公司经历下面加粗。关于故障经历写线上故障是加分的但要写对结构现象 → 定位 → 止损 → 根因 → 长期措施。- 支付回调重复导致订单重复发货日均 3-5 单。 通过对账脚本定位到 MQ 消息未做幂等紧急加唯一索引止损 后续在回调入口统一接入幂等组件并补充对账告警同类问题归零很多人不敢写故障怕暴露自己出过问题。实际上有经验的评审者反过来看没处理过故障的人才是没上过真实战场的人。关键是写出你从中沉淀了什么。别写的几类技术栈罗列越写越长。三年经验的人简历上列 30 个技术名词反而说明没有主线。挑与目标岗位相关的、你能聊深的其余删掉。每段经历都写「负责日常需求开发」。这句话在任何一份后端简历上都成立等于没写。用形容词替代事实。「具备良好的架构设计能力」「较强的问题排查能力」这类判断应该由读的人根据你写的事实得出不该由你自己下。跳槽频繁时的处理三年三家的情况简历上不用解释原因那是面试里的问题但可以在结构上减少疑虑每段经历都写出明确的产出和量化结果让人看到你在每一段里都留下了东西。短于半年的经历如果确实没什么产出可以考虑合并或省略但要注意时间线不能出现无法解释的空白空白比短经历更引人追问。改完整体读一遍改完之后把简历放着隔一天再读只问一个问题读完之后这个人第三年和第一年的差别在哪。答不上来就还得改。顺手也建议扫一遍格式问题。社招简历经历多、条目杂时间格式、公司名写法、技术名词大小写不统一是通病。棱镜简历prismresume.cn/check能把这类问题列成清单一起改掉。最后年限只是一个数字评审者真正读的是曲线。把每段经历里最难的那件事写清楚、按复杂度排好序、把角色变化显式写出来同样的三年读起来完全不是一回事。