这半年我带了两个批次共23个实习生，研发部14个，产品部9个。最后转正19人，转正率82.6%。剩下的4个里，有2个是主动请辞，1个能力不匹配，1个是态度问题被我打了不通过。你可能会说这个率还行，但说实话，转正只是个开始——这19人入职后三个月内绩效达标的有18人，达标率94.7%，目前还没有被劝退的。这个结果比我预期的要好一点，但距离我理想中的“每个转正的人都能独当一面”还有差距。
整个评审过程中，我自己也踩了几个坑，有些是方法上的，有些是判断上的。下面挑几个重点说说。
一、数据模型跑通了，但别迷信它
我一开始搭的那套KPI雷达图，覆盖代码提交质量、需求理解偏差率、跨部门协作时效三个维度，每个维度分5级。看着挺科学，跑了两批之后发现一个问题：它对“慢热型”选手不公平。
举个具体的例子。3月份进来的小陈，头两周代码CR通过率只有63%，偏差率34%，按模型打分是C档。但我翻了git记录，发现他每天的提交次数少，但每次commit message写得非常清楚，单元测试覆盖率也在慢慢涨。这不是偷懒，是他之前在上一家实习的公司养成了“想清楚了再动键盘”的习惯。我跟mentor说，把他第三周的数据加权调高一些试试。结果第三周他连续三天解决了两个积累已久的编译警告，CR通过率直接跳到89%。最后他以84分转正，现在在支付组，上个月还评上了月度之星。
反过来，也有被数据“欺骗”的时候。另一个实习生小刘，前两周数据漂亮得很，CR通过率92%，返工次数0。我挺看好他，但到了第三周的场景压力测试，客户那边模拟了一个配置中心突然挂掉的故障，他直接懵了，第一反应是“等运维来修”，而不是自己去查本地缓存或者降级方案。后来我查他前两周的周报，发现他从不写“踩坑记录”，所有的任务描述都是“已完成”。说白了，他只做自己会的，遇到陌生的东西就绕道走。这件事之后，我在雷达图里加了一个“陌生场景应对次数”的观察项，不直接打分，但作为评审时的必问项。
二、场景压力测试那天的真实情况
网上很多文章把压力测试写得很热血，我这儿说点实在的。
7月份第二批评审，我提前跟客户方的关系比较好的一个技术经理打了招呼，请他帮忙打个突袭电话，就说“我们线上有个接口延迟飙高了，你们谁来看看”。电话是下午两点打过来的，我当时正在会议室里跟三个实习生过方案。我没避着他们，直接开了免提。
对方讲了大概一分钟的业务背景和现象，然后我回头看三个人的反应。一个男生马上打开电脑看监控大盘，另一个女生（就是后来转正的那个林晓）掏出本子开始画调用链，第三个实习生一直盯着我问“是不是我们这边的问题”，明显是想推责任。说实话，当时我心里就已经有数了。
后来林晓花了四分钟画出调用链，指着下游的一个推荐SDK说：“这个SDK我们上周升过版本，release note里写了默认连接池从20改成了5，会不会是这里？”她接着问了一句很关键的话：“客户那边的QPS大概是多少？”对方说峰值得有300。她马上算了一下——5个连接，每个连接平均响应50ms，理论QPS只有100，确实不够。
这个排查思路虽然不是她独立代码修复，但方向完全正确。后来我们按这个改了配置，问题就解决了。我当场记了一笔：这个女生脑子里有“容量规划”的概念。这种能力你光看代码提交是看不出来的。
三、一个没转正的真实案例
前面提到那个态度问题被我打不通过的实习生，也值得说一说。他叫小周，本科学校不错，技术底子也好，前两周代码量排第一。但他有三件事让我下了决心。
第一次是第三周的晨会，他迟到了15分钟，理由是“昨晚写代码太晚，闹钟没听到”。我当时没说什么，只是提醒了他。第二次是跨部门协作打分，产品经理反馈说给他提的需求文档他根本不看，直接按自己理解写代码，导致三个接口字段名跟PRD不一致。产品那边改了两版文案，他一句“我觉得原来的更好”就给否了。第三次最严重——他私自把测试环境的一个配置改成了线上值，导致下游依赖的mock服务挂了两个小时。事后问他为什么要改，他说“我想验证一下性能，懒得走流程”。
-
✹好拿网hn373.cOM精品手册:
- 年度个人总结2026 | 2026年度个人总结 | 教师个人评审述职报告 | 年终工作总结2026 | 实习评审个人总结 | 实习评审个人总结
那次我跟他谈了四十分钟，我说技术可以练，但规则意识和对团队的基本尊重不能等。最终评审我没给通过。后来他去了另一家公司，听说干得还可以，可能我这边管的确实严了点。但我不后悔。
四、我自己踩的两个坑
第一个坑：太相信初始数据，对非技术岗的实习生缺乏耐心。4月份有个运营方向的实习生小杨，前两周的数据很一般，用户访谈整理的速度慢，分析报告也写得平平。我差点打了C。后来产品总监跟我说，小杨每次整理录音时会把用户的原话逐字逐句写下来，还标注了情绪变化，这东西虽然花时间，但对后续做用户画像非常有价值。我重新翻了他的工作产出，发现确实如此。后来我给了B+，他转正后做的用户痛点分析，直接帮我们改了两个功能入口。我现在给自己定了个规矩：评审非技术岗之前，必须先看一遍他们做的所有“脏活累活”，不能只看表面KPI。
第二个坑：评审周期太依赖前三周的滑动平均，对“爆发型”选手反应迟钝。8月份有一个实习生，前两周数据都是C档，第三周突然拿出了一整套性能压测脚本，还把之前没人管的几个慢SQL优化了。等我的模型反应过来，离评审结束只剩两天，很多细项已经来不及补测了。下个季度我会把评审拆成“初评+中评+终评”三段，每两周做一次轻量复盘，不等到最后再算总账。
五、下半年打算做的事
一是把离职后三个月的跟踪数据也拉进来，看看我们的评审到底有没有预测力。二是建一个内部案例库，把那些“踩坑-解决-经验”脱敏后归档，供后面的实习生参考。最后一个是双向评估——让实习生匿名给mentor和评审组打分，我承诺如果平均分低于80，我当着全组做一次公开复盘。
写这份总结的时候，我想起年初评审开始前，我工位上贴了一张便利贴：“你评的不是分数，是他们第一份工作的起跑线。”现在回头看看，有欣慰，也有遗憾。但至少数据没有说谎，案例摆在那里，下一次我能做得更好。
-
为了您方便浏览更多的工作总结网内容，请访问工作总结