在前面
这应该是我第一次发帖，虽然在公司做过大大小小的tech和non-tech talk, 还是有一点点紧张，语言组织上如果有点混乱还希望大家理解～8年来人生轨迹也发生了很多的变化，有高兴，有失落，有惊喜，也有怅然。其实这些都是非常正常的，就像乔帮主在Stanford的演讲（特别精彩，强烈推荐）说的，这些人生道路上的点点滴滴在一开始时是那么的分散和毫无联系，但是最终它们会在某个时刻汇集成 the reason why you are who you are now.不过呢，如果在刚入职场或者还没有到非常senior的position时能有好的mentor或者师长引导到正确的道路上，的确是能少走很多弯路，同时能迅速增长见识和格局，对于很多老生常谈的问题也能有更全面的认知和判断力。我看到很多新童鞋的提问，再回想自己曾经走过的路得到无数师长和朋友的无私帮助时特别感同身受。所以我愿意尽我所能提供我自己的一些data points和thoughts
我的背景（出于隐私考虑，我不会透露太多具体personal info，希望大家理解）
首先，我在标题里用了FLAGUAP只是为了隐去一些personal info，其实我只在其中一家工作过。不过这篇文章的讨论应该是比较普适的，大家不用对号入座，咱们重点还是focus在观点讨论上。其次，这是一个新的账号，原因也是隐去一些隐私相关的信息。
本科研究生都是在国内985读的CS。出国之前在阿里短暂工作了一段时间，之后因为家庭的原因来美国再读了一个CS master，用了差不多一年的时间读完课程毕业然后去了现在的公司。在过去的4年里，我参与了不同类型的核心系统design和实现，tech stack跨度比较大，从最前端到backend，pipeline，mobile，pure infra都有做过，现在是focus on pure infra的work上。另外因为技术背景的原因，我在很早期就开始参与公司非coding的interview，主要是system design和experience interview，后来也参与了很多acquihire的interview工作。在team里，除了coding之外，作为senior eng我还会花不少的时间和manager或者PM一起制定team的roadmap和priority setting，当然也会mentor很多新来的或者比较junior的同事。跨部门的协作也参与了很多，也做过很多consulting和tech review的工作。总的来说，在tech stack上我唯一没有做过的是ML modeling相关的工作 (ML infra更多的是在ML的domain里解决infra problems，算是pure infra的一个应用或者叫做platform，我的team跟他们也有很密切的合作)，所以不会也没有能力讨论任何关于ML的事情，请大家见谅～
关于转专业
在公司里我见过太多的同事是非CS本科(物理、化学、生物、英文文学、音乐等等)因为各种不同的机缘巧合或者动机最后转了CS然后可能有不同的工作经历最后大家相遇在这里。所以最直接的结论就是：转专业本身绝对是靠谱的，而且成功案例不计其数。但是，对于转专业的童鞋这里有几个必须要正视的话题，只有当你从心里认可并且决定承担可能带来的好的或者特别是不好的结果后，这个转专业在我看来才是问心无愧的。
- Opportunity Cost：如果是和本科就是CS的同学比那这个cost肯定已经是沉没成本了。但是如果跟自己的专业的未来就业前景比，有可能更多的还是opportunity。很多时候我们太容易去计较20多岁的时候那么几年在同龄人中的落后(其实也不算浪费，你也学到了不同领域的一些方法论，这里可以回顾下乔帮主的名言)，而忽略了人生是场马拉松而不是短跑这个重要的理念。如果我们把格局拉的再大点，把30-40岁这10年考虑进来就是20年，最差的结果是你比别人浪费了1/5的时间，但是考虑到顶级公司eng level只guarantee到L，L3-5按avg算4-5年的话，还有11年的时间。在30岁之后的10年里，95%的人已经没有之前的那种拼劲和动力了，生活有了更多的茶米油盐酱醋茶，也就是说竞争已经不是过独木桥了，而是根本就没有多少人打算过桥。所以与其踌躇不前，不如早点下定决心，挽起袖子就干。
- Career Interest：虽然大IT整体就业非常好，而且科技对未来社会的影响还在放大，但是并不代表其他的学科就没有未来，特别是交叉学科的兴起和Computer Aided的学科。其实我个人非常看好这种交叉学科，可以孵化出原有产业+IT=新产业，比如医疗、新农业、IOT、智能仓储运输、区块链优化隐私保护和多方合同、机械制造、无人车…这里面随便一个的market share都比今天的所谓互联网产业大很多。我的point就是，互联网不是无所不能，做你最擅长的事情很重要。
- Capability：接着上面提到的点，如果只是因为互联网现在火就想转专业到这个行业，还得考虑你自己是不是能deal with这个行业的工作方式和特点。我马上能想到的几点大概有1. 入门比较容易，但是tech depth and breadth非常艰深；2. 年轻人很多，初级工作竞争非常激烈；3. 加班或者准确说是自发加班是common sense特别是top company，因为strong peer pressure (当然也是team by team的)；4. 需要花费额外的力气弥补转专业之前的沉没成本。面试或者拿到一个好的offer是一个好的开始，但是真正hard core的事情才刚刚开始，be prepared！
- Courage：放弃自己现在拥有的一切去另外一个行业是需要很大的勇气的。你之前的积累越深厚这个代价就越高。即使转了CS之后还是会面临很大的竞争，需要有很强的毅力支持下去。所以客观来说所有决定转专业的童鞋都是值得敬佩的！
这个话题还可以展开说很多，比如回国、换个国家、从事教职等等，这里我们就点到为止，欢迎大家留言并且互相讨论。
关于面试
一个很好的版块就是面经分享或者面试心得分享，我自己也受益很多。这里我只是从面试官的角度来补充对比分析下面试的一些流程和decision making process。
-
Hiring pipeline：每一个eng candidate都是通过一个完整的hiring pipeline招进来的，company planning -> org planning -> head count allocation -> job posting -> sourcing (referral) -> recruiter engagement -> phone interview -> onsite interview -> round up (HC at Google) -> Hiring manager (org Director/VP) review -> offer -> counter offer -> sell call -> accept/decline。可能大家会问，除了面试刷题之外，其他环节跟我没啥关系，我也没有控制力，知道了有什么用？其实很有用，特别是对于industry hire和senior candidate hire来说很重要，因为最终offer decision making就是这个pipeline里所有参与的人决定的，每一个步骤都是single point of failure，fail了就没法move on了，所以对于candidate来说可以针对具体环节制定具体的策略。
-
面试结果随机性：很多candidate觉得我刷题特别厉害，所有的onsite question我都做出来了也是对的，为什么就挂了呢？这里有一个基本的信息差或者说大家都知道但是不一定重视，就是correctness和run time performance只是评价的一个方面，整个分数评价还有好几个别的方面，至少包括communication，coding quality，reasoning，language proficiency，system design和experience interview还包括technical depth/breadth, metric driven development，manager interview又有新的面试考察点比如coaching，team/org strategy setting，team health，org influence，conflict resolution etc. 我的point是刷题真的只是一个最入门的技能，这是个必要条件，但远远不充分。希望这些内容能帮助大家在刷题或者准备面试的时候能更有针对性，更系统性，而不是盲目题海战。
-
negotiation power：这个话题已经有很多帖子都讲过了，比如这篇文章。我主要从公司的角度补充下文章里可能漏掉的地方，让大家对整个process有更全面的理解和把握。
-
如果我们把hiring的过程看成是一个offline pipeline (所有做过data warehouse pipeline work的童鞋应该都了解，或者想像成a DAG of MapReduce jobs也行)，很多问题就很清晰了。上述每一个步骤就是一个job，只有前面的job完成后面的才能开始run。
-
在拿到offer之前，公司相对candidate是有巨大的话语权的。尤其是大公司，几乎每天都是很多个DAG在run。公司的goal是说给定一个result (5 HC)，100个DAG里任意5个run完就行，基本上是先到先得，极个别情况下会存储中间状态(比如在border line上的candidate)再看看有没有更优秀的candidate。所以，不要太相信公司面试成本这个事情，我不是说这个观点不对，而是说它不全面，没有从公司角度来看如果招到一个错误的人或者不适合的人对公司长远造成的损失。我所在的org之前就有一段时间在manager candidate上没有什么DAG能run完，但是秉持着宁缺毋滥的原则，大家内部过的tough点，也比来了个不好的manager对org和culture的破坏好太多。对于普通Eng来说原理是一样的。因此，大家在面试的时候一定要做足功课，千万不要随便挑战面试官或者公司的底线。
-
拿到offer之后，对于有competing offer的candidate来说，他们对公司有比较大的优势，没有competing offer的优势没那么大。但是，公司并不是一个守株待兔的状态，其实反而是非常主动的。咱们再回到上面的DAG，一个DAG接近run完了，但是最后的long tail run的很慢，也很麻烦。没关系，我还有另外5个DAG也在并行的run，只要他们其中有能成功run完就算任务完成了，前面那个long tail kill掉也无所谓。这是一个基本原则，当然case by case，遇到很特别的candidate会有不同的channel来处理的。
-
在我面过的candidate里，90%以上挂掉的原因都是非常consistent的，就是说所有给No的面试官的评价都差不多。比如有个candidate coding又快又好，结果至少两个面试官提到怀疑他背了题，要求加面，而且要求加面的面试官出那种非常生僻的题。另外一个case是candidate coding很好，但是至少两个面试官反映他的communication或者technical depth不太行，要求降level或者给低于candidate预期的level。这些例子说明mock interview通常是一个比较好的方式来检验所有这些方面的，不只是coding，大家可以多多准备。
-
综合这几点还有那篇negotiation的文章来看，这里核心的原则说白了就是demand-supply balance。negotiation永远都是需要的，而且很重要，个人比公司在心理上已经处于劣势了，再不为自己争取权益那就说不过去了。另一方面，了解面试公司的招聘现状，发展方向，火爆程度会更有效的帮助提升negotiation技巧，特别是很多recruiter对于candidate的那些negotiation skills已经很轻车熟路了，那就更需要大家知己知彼才能事半功倍。
-
有心的童鞋可能已经发现了，如果并行的DAG非常少，或者等待时间过长，candidate不就有更多的优势了吗？完全正确。所以比较冷门的position比如linux kernel engineer，或者比较高级的职位如senior manager (senior staff+ at Google)，那就完全是另一翻景象了。因此，把自己变的更加稀缺或者增加uniqueness是提高自身market value和competitiveness的不二法门。
关于Full Stack Eng vs Backend Eng vs Frontend Eng vs Infra Eng
这个问题是我在做new hire buddy和sell call的时候最常被问到的问题。有很多new grad童鞋非常关心自己的career growth，也想快速学习成长，但是不知道怎么制定自己的职业发展路线。对我来说这些role我都体验过了，也跟相应role的Eng有很多合作，可以更客观地分享一些自己的看法。当然，这些分享都是一家之言，大家兼听则明。
- Full Stack Eng：前几年startup很火的时候最受欢迎的role之一。这个role是一个多面手，一般是做具体product的，根据team分工可能有所侧重，但大多数都能cover from frontend to backend。在产品开发的早中期为了快速迭代，FS Eng能够和PM、Designer一起快速推进，奠定MVP，然后获取用户再不断grow。这个角色最明显的坏处是容易deadline driven，受product progress影响很多，另外自身很少有时间去打造更成熟或者更复杂的东西比如company/org wide framework或者最新最前沿的技术探索等等，通常都是使用现成的工具。
- Frontend/Backend Eng：在前端或后端有比较深的耕耘。一般在product非常成熟的org或者team里出现的概率比较大。打个简单的比喻，可以理解成一个大型service被break down成多个小service，然后他们就可以分别优化和scale。好处当然是你可以把自己的领域做的非常精深，坏处就是会过于focus，不太容易有full picture和大局观，这点在越senior的职位上体现越明显。
- Infra Eng：一般来说一个公司最core的工种，尤其是成熟的大公司。好处是解决的问题的scale远远超过市场平均水平，视野会比市场看的更远，也容易引领技术市场的发展，比如Google open sourced Kubernetes, Istio, FB open sourced React etc. 坏处就是离product比较远，有的时候product sense不够，不能collaborate with product teams well。
当然，每一个role都还有很多细分，每一个细分还有独特的地方可以探讨，比如Dev Infra，Data Engineering，这里就不深入了。回到最开始的问题，一个new hire特别是new grad应该去什么样的team或者做什么样的事情？我个人认为最重要的几个考虑方面是：
- 选择老板：跟一流的人做事，可以把二流的产品做成一流的；跟二流的人做事，会把一流的产品做成三流的；跟三流的人做事，可以把任何产品做死。
- 选择team culture最适合你的：team加班比较多，但是rewarding也很好，是不是你的style？team work life balance很好，但是机会寥寥，这又是不是你能接受的？
- 选择team structure合理的team：一个10个人的team有5-6个senior eng，没有或者很少L3、L4，或者只有1个L5+，其他全是L3，他们之间的dynamics是很不一样的
- 选择有不同可能性的project：这一点又是由第一和第三点一起决定的。
- 选择能帮助你职业成长的team：比如我想当一个product team manager，那我需要培养很多data sense，product sense；又比如我想在技术上有领导力或者lead infra team，那strong technical skills就很重要了。
最后一点，每一个阶段的选择都不是永久性的，一般来说在现在的岗位做过一段时间之后，如果到达了一个瓶颈期或者自己产生了厌烦情绪，大公司里都是比较容易允许transition team或者switch function role的。当然我也有听说有些公司在这个问题上有很多猫腻，这个多和过来人聊聊，提前了解下。
Performance Review & Promotion
这个话题一般非常带有political的味道，特别是Level越高越明显。这篇文章还是focus在L6以下，还是有很多客观的东西可以follow，再高的Level楼主也没有经历过，没资格点评。。
- Perf Review有两个评审维度，第一是跟公司制定的Level-Rating标准比，第二是跟你所在org的peer比。这两点综合起来会决定你的ranking on rating list.
- 所有Perf Review都有Calibration，对于低Level的case来说就是manager给出一个initial rating，然后calibration committee会通过讨论和辩论来修正rating，可高可低，通常是往低的走。
- 每个公司都有一套严格的职级标准，虽然有些差异，但是原则上对于各职级的要求是差不多的。L3: 在一个well scoped project里，能够deliver excellent results with some guidance；L4: 在well scoped project里，能够deliver excellent results independently；L5: project is not scoped，senior eng需要scope out project，deliver excellent results with mentoring a few junior engs. L6: no problem is defined. senior eng需要identify和select right problems to solve，然后scope out什么project可以解决这些problems，最后做到L5需要做到的事。当然，每一级的scope都是在逐步扩大的，不可能说L5做一个feature work就能justify这个level和rating。更具体的要求比如technical difficulty，leadership，mentorship这些话题就更大了，有机会的话以后可以单独讲讲。
- 通常manager给的rating不会是cycle结束的时候才拍脑袋的结果，
而是在整个cycle期间就差不多形成了。这样的feedback loop其实有点长，容易产生unexpected surprise，对双方都不太友好。在我所待过的team里执行了一种叫做half-cycle informal perf review的process，每三个月一次，整个流程的前半段跟formal perf review一样，主要目的是收集和传递constructive feedback，这样每个eng可以更快的得知自己当前的状态和peer的评价，好做相应的调整。除此之外，好的manager一般会主动提一些工作上的建议，technical或者non-technical的，好帮助下面的人更好地成长。
- 通常一个正常的team都会有比较senior的所谓tech lead，他们的观察和perf review对manager了解下面的人的水平是有很大的参考作用的。如果你是刚来team的新人或者职级比较低，那么除了manager之外，多跟team里的tech lead或者senior eng交流和主动索要feedback是非常有意义的，能帮助你尽早修正航线，并且他们也会乐意分享宝贵的经验。
当然啦，因为perf rating和promotion涉及到随后的薪资调整、权力或scope变化、人事调整等，每个人对其公平性和是否reasonable都有自己的看法。这里我就不深入讨论了。
总结
这个帖子里我们主要讨论了转专业、面试、新人职业发展、Perf Review & Promotion，主要focus在道的层面，术的东西有太多personal的东西，比如机遇、运气、家庭原因等等，没法讨论也很难总结。当然除了这些，其实还有很多特别有趣的话题可以讨论和发散，比如PM, Designer, DS和Eng之间的合作与制衡，如何解决cross team conflict，mentorship的技巧，什么是leadership等等，这个帖子算是抛砖引玉，以后有机会可以再讲讲。总的来说，我的核心观点是对于入行不久或者停留在比较低的level但又不知道如何提升自己的朋友，CS的工作真的远远不是刷题 -> 争取一个好公司 -> 争取一个好team -> 继续写code这么简单，这样的操作基本最多就在L4的水平了。越往上走，越需要视野格局和找到对的榜样。如果你的team或者公司有很多这样的人，那么非常恭喜你有这么好的外部环境支持；如果没有这样的榜样学习，我的建议是either step up to take more impact and accountability or go for another better place，但是不管怎样都不能原地踏步。忘了马拉松那个观点的童鞋可以重新读读转专业那一段，当你选择原地踏步那一刻起，其实未来的命运就基本注定了。但是只要坚持不懈，不断寻找新的个人增长点，人生的长跑就永远没有结束，新的机会也会在未来的某个时刻不经意地来到你的身边。与君共勉！
