新人入职第一周该做什么，老员工告诉我先别急着表现

我刚入职那会儿也被人这么劝过，当时心里还犯嘀咕，认为这不就是让我摸鱼吗，

后来踩了坑才明白，老员工这话吧，对了一半，也坑了一半，说实话哦。我上一份工作在杭州，3月入职一家做电商中台的公司，第一天就被拉进七个群，电脑还没配好。

当时我想着得赶紧露一手，连夜看文档，第二天开会就提了个优化方案。

结果呢，那个方案早两年就试过，因为历史数据迁移的问题搁置了，我还当着十几个人的面讲，尴尬得脚趾抠地（这个我真没想到）。

所以“先别急着表现”这句话，核心不是让你装死，是让你先搞清楚这公司的代码库到底有多烂、流程到底有多绕。

前三天最该干的事，其实是搞明白三件事：谁说了算、东西在哪、以前踩过什么坑。

我现在的习惯是，入职第一天就翻内部wiki的“历史决策”板块，没有的话就找测试环境地址和部署脚本。

别小看这个，我见过一个新人，第三天就自己把本地环境跑通了，比同期快差不多两天。

他也没干嘛，就是发现公司的依赖包用的是内网私服，地址藏在某个老员工的签名档里。

你看，这就是信息差，跟技术能力没半毛钱关系。

具体方法

那到底怎么“不急着表现”又“不显得混”呢。

我自己的做法是，第一周给自己定个“三十行代码”的小目标。

别多，就改三十行，最好是修个文案或者调个日志格式。

提个PR，走一遍完整的代码评审流程，看看组里谁说话管用、谁喜欢挑刺、谁的评论你必須回。

我管这个叫“投石问路”，石头小，砸不出水花，但能看出水深。

然后中午吃饭别老自己点外卖，跟着组里人走，哪怕不说话就听着。

你会听到很多文档里没有的东西，比如“那个模块千万别动，一动就崩”“某某接口是给老板看的，实际没人用”。

这些信息，比你闷头看三天代码都值钱。

还有个坑得避开，别在公共频道问“这个功能为什么这么设计”。

我吃过亏，当时在群里问了一句，结果那个功能是CTO五年前拍的板，没人敢说不好。

要问就私聊，找那个看起来最闲的老员工，递杯咖啡，问“我想改这块，你觉得会影响到谁”。

这比你在会上提意见强一百倍。

另外，搞清楚你的直属领导最在意什么指标。

是线上故障率、需求交付速度，还是老板的满意度。

我有个朋友在深圳某大厂，他领导只看故障数，他就把前两周的精力全花在写单元测试上，虽然产出慢，但领导觉得他靠谱。

反过来，另一个组的领导看交付速度，你写测试就是磨洋工。

所以“表现”这个词，得看对谁、在什么时候。

第一周就猛冲的人，往往第二周就露怯，因为底牌亮太快了。

• 避坑点：别第一天就提流程改进建议，你连流程都没跑过一遍。
• 避坑点：别在群里发“大家好我是新来的请多关照”，没人记得住，不如私聊加个微信。
• 避坑点：别急着改公共代码，先看看最近三个月的git log，谁改得最多、谁被revert过。

我去年带过一个应届生，他就是第一周啥也没干，光看历史工单和事故报告。

第二周他跟我说，发现一个老模块的定时任务有内存泄漏，写了个补丁。

那个补丁就改了不到十行，但直接让服务器内存降了差不多百分之十五。

领导当场就记住了他名字。

你看，他不是第一周表现，他是第一周攒弹药，第二周才开枪。

所以老员工说的“先别急着表现”，翻译过来是“先别急着送人头”。

你得先把地图摸熟，知道哪里有雷、哪里是安全区，再决定往哪冲。

第一周结束的时候，你能叫出组里每个人的名字，知道找谁要权限、找谁问历史背景，就已经赢了。

至于代码，能跑通本地环境、能提一个三十行的小PR，就是及格线以上。

剩下的，交给时间。

毕竟咱是来干活的，不是来演宫斗剧的，对吧（手动狗头）。