同一份简历投大厂和投小厂的效果可能完全不同。原因不是水平问题是两边在找的证据不一样。两个方向各自被怀疑什么大厂转小厂对方担心的是你习惯了完善的基建现成的中间件、发布平台、监控体系到了什么都没有的地方能不能自己搭。你负责的是一个大系统的一小块能不能端到端地扛一个完整的业务。你能不能接受混乱、频繁变化和资源不足。小厂进大厂对方担心的是你的工程规范代码评审、测试覆盖、灰度发布、文档是否达标。你做的系统规模是否够有没有处理过真正的高并发和数据量。你在复杂组织里的协作能力。这两组顾虑决定了简历该强调什么。大厂转小厂要写端到端和从零搭建大厂的简历常见的问题是分工太细写出来像是只做了一个螺丝。改前 - 负责订单中心履约模块的接口开发与维护 - 参与大促期间的稳定性保障这两条在大厂内部流转没问题投小厂时对方看不出你能不能独当一面。改后 - 负责订单履约链路下单后到发货前的 6 个状态流转端到端覆盖设计、开发、灰度、监控与值班。日均处理订单数十万量级峰值 QPS 3800 - 从零搭建了该链路的可观测性原来出问题要翻 4 个服务的日志我定义了统一的 traceId 透传规范并接入链路追踪加了 12 个业务维度的监控看板和 8 条告警规则平均定位时间从 40 分钟降到 8 分钟 - 大促保障提前做容量评估按去年峰值 2.5 倍、压测发现并修复了 3 处瓶颈连接池过小、一处 N1 查询、一个没加缓存的配置查询大促当天零故障改后强调了三件事端到端的责任范围、从零搭建不是用现成的、以及独立完成的完整闭环。如果你确实用的是公司的现成平台也可以写但要写出你的判断和配置能力- 用公司的链路追踪平台接入其中埋点方案和业务维度的定义由我设计12 个维度并根据实际排障需求调整了 3 轮采样策略另外投小厂时要主动展示广度你能不能顺手写点前端、能不能自己部署、懂不懂数据库运维。小公司需要的是一个人顶几摊。小厂进大厂要写规范和规模小厂的简历常见的问题是做了很多但看不出工程质量。改前 - 独立开发公司核心系统负责从需求到上线的全过程 - 使用 Spring Boot、MySQL、Redis 等技术大厂面试官看到「独立开发核心系统」第一反应不是佩服是「规模多大、有没有规范」。改后 - 独立负责交易系统日订单峰值 8 万、数据量 2000 万行级的设计与实现。虽然团队只有 3 人但落地了基本的工程规范所有变更走 PR 至少 1 人评审核心链路单测覆盖率 72%发布走灰度按用户 ID 取模分 3 批并保留一键回滚 - 分库分表方案订单表按用户 ID 分 8 库 16 表用影子表 双写做了 3 周迁移验证切流分 4 批全程无数据不一致 - 建立了值班和故障复盘机制每次线上问题产出复盘文档时间线、根因、改进项、负责人累计 14 份其中 9 个改进项已落地改后回答了大厂关心的每一点规模有数字、规范有具体做法、迁移有风险控制、有复盘机制。注意「虽然团队只有 3 人但」这个结构。它主动承认了规模劣势然后用具体做法证明工程素养不受团队规模限制。这比回避更有说服力。要换的三处第一处经历描述的抽取角度。同一段经历投小厂抽「端到端、从零搭建、一人多能」投大厂抽「规模、规范、风险控制」。第二处技能栏的排序和内容。投小厂把广度放前面后端 部署 数据库运维 一点前端显示你能顶多个位置。投大厂把深度放前面某个方向的深入程度并且补上工程规范相关的内容。第三处项目经历的选择。投小厂优先放你独立完成的、有完整闭环的项目。投大厂优先放规模最大、复杂度最高的那个哪怕你只负责其中一块。关于公司知名度小厂的人常担心公司没名气。处理方式是给公司加一个定位说明某某科技B 轮某某垂直领域约 80 人 后端开发工程师 2023.03 - 2025.09一行括注让读的人知道这是什么量级的公司、在做什么。没有这行对方对一个陌生的公司名没有任何概念。大厂的人反过来要注意不要以为写了公司名就够了。你在大厂里做的是什么量级的事仍然需要数字说明。同一家大厂里的不同团队差别极大。一件两边都要做的事不管哪个方向都要准备好回答「为什么想换」。从大厂到小厂说你想要什么更完整的业务闭环、更快的决策、更直接的影响不要说大厂不好。从小厂到大厂说你想要什么更大的规模带来的技术挑战、更完善的工程体系、更深的专业方向不要说小厂不好。两边都别说前东家的坏话这是通用规则。最后同一段经历有多个抽取角度这是简历优化里成本最低、收益最高的一件事。它不需要你新增任何经历只需要换一个侧重点重写。