我在FLAGUAP工作4年的职场感悟

楼主的文章太赞了！！！ 给力！
想请教一下楼主，devOps/SRE算 infra eng 的一块吗？还有可以问下 你为什么转到pure infra这块呢？

螺丝钉学到了

工作4年的职场感悟

很有用的信息！

If you want steady growth, good stability, top-notch paycheck. However, if you are clear about what you want, if you believe in the company’s future, if you enjoy startup vibe, you are in a good place to make big impacts.

良心分享！谢谢楼主！

醍醐灌顶的干货，哎，还是水平太低了。希望能进入想去的公司，然后学习楼主的视野，最好是能交个朋友，我好好加油。

很有道理👍 期待樓主更多分享

Update on 10/26/2019:
发完这篇文章之后很多童鞋在评论里表达了喜爱并提出了一些很经典的问题希望我回答。非常高兴大家对这类主题感兴趣。因为工作太忙的关系，我可能无法一一回复每个读者，但是定期我会挑选一些之前没有来得及讨论但是大家反映很重要的topic来补充讨论，所以如果你们有什么想要了解的话题（限于本人经历和能力范围内的）我都会尽量补充回答。

题外话：好像这个版块的文章是不能直接编辑的。如果版主看到这条回复的话，麻烦请帮我编辑到正文的最下面，这样新老读者可以直接在正文里看到全部的更新。感谢！

关于选组

在之前的"关于Full Stack Eng vs Backend Eng vs Frontend Eng vs Infra Eng"中有简单地提到team structure的类型，不过没有过多的讨论。好几个高赞回复都希望再扩展讨论一下，索性我就把连带的几个问题一起讨论下好了。

如果你是new grad或者L3 new hire，通常可供选择的机会和范围是极其有限的。一般来说大公司有两种机制针对new grad，team match和bootcamp。从new hire的角度看当然是bootcamp给的自由度更高，但是从公司的角度看bootcamp的效率极低，本质上其实是两者的goal完全不同。公司招聘junior engineer是为了补充每个team对staffing的需求，以应对分配下来的team goal或者cascade到company goal，但是并不指望他们在能力上有什么特别的地方。所以理论上当然是让hiring manager或者eng manager根据简历、背景考察、sell call、面试情况来挑选大致合适的new hire到自己的team为最优。但是，好的公司又希望尽最大可能尊重new hire的个人兴趣爱好，相信一个人如果干自己喜欢的事情肯定会激发出更大的潜能。这里的问题就是new hire的个人兴趣爱好如何跟team的需求有最优的match？为了解决这个问题，有些公司又搞了一种叫做preallocation的机制，就是将每个junior new hire先按Product Area或者Business Unit甚至更小的单位分配，还是会有bootcamp，但是最后new hire只能在这个PA或者BU甚至下面的某个Org里选择具体的小组，这里还有可能run一个double ranking list来做match，就是manager和new hire把想要的人/想去的组排一个优先级，双方进行从高到低的匹配。说了这么多team match背后的机制其实是想给大家一个客观的忠告：除非你对这个公司非常了解 which is almost impossible for junior hiring，否则最好保持一颗随遇而安的心，既来之则安之，根据结果来调整优化自己的career path，而不要把全部身家赌在选好一个team上。

看到这，大家可能有两个最基本或者最自然的问题要问：

1. 我有熟人在这个公司啊，他/她可以给我很多内部information来帮助选组。这其实忽视或者小看了个人的bias，举个粗暴简单的例子，一个非常senior的infra eng通常是不会推荐你去pure frontend team的，反之亦然。但是这并不代表对方team真的不好。如果你的朋友在product team，由于project之间的isolation还有team dynamics等因素，那更是管中窥豹。
2. 一个公司里是不是有这样的对new hire很好的组存在呢？首先，“好”是相对的，是严格跟你的personal career goal绑定的。对A好的组不一定对B好，即使这两个人都想快速升职，但只要这俩人有明显的不同（比如personality），对同一个组的评价就会有不同。第二，假设有这么一个组符合你的期望，那你想想，这个公司有没有内部的engineer跟你有同样或类似的期望呢？他们肯定比你有更多的information和转组机会，所以理论上这样的机会一旦存在，一定是先被内部消化了。

另一方面，如果你是senior hire，那基本上都是定向招聘了。senior candidate的个人需求一般都是很明确的，他们有一条非常clear的career path，所以知道自己想成为什么样的人，该选择什么样的team来帮助自己到达那个位置。这里我就不再赘述了。

综上所述，对于童鞋们提到的选择senior多或者少的team哪个好这样的问题，其实你已经限制了自身发展的可能性。senior eng多的team可以提供更多更好的mentorship，更成熟的dev process，code review，甚至一些职场guidance，project scoping或者priority setting你都不用操心，坏处就是junior position很难有出彩的机会，或者大的initiative一般都不会让你来做，或者你的角色是属于辅助角色或者可替代性比较强的位置，impact相对比较小。senior eng少（和没有senior还是有本质的区别）的team就恰恰相反，因为senior eng自己无法做完所有的事情，他/她需要delegate部分甚至重要的事情给junior role，这个时候你就可能在更早期take such initiative然后make bigger impact，但另一方面，流程管理和quality control就不再那么完善了。L3到L5的道路上technical complexity并没有非常高的要求，另一方面，impact是作为一个更高的指标体现在perf review中的。我在这两种结构的team里都有看到很多成功的例子，当然也有失败的例子，所以这个事情是不能一概而论的。最重要的key point是希望大家重视调整自己看问题的视角和思考方式，以便更好适应或者优化当前的path，也为将来的转换（升职、换组、跳槽）做好准备。

关于稀缺性

有童鞋在评论中提到稀缺性高的工种开放的职位也比较少，怎么平衡这种选择？我不太清楚这位童鞋的背景哈，可能大家有一个误区认为说linux kernel engineer只能做kernel相关的工作，不能做别的工作了。咱们换个例子来想想，Linus写了一辈子的kernel，你说他难道对dev productivity一点不懂，或者他能不能做networking的job，或者他能不能做database level的development，甚至你让他写一个mobile app，他会写不出来？答案是显而易见的。一般来说需要一点时间适应或调整下，但是rampup通常都是很快的。陈皓（网名左耳朵耗子）曾经感慨过“细节是魔鬼”，结合我自己的工作经验就是谁能把细节扣的越深，谁对问题的理解就越透彻，在技术市场上就有越大的稀缺性。回到最开始的问题，linux kernel engineer一定不怕找不到饭碗的，唯一阻碍他们的只是他们愿不愿意去做一些更上游的（当然不是指从kernel到网页开发那么极端啦）、overqualified job。不过就像上面提到的，一流的工程师可以把一个看似很普通的问题发展出创新性的技术产品甚至引领那个领域的发展。推荐大家读一读Facebook React的发明过程和Airbnb Airflow的发明过程，都是在已有很多开源或工业界标准解决方案的情况下提出来的最后又在工业界成为了很受欢迎的开源项目。

关于我为什么从Product组跳到Infra组

每个人的经历都是很特别的或者unique的，这跟自己的性格、家庭背景、现在的处境等等都有关系。分享我自己的经历除了满足下大家的好奇心之外，其实不一定能帮到每个人具体的case，几乎所有的案例都得case by case的分析。所以下面我主要介绍下我的thought proces，这些反而是比较容易借鉴和二次发挥的，希望对大家有所帮助。

当我刚进公司的时候是在一个产品组工作，没有一个什么很特别的理由，就是这个组的manager是我的new hire buddy，team和我自身又比较match，大家就一拍即合了。因为这是一个垂直产品，所以需要涉及到修改公司的整个tech stack。在这个过程中，我hands on的写了非常多的code，design doc，到最后也有机会去给别的team做技术分享。

后来由于一些人事变动，我们做的产品被deprioritize了，因此整个team都面临着被shuffle的可能性。于是，第一次换组就在这个时候出现了。当时我的想法是我已经对product开发整套流程和相应的tech stack都非常了解了，不想换个team做类似的事情，但是另一方面，在技术深度上我觉得还欠火候，想往底层做做，又不想一下就做到非常low level的stack上（比如database，network，parallel computing, data warehouse etc），所以最后选择了一个成熟但有着更细致分工的产品团队，深入做backend的work。除开manager，team member，team culture这些考量外，技术上算是一个不错的过渡，能leverage已有的技能，又能touch更多的pure infra projects或者开展更多合作。

就这样干了一年多。后来有一段时间我已经把手头的项目做的很成熟了，也做了很多delegation的work，让我的teammate去take more initiative。这个时候我越发觉得自己的成长速度开始快速下降，就是感觉每天解决的问题都是我信手拈来就能搞定的，已经没有什么挑战性了。另一方面，和infra team合作越多越紧密，我就越发觉得其实自己的domain knowledge还是不够深入，还有很多有趣并且有挑战性的工作可以让自己成长。于是，我就着手跟不同的infra team进行洽谈并最后选择了现在的team。因为之前跟很多infra team都build了良好的关系，同时别人也看到了我的能力和技术水平，所以整个洽谈过程非常顺利，没有遇到任何挑战和阻碍。现在在新的team做的事情都极具挑战性，由于已经到要跟disk、network和OS这个level打交道了，有很多问题或者bug都不是说我花时间甚至一个礼拜就能搞出来。team或者org里的senior IC或tech lead的眼界和提出的意见在这里就极为重要，也让我深刻感受到进入了一定的技术深度后，真的不是只靠勤奋、努力或者熬夜加班就能解决问题，长期的经验、对问题的深刻理解和技术视野在这里起到了关键性的作用。所以现在每天干活都是非常开心的，即使经常碰到自己挠头瘙痒都很难解决的问题～

最后总结一下，我个人的经历是一个从tech stack上层往下做的过程，当然我也见过有人从下往上做也很成功的。这些都没有固定的范式，最重要的是确立好自己当前的career goal是什么并为之做优化。这个goal随着时间是可以变化的，但不宜变化太过频繁，除非特殊情况，不然几乎都说明你之前的goal setting想的不够充分，不够合理，需要多反思、多总结，避免白白浪费掉宝贵的时间。

～彩蛋～

有童鞋说到我的文章里有一些概念或者思想跟吴军老师的谷歌方法论很像。应该说这位童鞋还是很敏锐的，我本人是吴军老师的粉丝，我阅读了他几乎所有的著作，也很欣赏他思考和做事情的原则、态度和方式。这里我没有任何给他的书打广告的意思，只是想补充说明一点，这个世界上有很多比我们厉害很多的人，他们已经提出了很多insightful的观点，但如何把这些观点落地并与自己的具体经历结合却是一个很有挑战性的事情。绝对不是说你去把某个名人的书看一遍或者听听他的talk你自己的世界就会发生天翻地覆的变化。我个人认为最重要的是methodology，中文也是方法论的意思，和实践精神。头脑里有好的方法论做指导，然后脚踏实地地去实践，这样才能有真正的提升～

写得非常精彩，收益良多！