一年前，我接了个大厂外包的 offer。当时身边朋友的反应出奇一致：“外包？能转正吗？”“不就是去大厂打杂吗？”“干两年出来简历怎么写？” 说实话，我自己也犹豫过。但那时候手里没更好的选择，咬咬牙，去了。 一年后的今天，我想说点不一样的。

第一印象：原来外包也能碰核心代码入职前我以为外包就是写点边角料，真正进去才发现——我直接进了某个中台业务组，写的是线上核心链路。 当然，权限确实有差别。我不能直接部署生产环境，某些内部文档需要申请才能看，周会不能主动发言。但代码，是真的在写。 第一个月我接手了一个老旧模块，里面全是祖传代码，没有注释的那种。我硬着头皮重构了一版，提了个 PR，leader 给了十几条评论，每条都写得很细：“这里为什么要用这个设计模式？”“这个命名能不能更语义化一点？” 我改了四版，才合进去。 那是我入职以来最有成就感的一刻，因为我知道自己写的东西，有人在认真看。 技术成长：三个“被迫”提升的能力

第一，代码规范不是约束，是保护。 以前在小公司，变量名用拼音都行，反正没人 review。到了大厂，没通过 lint 的代码连 push 都推不上去，PR 评论里稍微不规范的写法都会被标红。 刚开始觉得很烦，后来习惯了，再回头看自己半年前的代码，发现确实写得干净。好习惯是被逼出来的。

第二，看源码成了本能。 外包有一个尴尬的地方：遇到线上问题，你没法直接登录服务器看日志。 怎么办？只能看源码，拼命看源码。 有天晚上线上有个诡异的超时异常，我同事说“重启一下就行了”，但我觉得不对。我花了两个晚上把那段 RPC 调用的源码从头到尾看了一遍，发现是一个连接池配置不合理导致的，改掉之后问题再也没有复现。 我那个同事后来跟我说：“你是我见过的 debug 最细的外包。” 我说：“因为我看不了日志，只能看代码。”

第三，学会问对的问题。 在大厂，提问是一门技术。文档很全，大部分问题都能搜到，如果你张嘴就问一个文档里写清楚的事，别人嘴上不说，心里也会给你打标签。 我学到的经验是：提问之前自己先找半小时，确认找不到再问，而且要把问题具体化——“我查了 A 和 B，卡在了 C 这一步，能不能给个方向？”这样别人才愿意帮你。 关于外包，说几句实在的先说好的： 项目质量高、流程规范、同事平均水平确实在线，在这种环境里待一年，比在小公司写三年业务代码学到的东西更系统。而且简历上写大厂的项目经历，至少能过简历关。 再说不好听的： 福利基本没有，年终奖打折，没有内部股票，没有免费三餐。那种“二等公民”的感觉，偶尔会冒出来，尤其是看着正式员工在群里聊期权涨幅的时候。 但我想明白了一件事：外包是一张门票，不是终点。我来的第一天就清楚，我在这里是攒经验、攒项目、攒履历，不是为了拿内部 offer（虽然也有外包转正的案例，但那太少太少了）。

一年后的变化最近开始面正式岗位了。 面试官问我：“你在大厂做过什么？” 我讲了那个重构的老模块，讲了那个连接池 bug 的排查过程，讲了我怎么在权限有限的情况下还能保质保量上线。 面试官没提“外包”两个字，一直在追问技术细节。 那一刻我知道，这一年的代码没有白写。 最后想说的如果你也在考虑外包，我的建议是： 看团队、看项目、看技术栈。如果这三样都好，那就去，哪怕是外包。如果三样都不行，哪怕是正式岗位也慎重。 外包不丢人，丢人的是干了一年，发现自己没有任何成长。 我很庆幸，这一年的外包经历，让我离一个更好的程序员，更近了一步