美团食杂零售

转眼已经实习两个月啦！现在已经逐渐熟悉工作内容，也对一些小任务手拿把掐啦！组里的氛围真的很好！mentor非常有耐心，最近在跟一个完整的小项目，完成了一些些工作，还是非常有成就感滴！从图片上能看出我把自己的工位装扮的很漂亮吧！最近打算去健身房练一练！三伏天又准备重启我的健身计划啦！如果食堂的饭能再便宜点的话那就完美啦！

入职开水团成为产品校招生已经快小半年，复盘这段高强度成长期，深刻体会到学生思维与职场要求的鸿沟，作为新人难免经历认知重构的阵痛期。因此记录一下我landing期间踩过的各种坑，供各位牛油参考：⚠️新人经常踩坑的场景1️⃣ 畏惧跨部门沟通：常常在群聊里文字讨论三小时未达成共识，实际拉会/线下见面五分钟解决——因对直接交流/沟通有畏难心理，陷入低效文字拉锯；2️⃣ 需求理解错位：交付任务时发现与mentor预期南辕北辙，返工成本远超执行时间；3️⃣ 事项处理延迟：因惧怕打扰忙碌的mentor搁置待办，反而引发协作方投诉。……✍️ 我的经验第一，沟通讲效率。能当面聊就别打字，几句话能说清的事，文字掰扯半天还容易误会。被质疑时，会直接问“现在方便对一下吗？”快速对齐。自己对接需求前，一定先想透：为什么改？核心步骤是什么？可能被问什么？心里有谱才能讲明白。第二，接活要问透。收到任务别光记，立刻搞清楚：谁要结果？做成什么样？哪天要？不确定就直接问：“我理解是...对吗？”比如给设计的文档要讲清界面怎么交互，给开发的得说明功能逻辑。执行中紧盯关键结论和时间点，重要共识当场文字确认（比如“结论：采用方案B，@张三周三前提交文档”），有风险早汇报（“进度落后了，卡在X点，可能延期”）。 工作留痕方法论可见主包之前分享的《📒校招生血泪第一课：工作留痕，保护自己！》第三，求助有方法。Menter忙，但该问还得问。关键是自己先理清：现状是啥？卡在哪？试过啥办法？再去问：“现在情况是X，问题出在Y，您看下一步怎么走？”简单问题多问同批实习生或组里年轻同事，吃饭闲聊时就能解决。核心就一条：把事情想在前头，信息理清楚，沟通抓重点。踩坑不可怕，犯错永远是新人最快的成长路径。

作为刚刚加入开水团的校招新人，我对自己的预期是希望建立“靠谱”的人设：暂时做不出创新的内容，至少能够让老板放心把项目交给我。通过和职场前辈不断交流以及我的观察，培养良好的职场习惯，并通过刻意练习内化于心是很重要的：1️⃣ 习惯一：任务确认闭环管理面对线上任务：即时回复“收到”，并给出预计交付的时间节点；面对当面指派的任务：边听边记录要点，结束时要复述关键点确认：“我理解需要做A、B、C，重点在X，下周三提交，对吗？”确保自己理解交付程度，同时也要将这一任务落在笔头，确保双方对于任务的理解在同一水平线。2️⃣ 习惯二：交付清晰易懂的成果提交文档前，换位思考：关键信息是否高亮？逻辑是否一目了然？标注是否充分？确保他人无需反复询问即可理解核心内容。3️⃣ 习惯三： 带着方案解决问题遇阻时，先尝试自主解决。汇报时简明阐述问题本质，并提供至少两个可行方案及建议，让Leader做选择题而非问答题。4️⃣ 习惯四：关键过程必留痕养成记录习惯：会议结论、重要沟通、决策依据及时书面存档（邮件/群聊/文档）。既是复盘依据，也是厘清责任边界的保障。5️⃣ 习惯五：理性对待反馈与修正这一点我目前做的也不好，但在努力往这个方向做到。被指出不足时，专注要点：“明白，重点在X和Y，我立即调整，后续会注意Z点。” 避免辩解或情绪化，将反馈视为优化机会。

这个星期转正系统开放了，我的实习时长达到了60天，这个星期也认真复盘了一下在美团实习这段时间的工作内容、收获以及对未来的规划……在复盘的过程中也逐渐回忆起来自己做的有进步的地方以及未来需要改进的地方，人生只有成功和成长，希望未来继续努力！在转正系统上完成自评后就会按顺序流转到主管以及再上级主管，后续流程大约要几周。最后祝大家一切顺利！

你是一个幸运儿，你过五关斩六将，拿到了大厂实习offer。你对性能优化了如指掌，你对锁和高并发倒背如流。你怀揣着满满的业务理解，希望在未来的几个月大展宏图。你的mentor经验丰富，组内的业务朝气蓬勃。你接到了第一个需求（怀揣着激动），你以为是设计xxx模块，优化xxx接口，定睛一看——为xxx功能编写单测！……开个玩笑，其实单测没那么可怕，它早已成为每个实习生入职的“必修课”。在大厂项目中，单元测试往往是新手最早接触、也最容易上手的一部分工作。原因主要有下面几点：一方面，大厂的项目庞大复杂，服务动辄数十个模块联动，启动一次应用可能就需要几分钟，甚至还要拉起一整套依赖服务。如果每改一行代码都靠本地全量启动来验证功能，不仅效率低下，还极容易被各种依赖卡住；另一方面，一个功能在真实环境中往往依赖多个组件，比如远程服务调用、消息中间件、定时任务调度、数据库读写等，很多逻辑在本地调试阶段难以构造出完整链路。这时候，单元测试就像是一把“放大镜”+“模拟器”，让开发者可以聚焦在某一个方法、某一个功能点上，通过精心构造输入、模拟依赖、验证输出，快速高效地完成逻辑验证。还有一点，这一点和我们相关性较强——借助单元测试可以帮我们更好的熟悉相关链路，因为实际在编写单元测试的时候你就会发现，不熟悉代码逻辑，单测就只能依靠伟大的ai大人了——你还得为对错战战兢兢。单测介绍单测，全称单元测试，就是对代码中的最小功能单元——通常是类或方法——进行测试，确保它们在各种输入条件下都能得到正确的输出。与集成测试不同，单测给我最大的感觉是隔离环境和快速见效。通过使用模拟对象（如 Mockito ）、断言库、Junit等框架，开发者可以非常精细地验证一个方法在特定边界条件、异常路径、依赖出错等场景下的行为。举个例子：一个订单处理函数可能依赖库存服务和用户服务，如果每次测试都要先确保库存服务可用、用户服务响应正常，测试效率将大打折扣；但用单测，你可以通过 mock 技术让库存服务“假装返回库存充足”，让用户服务“假装认证成功”，你要测的只剩核心业务逻辑本身。指导原则自动、独立、可重复执行边界值测试、正确的输入、与设计文档结合、强制错误信息输入（输入非法数据，得到预期的结果）哪些需要编写单测1. 底层模块，出了问题难以察觉，影响很广2. 自动化和手工测试成本高，难以模拟边界条件3. 重逻辑和规则的计算，而非流程编排和模块组装注意：一切跨类跨系统的测试都不是单元测试ps：实习以来，靠着单测多次查出潜在的bug（lz用的是mockito库），现在已经完全适应手写单测了