Career 2023

今天是 2023 年 4 月 26 日，是我在字节跳动的第 1046 天。

平淡的学生时代

和大多数人一样，我的学生时代没有做出什么出彩的成就，没有参加过任何竞赛，也没有去争取过保研资格，毕业论文也和优秀毫无关联。

和大多数人不一样的是，我没有参加过大学的开学典礼，也没有参加过大学的校运会，甚至在毕业的时候连张毕业照也没去拍，领完毕业证就走了。

但是从某些角度来看，也许，只是说也许，做的还算不错——从没有名牌大学的江西省考入了985、选择了计算机专业、毕业就加入了字节跳动。

其实客观的来看，这也不是什么特别“不错”的事情，尤其是当你身处这座围城的时候更是如此。在成都，电子科大在计算机专业有更响亮的名声；在业内，字节跳动也有不少同事在往外看更好的机会。

总而言之，选择计算机行业这件事，是我至今都很少去反思、怀疑的，想必未来也是如此。

川大是一个包容的学校，条条框框很少，至少对我来说是这样，我的大学四年基本都是过着“放养式”的生活。学校给的约束不多，引导也不多，所以我的选择更多的还是围绕一些自己偶然预见的机会，以及友好的同学/学长/学姐抛出的橄榄枝来进行决策的。

其实在我身处川大的四年的经历中，能称之为 Milestone 的事情并不多，主要是以下几个：

1. 大一上学期的「数字逻辑」课，期末总分是 63 分。

2. 大二上学期开始学习Java，并决定以它作为自己的主要语言。
3. 大二上学期在室友的帮助下进入了「403 实验室」。

4. 大二下开始决定备战 2020 年的春招实习。

数字逻辑这门课就像是浇灭我初入大学校园热情的第一盆冷水（后面还有汇编语言，微机系统等… …），双语的教学模式让人猝不及防，闻所未闻的「门」让人摸不清楚头脑，甚至在期末考试前的几次课前小测验，我都不知道要算在期末的总分当中。看到期末成绩的那一刻，我第一反应就是“我肯定不能保研了”。—— 这也难免为后续出来找工作打下了心里基础。

大二上学期学了 Java 之后（在大一学的是C/C++），第一次见到“集合类 Collections”，发现写代码变的简单了，也就提起了对编程的兴趣。当时正好在学计算机网络这门课程，老师讲到 DHCP 协议的时候，我就联想到川大的校园网 SCUNET 经常登陆不上去，后来发现是 IP 池不足以给上下课人员高峰期的每个同学使用，就用 Java 写了个抢校园网的工具，给当时 Java 程序设计协会的同学使用了一段时间，后来也被一个学弟拿去改了改放 Github 上了，代码在这里。这里顺便感谢学校的前辈总结的 SCUNET 前世今生，这篇博客的详细程度至今都令我叹为观止，想必是耗费了大量心血制作而成，传送门在此。

在大二上学期的时候，我在一个同寝的室友的帮助下进入了一个计算机社团，当时叫做「四川大学Java程序设计协会」，这个协会配有一个很大的实验室，其实就是一个有空调有大型办公桌的机房，甚至还可以在里面抽烟🚬。当时在这个实验室里面遇到了几个同级的同学，还有几个学长学姐，他们教了我不少关于 SSM 开发的知识；但我觉得更重要的是，在很多同学每天早起去图书馆占座的时候，我有了一个更好的硬件环境，可以帮助我心无旁骛的学习。

大二下学期是个转折点，四年的大学生涯已经过去了3/4，之所以这么说是因为当时我们都倾向于尽量在前三年修完所有必修课，以及凑够毕业所需要的学分。所以在当时，大家对自己能否保研/出国，心里都有了个底，我就是那一类“不能保研，又不想考研”的人。而且当时在403实验室，有一个比我大一届的学长已经拿到了拼多多的 offer，所以也算是有了个目标，就这么开始了几乎为期一年的长跑。其实当时准备的也不见得有多好，但倒确实是坚持了整整一年。

春招的结果是挺圆满的，可能是因为当时大环境比较好，最后拿到了一个成都字节跳动的 offer，还有一个杭州阿里巴巴企业智能事业部的 offer。最后我还是因为舍不得成都，就选择去了字节，20 年 6 月份以实习生入职，同年 10 月通过了转正答辩。顺带一提的是，阿里的那个部门，在当时不久后的未来就开发出了全国都在用的「支付宝健康码」。

补充一个很真实的帖子截图：

20-23 年互联网行业的形势真是潮起潮落。

“Always Day 1” to Day 1046

2020 年 6 月 15 号我以实习生的身份加入了字节跳动，那个时候我所在的部门叫做 EE —— Efficiency Engineering，翻译过来就是「效率工程」，主要是负责字节跳动内部效能工具的开发，比如字节自研的一整套 People 应用 —— 涵盖了 OKR、CoreHR（人事系统）、招聘系统和薪酬系统等，当然还有一些横向的工具，比如 aPaaS 低代码平台等。那时候整个大部门的 Slogan 让我印象很深刻：“以字节跳动为实验对象，以敏捷为理念，学习优秀企业的实践，开发、改变现代企业交流沟通和业务开展效率的工具系统。”

我的团队是负责招聘系统的，内部代号 ATSX，即 Application Tracking System X。当时团队还不大，后端一共二三十人，产品也还没有商业化，我进去的时候，我们的产品正处在商业化的前夕（同年年底完成的商业化），所以当时从 6 月到 11 月的这段时间，团队内的业务还是非常繁忙的，后来为了冲刺，团队内还喊出了“决战 930” 和 “再战 1031” 的口号。

顺带一提的是，当时互联网的形势还算不错，一共二三十人的后端团队内，包括我在内有大概 6，7 个实习生 —— 后来我是唯一转正并留下来的。

“艰难”的转正之路

之所以称转正“艰难”，一是因为同批的 6，7 个实习生中只有两人通过 —— 除我之外的另一个女生后来没有选择留下来；二是因为当时正常的同学一般在实习三个月之后就会发起转正答辩，我花了整整四个半月才将整个流程走完。

我是怎么通过转正的？概括来说，是遇见了一些同批次同学没遇见的机遇，换成俗套的句式来描述，就是运气好：性格和 Leader 很对付、需求交付的也比较及时。

在我刚加入团队的时候，团队内部有一个新人 landing 必须要做的事情，就是在熟悉自己组内的业务一个月后，写一篇串讲文档，再约一个很大的会议室邀请组内所有同学来旁听。你需要一篇详细的文档来描述你所负责的业务，然后在有限的时间内讲解完文档上的所有内容，并且过程中你需要回答任何同学对你提出的问题 / 质疑，过程中你的 Leader / Scrum Master / Mentor 会在你的文档上留言记录全过程。只有串讲通过的实习生同学，才会开始被安排业务需求，否则只有做一些横向的/业务无关的任务；如果串讲失败，则需要在会后修改文档然后找时间再次发起会议。

当时串讲的严格程度令我汗颜，简单来说，串讲的考核是打分制的，准确的说是“扣分制”，过程中每答错一个问题就扣 10 分，低于 60 分就宣告失败。一次串讲的时长从 30 分钟到一个小时不等，参与的人数从 10 到 20 人不等，形形色色的问题个数也从 5 到 10 个不等。最令人感到窒息的是，同学们问出的问题往往都是你的串讲文档以外的内容，时而上浮到业务逻辑，时而下潜到服务使用的 RPC 框架、中间件、数据库表设计的理念，甚至还有云平台的配置和 Golang 的基础知识。当时同一批的实习生，有连续两次串讲失败的，我在一旁看得焦虑无比。

后来我在两位 Leader 的支持下跳过了串讲的流程直接进入了转正答辩环节，并且答辩环节也是所谓“走个过场”，不过那都是后话了。

我进来的第二周，我的 Leader 就给我安排了一个对新人不太友好的任务 —— 写一个飞书机器人来追踪代码上线前后的一些发布流程，将他每次发布时需要做的很多人工操作进行自动化。之所以说不友好，是因为作为一个大学生（也可能只是我自己），其实在面对陌生的工业环境时，很难立马融入到一些“平台化”、“标准化”的流程中去。具体来说，就是阅读飞书开放平台的服务端文档对当时的我而言是一件很困难的事情，这倒不是因为那些文档写的有多么晦涩难懂，而是在于让你在毫无实践经验的情况之下，只通过阅读文档来进行一些开发工作。这个问题稍一延伸，就变化为：“从理论跨越到实践”。

幸运的是，飞书团队在 Github 上开源了一套机器人的 SDK，简化了不少基于 OAuth 2.0 的应用鉴权流程；并且在武汉一位同事的帮助下，通过一些非常 trick 的方式赋予了机器人用户身份 —— 让机器人使用我 Leader 的身份来操作云文档；与此同时，字节内部对网络隔离的要求还不是那么严格，我可以方便的把编译出来的可执行文件直接部署运行在我个人的开发机上，省去了不少关于服务部署的学习成本。最后这个机器人成功的跑了起来，虽然内部的实现非常简陋，就连很多持久化的功能都是直接依赖于开发机上部署的 redis 来做的。

总结来说，站在现在的角度来回顾当时短短一周的过程，有两件事是比较重要的：

第一是打开思路：xx 平台提供了官方文档，我们未必就一定要按照这个文档去做对接，在这个具体的例子里是恰好飞书团队官方就开源了一套 SDK，即使没有官方的 SDK，我们也大概率能够在网络上找到别人封装好的轮子。当然上面这个例子只是一个具体现实的映射，我们还有很多别的场景不适用于上面这个具体的解决思路，重要的事情是不要局限于问题的表象、现有的解决思路可能是一种束缚。

这里稍微展开一下，我在字节跳动听过几次震原的分享，其中有一个分享的主题叫做《工程师成长的真相：“成长是自己的事情”》，里面他举了一个例子，也是他早期在百度期间听王梦秋分享的：捕鼠器案例的启示。

简单来说，当你被安排了一个“优化捕鼠器🪤”的任务来提升捕鼠效率之后，你可能会 focus 在捕鼠器本身去优化物理结构，然后在一段时间后就达到瓶颈；但是后来你可能会发现任务的目标在于灭鼠，于是你下一步会想到舍弃捕鼠器而转为使用灭鼠药，于是你又开始 focus 在灭鼠药的配方和投放位置上；最后你会发现老鼠没了之后也保护不了粮食，因为你的粮仓时常漏水；step by step，你可能会将你的目标转移到「粮食保护」这件事情上去，制定具体的粮食保护评估指标，然后你可能会成立“粮食保护小组”，最后上升到更高层面的“政策”、“法律法规”上去，最后可能在国家层面就形成了粮食保护局，或者世界范围内的粮食保护组织，就像 WTO 这些组织一样。

第二是主动寻求帮助，如果确实觉得文档对于当前阶段的你是晦涩的，坚持一段时间也无果，那么不妨去问问前辈，我们常说“不耻下问”，在这里对应的是“不畏上问”。我当时在飞书上点开了我们行政群的一个“提醒你按时吃饭”机器人的详细信息，在里面看到了开发者是 xx 同学，我就直接小窗私聊那位同学请教机器人的开发细节了。First thing first，大多数时候解决问题比较重要，个人的想法、情绪先摆到一旁，解决问题带来的正反馈与自己克服自己的心理障碍所造成的损耗，这二者综合起来的数学期望往往都是 > 0 的。

这里也稍微展开说一说，在上面引文中震原的分享中还有一点，就是“成长是自己的事情”，这里震原想表述的主要是你要有自己的目标，有了明确的目标之后，那么你身边的人和物都是资源。你的 Leader 是资源，你的同事也是资源，站在这个视角来看，公司也就是组织资源的一种形式，能够通过一些“权威”的方式来降低交易成本。那么对应到这个例子中，我就是利用了飞书机器人的 profile 详情页查看到机器人的作者，然后利用飞书提供的方便快捷的“视频通话”的资源，来触达到身在武汉的机器人作者这个资源，最后利用这个资源完成了我的目标。

转正后的长期迷茫

2021 年 7 月，我结束了为期一年的实习，无缝衔接到正式工作中去。

从 7 月到第二年的 3 月，我都处在一个长期的迷茫过程中。22 年 3 月之后其实也只是略有改善，并没有好多少，直到 22 年的 6 月我才真正结束了为期一年的迷茫。

之所以称那段时间为迷茫，是因为那段时间迷茫的太过明显 —— 没有目标，也没有压力，完全是听从别人的安排去做事，做的事情也非常简单。

具体地说，别人都在做业务需求的时候，我在做杂活，别人当项目 Owner 的时候，我在里面打辅助，而且辅助的不见得有多好。

之所以会这样，主要有两方面原因：

一是个人原因。初入职场的同学往往没有明确的目标，总是被动的去解决问题；在高一层的 level 上缺乏思考，或是想不清楚，亦或是想清楚了但懒得解决，也可能是不敢提出来解决，于是就形成了一种“高不成低不就”的状态。我当时就是如此，虽然在团队内有一年的实习经历，对流程和套路都比较熟悉，但也仅限于此。我当时没有主动的去研究组里的服务代码，所以对不是自己负责的业务不熟悉，也没有主动的去研究团队的服务架构，导致对系统流量的链路不熟悉。

体现到实际工作中最明显的一点就是，每当线上用户对业务提出咨询时（招聘系统作为一个 B 端的产品，虽然技术架构做的没有 C 端深，但其功能逻辑异常复杂，有时甚至需要专门的同学给客户进行培训后才能投入使用），我都是一头雾水，会直接将别的同学拉入咨询群中帮我解答。更严重的是，有时线上出现了故障，我都不清楚如何排查。

这里说一件真实发生的故事，现在的大部分业务都是由多个微服务组成的，我们团队也不例外；在团队内我们细分了多个小组，简称 Scrum，每个 Scrum 会负责一到三个微服务。当时作为新人，我养成了一个非常狭隘的视角 —— 我只要关注自己组里的一到两个微服务的代码仓库就行了。

有一次接到需求之后去找我的 Leader 询问如何开发，他告诉我相关的代码在 xxx 服务的代码仓库里面，然后顺手就要在我的电脑上打开那个仓库，想直接一口气帮我找到相关文件。然后他找了半天发现我压根就没有拉过那个仓库的代码到我电脑上，没忍住吐槽了我几句。

那么为什么会这样呢，直接因是自己对于工作的 Scope 圈的太小，终极因是自己没有明确的目标。

二是团队原因。团队始终处于一个高速成长的阶段，时至今日也是如此，团队一直在面临的不仅仅是层出不穷的新需求，更多的是过于追求高速度而欠下的技术债。团队如何应对上面的情况不是这里的关注点，重要的是当时确实缺乏一些对于新人的引导，大家都在忙自己手上的活，Leader 那边没有给我制定明确的发展计划，我自己也没意识到这一点 —— 最后就好像一只被放养的羊，自娱自乐，自给自足。

总的来说，作为一个新人，我并没有想清楚自己要什么，也就没有利用任何的资源来达成任何目标。也许大多数人在一开始的时候都会面临这样的窘境，但我不知道我让这种情况持续了接近一年的时间，是不是超过了同批次同学的中位数。

向“独当一面”出发

直到 22 年的 3 月，这个情况才略有改善，改善的直接因是组里有个关系很好的同事 w 晋升了，想缓一缓，然后把后续的一些需求交给我来当 Owner。说到这里还是要感谢 w 同学，我当时负责的第一个需求，连方案都是他预先帮我出好的，而且开发过程中他的贡献的代码量并不比我低。

虽然是被动的，但好在整个需求交付的过程和结果都还不错。被动的被推上战场，并不代表过程中的事情都会变的格外艰难，跨团队沟通、对交付风险的把控、项目整体 Milestone 的制定对于没有经验的人来说虽然有挑战，但是“hone by doing（事上磨炼）”的感觉也会给人带来不少的正反馈。不过比较特殊的是，我做的这个需求本身可能和业务不太挂钩，还是偏横向，而且当时也因为个人的一些情况导致有些不在状态；但总的来说，这件事是个开始，多少改善了大家对我的印象，也为后续逐渐成长为“业务主要支撑同学”打下了基础。

22 年的 6 月，我接到了第一个需要我独立完成的较大的业务需求，业务的复杂度很低，总的来说就是批量勾选一些实体，然后将实体上挂的一些文件进行打包导出，然后用户就可以把这个包下载下来，也就是一个批量的文件下载功能。需求虽然简单，但是当时我们团队并没有一个好的流处理文件的解决方案，现成的方案都是需要借助容器里的本地磁盘作为介质来存储中间产物的，也就是会先把源文件下载下来到 /tmp 文件夹中，然后压缩成一个 xx.zip 压缩包，也存在 /tmp 文件夹中，最后再把压缩包进行上传。所以当时我从技术的视角出发，写了一个基于 Golang 的流式「下载-压缩-上传」的 SDK，只需要在在两个流的对接处留下一定大小的 Buffer，就可以实现完整的多文件传输链路，而无需依赖硬盘来保存中间文件，这个 SDK 完成后也得到了很多需求的服用，目前已经是团队内的一个标准解决方案了。

我想说的是，这可能和字节范里的“追求极致”没有太大的关系，而更多的是作为一个工程师的工程素养的问题。你需要敏锐的意识到现有方案的种种问题，然后评估其风险，接着思考是否有更优解，以及更优解是否有业界成熟的经验可以复用，最后盘点其 ROI 是不是足够的高，同样关键的是，这个过程需要在有限的时间内完成。听起来可能会很困难，事实上也确实不简单，要做好这些事情确实需要一些时间的沉淀，需要丰富的经验，对于新人来说确实不够友好。

时间管理是永恒的话题，每个人的时间都是有限的，工作时间的很大一部分都会花在工作本身，留给自己沉淀积累的时间永远不会太多，关于改进的方式，可以参照「5小时原则」和「一万小时定律」。

经验积累的方面，我想数据库索引的思维也许能够带来一些启发。既然时间是有限的，那么我们在有限的时间内如何能够获取到更多的信息这一问题，也许可以转变为 —— 如何加快获取信息的速度。我的一个想法是，你可以通过各类搜索引擎，不管是 Google、Github 还是企业内的文档搜索工具，来获取到大量成熟、现成的解决方案，然后你可以对这些方案做一个初步的了解，尤其是“这个方案到底解决了什么问题”是必须要弄清楚的，这一系列过程就像是在你的脑海中建立了数据库的 二级索引，以后当你遇到这类问题的时候，你就能够迅速通过这个索引来找到 primary key 然后回表查询，所谓的回表也就是通过各类搜索引擎来帮助获取详细信息了。

举个例子来说，我的实际工作中并不需要我亲身接触到 Elastic Search，但我会知道它是业内实现搜索功能最常用的中间件；与此同时，我还记得我曾经在逛 Github 的时候，通过 Golang 的标签偶然看见过最近点赞量很高的 Zinc 引擎，然后我通过它的简介知道它也能够很好的实现搜索功能，只是相比 ES 而言显得更轻量。所以也许在未来的某一天，当我的团队需要从 0 到 1 的去搭建搜索服务的时候，我能够迅速的通过这些“索引”来获取对应的知识帮助团队完成技术决策。

当有了一些积淀之后，后续的规划和目标也理应变的清晰起来，不管是晋升的计划还是对于业务的责任感。字节一直都很强调的 “Ownership” 也许在管理手段上会显得较为严苛，但是毕竟成长是自己的事情，不管外界是如何变化，自己的想法是否明确总是更为重要的。

具体的说，如果你正在待着的地方，所属行业发展快、团队氛围好、回报比较公平且周围有比你厉害的前辈可以借鉴，那么你所在的环境就已经是很好的了。

当然，上面所说的这些点，在我看来并不是符合「安娜·卡列尼娜」原则的，很多同行都会为了上述中的一到两点而选择加入一个团队。

正面思考，用脚投票

“正面思考，用脚投票”这八个字是我在字节期间某一次听 「Tech Talk 定坤震原面对面」所接触到的。

任何公司发展到一定规模之后，组织架构的层级就会变得更为复杂，导致我们无法（或是很难）与上层（你的 +2 / +3，或是公司的 CEO）直接进行跨级沟通，也就是说我们往往都只会和自己团队内的 Leader 或别的同事进行沟通。所以这也就是为什么大家常说：“转岗换团队和换公司并没有什么区别。”

不过这类问题往往是与工作/业务相关的，换句话说就是和你的个人发展相关的 —— 根据我的经验，大家对于“停车场停车不方便”、“下午茶的质量堪忧”、“疫情要来了，我们什么时候居家办公”之类的问题会表现地更坦诚清晰，其实无非就是，针对大家共同面临的问题，我们会显得更有底气。

人与人之间的沟通也是一个永恒的话题，过程中不可避免的会有很多矛盾的产生。关于这点，在《Guns, Germs, and Steel: The Fates of Human Societies》（枪炮、病菌与钢铁：人类社会的命运）一书中有许多详细的论证。

书中的第14章《从人人平等到盗贼统治》中描述了人类社群的发展过程：游群-部落-酋邦-国家，每个社群的规模和组成结构都很大差异。书中提出，当社群发展到酋邦阶段时，内部冲突的问题十分严重，主要是因为酋邦人口众多且大部分人彼此之间并没有血缘或姻亲关系，所以酋邦在 7500 年兴起后，人类开始学习面临陌生人的第一课：如何面对经常遇见的陌生人，不互相残杀？

虽然现代社会的公司和社群的发展不能相提并论，但是 Jared Diamond 在书中的论述还是有可借鉴的点。如果我们按照书中的人数指标来看待公司，那么公司整体就类似于一个酋邦，各个业务线的大部门就相当于一个部落，而我们每个小团队就像是一个游群。但是这么划分之后，显然我们会发现实际的工作体验与 Jared 的论述有极大的出入，我个人的想法是我们一个 5，60 人的业务团队更像是一个融合了“部落”和“酋邦”的社群。

显然我们不能像治理酋邦或是国家一样，通过宗教和卸除人民武装等手段来解决人与人之间的矛盾，更现实的解决方式还是要从每个人自身出发。在《Selfish Gene》（自私的基因）一书中有提到作者不支持“以进化论为基础的道德观”，在实际工作中我们往往也能发现，基于善意的假设去开展工作往往会比恶意假设带来的结果更好。

在工作中，我们时常会觉得自己的想法不被别人理解，比如对于自己的绩效不满意，觉得领导给自己的晋升规划过于滞后，或是单纯觉得他人就是在针对自己，在遇到这种情况的时候，往往需要我们去正面思考和应对，当矛盾和 Gap 产生的时候，你是否思考过你是不是有哪些事情没有沟通清楚，如果是的话，你有没有思考过可以找谁去进一步了解信息，有没有理性的劝说对方，举个初高中老师常说的例子：

请计算 x 的值

$$x^2 + 2x + 1 = 0$$

同学 A：

$$\begin{aligned}解: 原式= (x+1)^2 &= 0 \newline x+1 &= 0 \newline x &= -1 \newline 答：综上，x = -1 \end{aligned}$$

同学 B：

$$-1$$

阅卷人可能会给同学 B 的答案上打一个“半勾”，然后扣 1-2 分，如果是严格的阅卷人，也可能给 0 分，当然也不排除有的阅卷人不在意这些细节，经常有的同学被扣分之后，也许就直呼阅卷人是个 **。

实际工作中遇到的情形可能更复杂，不是一个非黑即白的场景，比如也许确实之前在某件事上没做好，然后被领导和同事质疑了，但是那件事之后表现的还不错，甚至还有一些小的亮点，然而年底的绩效还是不及预期，于是可能就觉得大家对自己有偏见了。这种情况下，也许真实的原因，只是团队内有别人在你不知道的方向上表现得更好，或者是今年业务的财报不佳，团队整体的绩效都不好。那么在这种情况下，你是否有和他人积极的沟通过，还是说一直回避这个问题，会对后续发展产生截然不同的两种影响。

当然也不排除有时自己已经正面的尝试去解决过这个问题，仍然没有什么改善，这种情况下可能你需要尝试跨级沟通，只是这样成本可能会显得“格外的高”；或者你选择离开，寻求更好的环境，也就是标题中的后半段 —— “用脚投票”，当然这样做的成本也不见得有多低，如果当前的环境确实很糟糕，且长时间得不到改善，那么大家也就会用脚来表达自己的意愿和想法。

但是总的来说，正面思考是首先要做的事情，在一个越大的群体里面，沟通的效率就越低，就越容易产生不信任的感觉，就像软件工程没有银弹一样，是一个永恒存在的问题。既然知道问题的根源来自于此，那么我们应该意识到在绝大多数情况下，都是有一些误会存在而导致的。

当然，理解“用脚投票”也同样重要，之前在网络上有看过一个言论：

“每个人的每个选择，都是在权衡当下之后做出的最优解。”

但是要注意到权衡的过程往往是不够客观的，比如有的同学会觉得换个工作太麻烦，需要重新复习“八股文”和算法题，也有的同学会因为在网络上看到很多言论说今年的就业形势紧张，现在出来没有什么机会，于是就选择“委屈一下“，保持现状。这样想其实是没有错的，只是你务必要去辨认清楚信息来源的真实性，”网上说的就业形势紧张是我的行业吗？“，”同行找不到工作，那我是不是也找不到？“，”每天早起一小时刷算法题和复习八股文是否会对我的生活造成很大的影响？“ 我有遇见过不少同学，甚至简历都没敢投递出去，就认为自己肯定得不到面试机会。

除此之外，在权衡过程中除了需要辨认信息的真实性，还需要避免采用单一的“贪心算法”，这个算法的使用场景是很有限的，这里就不展开了。

补充一个例子：

这里从另一个广泛的现象来阐述一下“正面思考”。大多数实施绩效考核的公司想必都发生过员工对绩效不满意，于是在网络上掀起舆论风暴的情况。我们把视角稍微延伸一下，就会发现其实不只是绩效的问题，当今任何没有得到公正处理（不管是主观还是客观）的事情，都有可能在媒体和网络上发酵出一阵轰动。

然后作为旁观者、事不关己者、义愤填膺者或是杞人忧天者，我们最终都会经历一个阶段，就是对热度的退减而产生愤怒或失望的情绪。

之前我也是这么想的，直到在一些分享中听到定坤对于这种现象的理解，才算是释怀了。其中的关键点在于，“让一件事情发酵的目的到底是什么”，这个问题是绝大多数人都没有想清楚的，或是压根就没有去想过的，就是单纯的吃瓜心理在背后作祟，甚至略显刻薄的说，很多人需要一些类似的事情来让自己的情绪得到调节。其实这个问题的答案还是比较单一的，用计算机的术语来说就是“索引的区分度不高”，一个事情发酵出来的目的往往是希望这件事最后会在群众的监督下解决，于是解决的结果会更为公平，即使不能让所有人满意，解决的过程至少也是秉公的。

那么在事情发酵之后，已经进入处理阶段之后，目的可能也就达成了，那么进一步的扩散应该是毫无必要的，也许还会带来许多诸如违反公司内部保密原则、损害公司的形象的弊端，所以会有一个人为的管控过程。

当然，也有一些特殊的情况，例如也许有些人让事情发酵的原因不是单纯的希望解决问题，或是管控之后没有进一步的推进问题的处理，不过这些情况不在我们的论证范围内了。

现在，在加入字节跳动后的第 10xx 天，我决定离开这个地方，离开的原因很简单，我的团队经常用 ROI（投资回报率） 来衡量做一个需求的性价比——我觉得现阶段的我继续在这里做下去的 ROI 不高。

虽然我没有那么好的运气，去经历字节跳动，甚至是国内互联网行业的黄金发展期，但是我幸运地经历了我们业务的高速发展期（虽然看起来这边的业务一直都处在高速发展的道路上），见证了一个团队将业务商业化的全过程，于是自己也在其中获得了很快的成长。

“ROI 不高” 这个话术过于抽象，具体来说我思考的主要是以下几点：

1. 产品已经商业化 x 年，正处于稳定的迭代期，亮点和机会相对变少，逐渐到达瓶颈期。
2. 除了业务稳定之外，我个人对其未来在市场上的发展也不抱太大的希望。
3. B 端的 HR 领域产品的复杂性往往体现在业务逻辑，技术深度相对不足。
4. 团队和产品内暴露出来的某些问题，当前的我并没有能力去解决、甚至是推动。
5. 相对来说，当前获得的回报无法掩盖上述的问题。

通俗的说，对我而言，“打工”中很重要的一环是价值交换的过程，公司可以用物质来换取：我的 idea、我的劳动力、我的人脉（比如猎头行业），也就是说公司可以提供他的资源来换取我的资源。一般来说，在合作关系开始的时候达成这一点是必然的，只是随着时间的发展，平衡会逐渐被打破。

比如我会觉得随着时间流逝，我对业务日益熟悉，我的产出也日益变高，于是我的工资也理应上升；或者是我觉得团队的工作量相比去年翻了 1.x 倍，如果不给我涨薪，那我的时薪就在下降；除了物质层面，可能我们还会逐渐在技术上也到达瓶颈，比如我们可能会在 x 年的时间里把团队的技术架构和选型基本摸透。当然，更坏的情况是当前的环境会带来直接的负面影响——上面列举的例子充其量也只是“不进则退”，比如职场里“不顺畅的沟通“和”不正当的竞争“也许会给你带来更大的心理负担，又或许过长的工作时间会直接影响你的身体健康。

当然上面讨论的只是一些可能发生的具体问题，而问题如果能解决的话，就不是什么问题，这也就是为什么我标记了第三点思考的原因。总而言之，我已经正面思考过，思考的结果驱动我“用脚投票”了。

End

我喜欢出发。凡是到达了的地方，都属于昨天，哪怕那山再青，那水再秀，那风再温柔。 —— 汪国真

感谢字节的三年，庆幸自己的清醒，也佩服自己的勇气。