2022-05-23 11:21 已编辑美团_基础研发_研发工程师

关注

实习变形记

hello，大家好。

我是ebby，19年从实习开始，参加工作。喜欢和不同行业岗位的人交流。

小破本毕业就搬砖了，最近很多朋友研究生毕业开始了实习，我自己也开始带实习生搬砖。

当初新开始实习搬砖的时候，踩了不少的坑。有很多天真的想法，还有不太恰当的处理方式。
所以对此感受颇深，简单总结一下我从学生转变成打工人，需要转变的心态还有一些行为习惯，抛砖引玉。

我一直想知道学校和社会上有什么差异和不同，无论是学校理论和工业界的技术的差异，还是整个社会分工协作的不同，亦或是那个象牙塔之外的狂风暴雨。

也为了实习之后能拿到更好的offer，更高的薪资。所以就想借助实习的机会，去了解一下，管中窥豹。

实习生进入企业，虽然刚开始负责的任务，一般都比较边缘，零碎。但也是正式进入企业，负责一小部分日常工作的职场人了。

需要及时调整，以职场人的身份来要求自己。尽快完成从学生到打工人的转变，实习就是我们职场的第一步。

1.和mentor/leader打交道

1.1我听不太懂，不敢说自己没听懂

我确实很菜，我拿实习offer是靠忽悠进去的。看了很多技术大会演讲视频，把他们的ppt背一背，对着面试官一顿输出就这么过了。

可能面试官觉得我挺关注技术前沿领域，就让我来了。如果那时候面我数据库，我是啥也不会的。sql，索引，事务隔离级别八股我都没背熟。

还好是服务治理领域的，不用数据库，核心是网络，c++。

进去就来活了，让做rpc框架的性能测试。仿brpc框架，做一个同样的benchmark，协助mentor出一份公司内自研rpc框架的性能报告。

第一天：装各种软件。

第二天：装剩下的软件。看brpc框架的性能测试文档，看完了，又好像没看完。反正看了个寂寞。

第三天：c++的rpc框架运行要在公司开发机上跑，mac本地运行是跑不了的。还有堡垒机使用这些百脸懵逼，没看明白咋使用咋申请权限。

第四天：老板问我，需求明确了嘛？rpc框架之前了解嘛？我一阵摇头，场面一阵尴尬。

第五天：另一个资深的同事说，如果事情搞不定了，得想想有什么办法可以做balabala的，传授一波工作做事的方式方法。

我没搞定，挫败感十足，有种被问责的感觉。恰好学校让我赶紧滚回去，别偷跑出去实习。只好跑路，协商返校和下次回去实习的时间。

过了一个月左右，重新回去实习。这次mentor换人了🤣，不是之前的同事离职跑路。至于其中发生了什么，不得而知。但是新的mentor，和新的帮助我工作的同事，这次讲的比较细致。

我熟悉项目，融入感觉比较顺利。

后来我逐渐明白，是我当时不知道怎么发问，而一开始的mentor也和我配合的不是很好。好在团队算是发现了问题，没等我反馈，就调整了一下。

如果一开始就明白，把需求拆解，问题明确。

哪些是业务流程，公司里的工具，需要同事帮助，哪些是基本知识，我可以自己上网学着自己搞定的。

问题困难点在什么地方，卡在什么位置。很基本的工作思路，但在当时我并没有形成这样的思维习惯。

当我成职场老油条之后，我自然明白，像公司业务流程，需求背景其实不明白不知道很正常。不给我讲明白了，我是不干的。

技术实习同学对数据库，操作系统，编程语言，git使用等内容也可以不熟悉不扎实，但是不能缺太多。

而且一般实习生也没有六维战士，但某一方面会有些亮点。比如我数据库不会，但是我那会儿网络，和c++的stl库，内存管理这些非常强悍。

1.2mentor/leader都是对的？

作为实习生新人，很自然的会觉得mentor或者同事给到的信息都是正确的，然后按照组内资历老的同事或者mentor的讲的方式去做。

我从学校回公司之后，开始接触某个后端api项目的重构和性能优化。重构最大的坑就是对旧版本收敛过程中的兼容性问题。

很自然的，我当时以同事们的话为圣旨，按同事的思路改完之后，没多想。上线后很快就收到用户反馈，接口调用出了问题。

排查发现新接口的权限被收紧了，导致部分业务鉴权不通过，调用失败。

有的时候，是mentor接了用户的需求，转述过程中失真。结果发现接口不能满足用户的需求。

辛苦做完发现，不满足用户需求，打回重新做，项目自然延期。

这种情况发生个几次，劳心劳力，会非常有挫败感。

有一些朋友这时候甚至会觉得，是不是老板坑我，mentor同事坑我，也满腹委屈地不想背这个锅。

当时的mentor和我说：

我把这个事情交给你，你是这个事情的负责人和执行者，你需要把这个需求的来龙去脉弄清楚，你应该是最清楚这个细节的人。

我把建议给你，做个补充，你得去看看适不适合这么做，实现方案怎么搞，需要你自己去验证确认。

2.技术成长

2.1工作特别琐碎，我得不到成长？

我的成长还算是挺快的，一直都在进步。但实际上我的活一直很琐碎，主要就是客服。

每天回答回答问题，业务有需求来了，就看看做不做。做的话，给他改改接口。

最初实习的时候做的活就更简单了，测试和优化。逻辑也不怎么改，主要以阅读代码理解为主。

按着接口列表一个个copy，把单线程跑的部分copy出来，放到多线程里。

如果就此打住，那确实是丝毫不会有什么成长。

不过我很喜欢折腾，当时想着能不能做成更自动化一点，更美好一点。

分布式系统尤其是AP系统（CAP分布式理论的AP）的接口调用，返回的数据会有不一致的问题。这种情况该怎么测试？这个测试case怎么算通过了？

每次测试都要自己搭很多的辅助系统和外部依赖，还有准备很多的数据配置。测完清理流程走下来还是非常繁琐。能不能mock外部的系统返回数据？

项目用到了zookeeper（简称zk），zk某些版本和mock工具之间是有版本冲突的。

能不能做环境的自动部署，然后自动清理？如果做不了为什么不行？

这些在业务系统上有大量的工具可以辅助，很多容器上云的应用，都可以很方便的测试。但是基础设施不行，就好比张飞力气大，但他没办法通过拔自己的头发让自己飞起来。那怎么办？

这些背后的功课做完，有一次我在周会的时候提了这些问题和想法。虽然还不是很完善有很多瑕疵。但是团队后面认识到这些问题，在这一方面投入了大量的人力去做这些事情。

后面公司也逐渐成立了质效部门，不清楚有没有我反馈的功劳。那时候在实习，觉得自己还是能有点价值，不是拖油瓶，还是有一些自豪感。

后面做了这些事情之后，mentor也会问，我们投入了这么多人力物力，做完之后，项目质量究竟有没有提升？怎么评估？

现在 qa流程这么长，发布的频次都慢了，故障bug确实少了。是因为我们不发版了少出问题，还是确实是测试起到了作用？起多大的作用？

这个问题我至今没有答案，没有很好的处理验证思路。如果有大佬有想法，欢迎探讨。

有很多平常的，毫不起眼的现象问题。背后深挖了，其实有大量的领域难题，即使没办法解决。对这些难题的走马观花，也有足够的成长空间。

3.团队合作

3.1我说的话那么难理解吗？

一开始，我参与的项目很多是没有产品介入。作为实习生新人，也不参与客服oncall。主要交流的人群是技术同学，人群范围一般都是大团队内的技术同学。

交流轻松容易，一般都是技术背景出身，不会有很大的gap。因此，我没有关注到词汇和概念的差异，平时自己的语言习惯，和我认为的常识。其实对不同的人来说是不太一样的。

我实习时间比较长，到了后面虽然还是属于实习，但实际上我已经开始独立负责小模块。这时候有产品介入，出产品原型图，我们研发分工完成原型图不同的页面部分。

有一个界面需要出报表数据。数据运算涉及到后端的计算引擎，我们使用的是大数据那一套东西。作为技术同学，一般能够理解，你的引擎用得是大数据的，还是普通的mysql数据库。

实现成本其实有很大的差异。

我们研发团队以引擎不支持为理由，拒绝了产品的需求。产品不能理解为什么小学生都能做的加法运算，数据汇总。到了你们这一堆硕士高学历技术大牛这，就做不了

。因此不接受这个理由，开启了一场撕逼。这种类似的事情多了，产品就换人了。（当时那个产品不靠谱，沟通出问题是挺正常的，一般正常解决推进就行。但是反复撕逼，弄的引起公愤了换人也不奇怪）

产品听不懂技术同学讲的名词，其实大家非常明显的就能感受到。但是很多技术同学没有意识到自己的语言表达是有问题的，并且因为产品这种有点像文科的东西，好像大家都能看明白。

大家也都能对微信评头论足，教一下张小龙做产品。因此大多没有发现自己的沟通是有问题的。

我是非常频繁的看到，技术同学对产品或者非技术同学解释一个技术概念的时候，大谈特谈技术原理。然后非技术同学听着云里雾里，一个概念不明白，讲技术原理的时候又出现了一堆新的概念。

讲完之后，发现产品同学依然不懂，不明白。最后只能说产品不懂技术。

比如当初介绍服务注册中心的时候，很多技术同学会说，服务注册中心是微服务体系的核心组件，提供服务节点变更，服务注册与发现用的。诸如此类，又引入了微服务体系，服务注册，服务发现这些概念。

但是考虑到听者不是技术背景的同学。我经常会去拿大家都用的某宝举例。

服务注册中心，大概就像某宝，卖家往某宝上会去注册很多它的宝贝。买家会在上面登记他的地址。这样买卖交易的时候，就可以方便配送。

服务注册中心，就是网络世界里的某宝。我们有很多业务是提供服务的，有很多业务是使用服务的。服务提供者和服务使用者都需要去登记，登记完了，我们才知道往哪里配送。

在对外描述的时候，说者和听者都需要注意对方的认知体系，需要努力去注意对方的认知。

4.常见误解

4.1 hr都是资本家的走狗？

20年正式入职谈薪的时候，我入职的公司，出了名的压薪资手段凌厉。

我一度愤恨，拿的是白菜价。不过随时间过去，注意力关注到后面怎么发展上去，也逐渐平复了心态。后面逐渐了解到了hr六大模块，也有一些朋友在做hr。

有的在做公积金社保，落户政策研究。隔三差五的推最新的政策福利。我也因此，薅了不少政府羊毛。有的在做薪酬方案制定，市场调研等等。

我偶尔也能了解到市场的二手数据，知道其实老板们还算是公允，并没有亏待，毕竟一家企业不是走在正道上，是不容易上市的。

有的在做bp，很多靠谱专业的bp，能拦掉许多工作态度方式有问题的同学。

没拦住的，进来什么牛鬼蛇神，导致办公环境恶劣，职场关系紧张。多半是bp不给力，或者没顶住用人急召的压力放进来。

大部分对岗位的偏见，多半是不了解。

4.2项目引入了测试，风控等等。我们的效率变慢了嘛？

每一次项目引入了新的同学，比如产品，测试或者信安风控等别的不同职业的同学。

我们都能明显的感受到我们的流程被卡了，沟通成本成倍的增加。需要不同的人都能理解业务，这时候内耗官僚化的声音不断出现。

因为搬砖有一些经历，我经历过产品的缺位，项管的缺位，前端的缺位等等情况。

产品缺位的时候，我们功能做的很快。做出来之后，大家觉得不好用，然后不停的改。改完发现好像还是不好用。长期下来产品功能都有，但是大家都不愿意用。

前端缺位的时候，我们的页面自然就做的丑。

项管缺位的时候，我们的项目迭代，变得全凭自觉。还会有些事情跟丢了的情况。久而久之，老板就来喷，你们的项目最近搞了什么东西？

术业有专攻，一个人的精力有限。专业的人做专业的事情，对于一个大型项目来说，需要有不同的视角的人去承担不同的责任。

除非你一直在做内部使用的小型项目。不然需要理解不同职位，不同岗位的作用。

这里我引用冯萌博士，关于企业内控的一段描述。

内控体系关注的是企业整体的、长期内的效率，孤立部门/岗位抱怨其自身工作效率受到影响，很可能是一种“只见树木不见森林”的狭隘观点。正好比，绿灯变成红灯，对于刚刚减速停下的车辆而言，确实耽误了司机的时间，但如果没有红绿灯，整个城市的交通必定陷入瘫痪；同理，内控体系关注的是企业整体及长期内的整体效率，而不是孤立部门/岗位的短期效率。

一群人才能走的更远。