工作内容和工作贡献首先要把自己实习期间参与的具体业务说清楚, 虽然说hr不懂技术,但是他们明白组里的业务是什么, 招聘时对于有类似业务经验的候选人肯定更受青睐(比如财务相关)其次,还要把自己的工作贡献表达出来, 这里可有的说了, 除了大佬,大家去实习一般都是做dirty work, 但是很多东西是可以争取的, 比如组里其他人做的专项, 叫声哥/姐,请吃个饭, 让人家教你这个东西, 这样你在面试的时候就能"吹了"关于测试实习, 工作贡献主要分为两部分, 第一部分是"共设计xxx条测试用例, 覆盖xxx模块, 无P0bug......", "实现UI/接口自动化, 提效xxx%", 此外, 还可以关注公司内部的"自动化平台", 虽然这个平台不是你写的, 但是你能把原理和技术架构说明白, 这也是能作为个人优势的写到这其实觉得"个人思考"是非常重要的一点, 就像我秋招面试时, 简历上写了一个贡献, 虽然在我实习期间根本就没参与过, 可我利用周末看知识库,看demo,搞懂了那个贡献, 因为最开始实习的时候真的很轻松, 我觉得不能这样下去, 有一次开会的时候看到一位同事分享了, 当时我就觉得可以借鉴学习一下, 后面在秋招也发挥了很大的作用

提完需求干一半反悔；实习生请一天假不给批，美名曰奉献；正常点下班阴阳怪气为什么走这么早。

现在回想起来，MT 说过最让我开窍的一句话，至今还影响着我的工作方式 ——“你不能只按照我的方案写代码，而是要自己理解做了什么事，涉及哪些模块”。刚实习那会，我满脑子都是 “赶紧完成任务”，完全没意识到理解业务的重要性。每次 MT 把方案发过来，里面会写清楚需求背景、业务逻辑，还有具体的代码修改点。我嫌看长篇大论太费时间，总是直接跳过前面的方案说明，直奔代码修改部分，照着标注的 “改这里、加那段” 机械操作。代码改完很快，可一到测试环节就傻眼了 —— 我根本不知道这段代码对应的是什么功能，要测哪些场景，甚至连为什么要这么改都不清楚。只能跑去问 MT “这个要怎么测”“边界条件有哪些”，次数多了，MT 大概也摸清了我的套路。有一次我又去问测试相关的问题，他没直接回答，反而说了那句让我茅塞顿开的话。那一刻我突然反应过来：我这样跟个 “代码机器” 有什么区别？只知道机械地修改代码，不懂背后的业务逻辑，不明白模块之间的关联，就算做得再快，也只是重复劳动。现在 AI 那么发达，这种不用动脑子的改代码工作，迟早会被替代。从那以后，我拿到方案再也不敢敷衍了。先花半小时到一小时，把需求背景、涉及的业务模块、上下游关联都理清楚 —— 比如这个功能是给哪个角色用的，解决了什么业务痛点，修改的代码会影响到哪些接口。理解透了之后再动手写代码，不仅思路更清晰，测试的时候也能精准覆盖各种场景，不用再反复问 MT。慢慢发现，懂业务和不懂业务的差距真的很大。懂业务后，写代码时会主动考虑潜在风险，甚至能提出更优的实现方案；遇到问题时，也能快速定位到是业务逻辑问题还是代码问题。这句话不仅让我改掉了浮躁的工作习惯，更让我明白：打工人的核心竞争力从来不是 “会写代码”，而是 “懂业务、能解决实际问题”，只有这样，才能在行业里走得更稳、更远。