实习不包装等于没实习?怎么合理包装实习经历?

对于大部分开发实习的同学来说,这应该深有体会。面试的时候,什么高并发、高性能、高可用,那是张嘴就来,但实际实习的时候才发现,哪会让你接触这些东西哦。可能理解业务就要理解一个月,然后前端做做切图,样式调整啥的,后端做做CRUD啥的。这样糊糊涂涂实习3个月准备秋招的时候,发现面试官都不知道该问你些什么,你自己也不知道该回答些什么。而有些同学知道要包装,但是可能用力过猛,导致面试稍微问深一点,就露馅了。所以合理包装自己的实习经历是必需的,那具体怎么样合理包装自己的实习经历呢?下面是具体的一些技巧:

1.把“做了什么”翻译成“解决了什么问题”

改重复出现的小bug:可以总结成“优化XX模块异常处理逻辑,通过新增校验规则减少80%同类报错,提升接口稳定性”。

调前端后端对接的接口:别只说“调通了接口”,而是“参与XX功能模块的前后端联调,梳理接口文档30+份,推动解决跨端数据格式不一致问题,缩短联调周期2天”。

写单测就可以说成,“建立单元测试规范,覆盖核心模块,拦截了2次回归bug”

甚至配环境,写文档,也可以说成 “搭建标准化开发环境文档,将新人上手时间从2天压缩到4小时”

2.重复劳动并把它自动化,那就是产出

之前在小厂实习的时候发现团队每次发版都要手动执行一串命令:打包、上传、重启。干了三次之后我觉得太傻了,花了两天写了个一键部署脚本。

这个脚本很简单,就30行shell。但我把它变成了一个小项目:

  • 加了日志输出,能看到每一步执行状态
  • 加了回滚功能,万一有问题能秒级恢复
  • 写了个README,教同事怎么用

后来整个小组都用上了,我的mentor还在组会上说我“XX做的小工具挺好用”。

杂事和产出的分界线就在这儿:你只是执行,那就是杂事;你发现了重复劳动并把它自动化,那就是产出。

3.没数据?那就制造对比场景

有没有发现面试官最喜欢问“效果怎么样”。但打杂的活哪来的QPS、耗时数据?

我的办法是:没有绝对数据,就做相对对比

比如我优化了一个慢接口,上线前没压测环境拿不到QPS数据。我就做了两件事:

  1. 本地用JMeter简单压了一下,记录“优化前300ms → 优化后120ms”
  2. 上线后观察了三天监控,记录“上线后零故障,日均调用量涨了20%没报警”

数据不一定非要来自专业压测平台。你自己对比的结果、上线后观察到的现象,只要是真实的,面试官就会认

最后,我想说的是,包装的本质是要能自圆其说(别瞎编你没做过的东西,很容易露馅的),而是“升维思考,降维表达”,能讲清楚“我做了什么、怎么思考的、学到了什么”,这比单纯的“高大上”技术更重要。因为之后面试的时候面试官更多的也是看重你的潜力:能不能把小事干好(干出流程、干出规范),有没有主动思考的意识等等,你要做的就是尽量用自己的经历给面试官展现出自己具有这样的能力。

加油,你一定能转正,秋招一定会有好结果的!

#互联网大厂##实习包装##实习##实习如何「偷」产出?#
全部评论
30行部署脚本真能抄 这思路顶
1 回复 分享
发布于 05-28 14:43 山东
纯CRUD三个月看面经心慌
点赞 回复 分享
发布于 05-28 12:45 广东
点赞 回复 分享
发布于 05-26 13:35 北京

相关推荐

在我来鹅之后,接到的第一个完整大需求就是需要编写一个skill,之前的实习也写过一些skill,但是在我的理解中skill就是跟提示词没差,把你需要的目标全写上就好了,所以第一次mr我提交了一个超过1200行的md,被mt打了回去,为了完成这个需求,我又赶紧请教了我身边的大神同学,获取一些写skill的经验,将原先1200行的md进行了对应的references拆封,又通过我朋友教我的验证机制验证这个skill的效果,最后完成了我的第一个需求。正好前两篇文章给大家分享了写好的用来包装简历的skill,那么今天来给大家分享怎么去写一个好的,可以实际用来工作的skill,摆脱只会写提示词的尴尬。构建 Skill 的五个步骤Step 0:先写 EvalsEval(Evaluation,评估)是一套结构化的、可重复运行的测试用例集,用来判断 Skill 的表现是否符合预期。它不是泛指"测试一下",而是开发 Skill 的前提条件。一个典型的 Skill eval 集至少包含三类用例:- 正例(Positive):用户说“帮我看一下这个 PR 能不能合”,验证 Skill 应该被加载- 负例(Negative):用户说“帮我把代码格式化一下”,验证 Skill 不该被加载——路由别跑偏到不该触发的地方- 边界(Edge):“这个 PR 改了一行日志,要不要审”,验证边界情况下的路由行为正例和负例都要写,而且负例往往比正例更值钱——误触发是 Skill 路由的头号失败模式。Eval 不只是测一次。Perplexity 的 eval 分三个层次:如下图每种都要在 GPT、Claude Opus、Claude Sonnet 不同的 orchestration 模型上分别跑——Sonnet 和 GPT 的 Skill 行为差异很大,只在一种模型上过了不够。没有 evals,你改 description 就是在盲改,一个新 Skill 也可能悄悄搞坏已有的十个 Skill。Step 1:写 Description(最难的一行)description 是路由触发器,不是文档。写好它不需要关心 Skill 的内容,只需要关心能不能在正确的时间加载、有没有意外触发到不应该触发的地方——误触发是头号失败模式,每加一个 Skill 都有可能让其他 Skill 变差。糟糕的 description 描述 Skill 做什么,好的 description 说什么时候加载。举个监控 PR 的例子:不要写这个 Skill 做什么,要写工程师感到焦虑时会说什么——"babysit"、"watch CI"、"make sure this lands"。快速检查清单:- 以"Load when…"开头- 控制在 50 词以内- 描述用户意图,最好来自真实查询- 不总结工作流程Step 2:写 Body跟同事讲工作流程和跟 LLM 讲工作流程完全是两回事。对几乎任何面世超过一年的软件工具,只要提名字,模型已经知道怎么用。所以跳过模型已经懂的部分。不用写出每一步命令。比如不要写 git log → git checkout main → git checkout -b clean-branch → git cherry-pick commit。写 "Cherry-pick the commit onto a clean branch. Resolve conflicts preserving intent. If it can't land cleanly, explain why." 模型在后者上表现好得多,尤其是事情不按预期走的时候。太规定的指令比灵活的指令更脆弱。然后聚焦 gotchas 和反例,它们是最高信噪比的内容。每次 Agent 搞砸了就加一条,gotcha 会自然地累积起来。条件逻辑或内容太重的东西移出 SKILL.md,放到 accessory file 里渐进加载。Step 3:用层级结构- scripts/ —— 确定性逻辑,模型不用每次重新发明- references/ —— 重型文档,条件触发才读("如果 API 返回非 200,读 api-errors.md")- assets/ —— 输出模板,模型直接复制填充- config.json —— 首次运行设置,问一次保存下来对于极其复杂的 Skill,进一步考虑是否应该拆成一组 Skill,用 depends: 声明加载关系。Step 4:迭代切分支出来,在无 Skill 的状态下跑 hero query(核心用户场景查询),建 eval 集,反复调。提交 review 时最好一个 changeset 里自带 eval 集。Description 里的小词改动对路由影响很大,甚至会 spillover(溢出)到其他 Skill,所以这些在 Step 5 之前做完。Step 5:发布大家快把这5步实行起来,成为写skill专家吧!
琉璃梦忆:直接skill creator 管你这那的
AI了,我在打一种很新的...
点赞 评论 收藏
分享
做梦也会成功的:真是Token比人贵
点赞 评论 收藏
分享
评论
11
54
分享

创作者周榜

更多
牛客网
牛客网在线编程
牛客网题解
牛客企业服务