这类经历有个尴尬的位置：写了像凑数，不写又觉得少了一块。「指导新人成长，参与团队代码 review，多次进行技术分享」，这一行几乎每份三年以上的简历都有，评审者也几乎都会跳过。
先说评审者的真实判断：非编码贡献在两种情况下有价值，一是目标岗位有带人预期，二是它能证明你对代码质量有自己的标准。其他情况下它是背景噪音。
什么级别该写
一到两年：不写，或者只在项目条目里带一句「该模块的 review 由我主导」。这个阶段写「指导新人」会显得错位，读者会想你自己是不是刚被指导完。
三到五年，高级工程师：该写，但要写成具体动作和结果，不写头衔。这是这类内容最有区分度的阶段。一个粗略的比例：技术条目占八成，非编码贡献占两成，超过这个比例就要想想是不是在凑数。
Leader 或架构：必写，而且要有规模和机制，几个人、什么流程、什么产出。这个级别不写等于没做过。
三类经历各有一个硬指标
带新人：带了几个、多久能独立接需求、你做了什么具体动作。「耐心指导」不是动作，「设计了三周的入门任务链」「每周一次一对一走查代码」才是。
Code review：不写「参与」，写你在 review 里建立了什么规则、拦下过什么类型的问题、量级多大。review 是最容易写虚的一项，因为人人都在参与。
技术分享：主题、听众范围、有没有落地。分享完团队改了什么，是唯一能证明分享有价值的指标。没有落地的内部分享，一句带过或者不写。
改一条看
改前：
- 指导新人成长，参与团队代码 review，多次进行技术分享改后：
- 带 2 名校招生：设计了 3 周入门任务链（从补单元测试到独立交付一个接口），两人分别在第 5 周和第 6 周开始独立接需求 - 团队 review 固定成员（约 40 个 PR/月）；推动两条规则进 PR 模板：涉及 DB 变更必须附执行计划、超过 400 行必须拆； 实施后 PR 平均改动从 600 行降到 250 行，review 平均等待从 2 天缩到半天 - 内部分享「线上 OOM 排查」后，团队把 heap dump 自动落盘加进了容器启动参数，此后 3 次 OOM 均在 1 小时内定位改后每一条都有数字，每一条都能追问，而且三条的结构一致：做了什么具体的事，产生了什么可观察的变化。
数字从哪来
review 的量级可以从 PR 列表里数出来；PR 平均行数、等待时长这类指标，代码托管平台的统计页面直接有；带新人「第几周独立接需求」，看他第一个独立提交的 PR 日期。这些数字对方是可以核的，按真实数据写，不要凑整，也不要挑最好看的那个月。
面试会怎么追问
带新人：他后来怎么样了。这题的重点不是新人的去向，是你怎么判断他「上手了」，判断标准说得出来才算真带过。
Review：你拦过最有价值的一个 PR 是什么。答不出具体案例，「固定成员」这四个字就站不住。
分享：如果我现在问你那个主题的一个细节，你能答吗。分享过的主题等于你在简历上主动开放的考点。
三个追问有一个共同点：问的都是结果，不是态度。
放在哪
不要单开一个「其他」或「团队贡献」栏。放在对应那段公司经历的最后一两条，紧跟着技术条目。Leader 岗可以在经历标题下面第一条就写团队规模和职责范围，因为那是岗位的核心信息。其他岗位一律技术条目在前，非编码贡献在后。
写了会有副作用的情况
投纯 IC 岗，尤其是专家型岗位，带人经历写太多会让对方怀疑你还想不想写代码。这时只保留 review 那一条，它证明的是你的代码标准，不是管理意愿。
反过来，投 leader 岗只写技术条目、不写任何带人机制，对方会怀疑你有没有真做过这个角色。
几种不该写的
「乐于分享」「团队协作能力强」，形容词不是经历。「培训新员工」但实际只是发了一份文档。「组织团建」。「参与 review」而没有任何量级或规则。这些写进去不加分，占的是本可以放技术细节的行。
改完可以整份过一遍格式。非编码贡献和技术条目混排后，条目结构和标点最容易不统一。
最后
非编码贡献的写法和技术条目是同一套标准：具体动作、可观察的变化、能撑住追问。达到这个标准就写，达不到就不写，中间没有「先写上再说」的选项。
