Team * [Team Scope] What is the scope of your team, (or how do you divide your scope into) * [Team Goal] What are the goals for this year? How do you prioritize them? * [Team Goal] What is the vision (near future / 1 yr / 3 yr ?): * [Team Process] What are the current tech debts, how do we mitigate them? * [Team Process] Do you have oncall / onduty? * [Team Process] Link to your Team page? * [Team Satisfaction] What is the team member rotation rate? * [Team Process] In case people leave, how do you keep his knowledge and ramp up a new team? Project * [Project Description] What will I be doing in the first half year * [Project Description] What will I possibly work on in two years Growning * [Member Growth] Growth plan for Ln to Ln+1 * [Personal Growth] What can I learn from team members * [Member Growth] Your own growth plan (career plan)? Management * [Management style] What is your management style? * [Management style] What topics do you talk with team members in 1:1 * [Management style] How do you see the balance between shipping fast and shipping w/ high quality? * [Management style] Your Googlegiest/Pulse/Survey result? Others * Any questions you recommend adding onto this list?
6.3 和组员1:1 这一章节是临时加上来的，突然想起来和组员问的问题与和老板问的问题不太一样。放一下我自己的问题列表： * What is the ramp up process? * How are your tasks assigned to you? Anything that is forced to be assigned to you? * Do you have a clear roadmap? * How often do your team hit hard deadlines? * Anyone working overtime? * How much does your manager talk with you about your career in your 1:1? * Does perf look fair to you? * Are you happy with your team? * What did you learn here
1. 明确你的需求
换组选组跳槽，大多数都事出有因。很多换组的同学都是因为老板或者组实在是呆不下去了，老板不帮忙，排挤，组里TL把组往阴沟里带，学不到东西，整天倒水搬砖填天坑等等。一个好组通常也会有一些问题，比如技术栈复杂老旧代码多，老板管人太多不会在每个人身上放太多时间，组里做新产品新功能压力大deadline多等等。没有一个组是完美的，所以要明确需求，看自己需要什么，对于什么样的问题可以忽略不计。
下面这些核心问题是我觉得必须要想清楚的
* 你的长久计划是什么
* 你在这个组想要学到什么
* 你在这个组会如何成长。不止是技术上的成长，也有沟通技能，管理水平，大局观之类的非技术技能的成长
* 你对这个组的项目有多感兴趣
* 你在这个组会不会待得开心
其中最难的问题应该是长久计划，这个问题明确了，之前的问题也能迎刃而解。比如有些人想走技术选TL路线，或者想走产品路线，或者管理路线，需求都是非常不一样的。在完成接下来的选组看项目聊1:1 之前，一定要把自己的需求明确好。
2. 选组清单
接下来就是在内部换组的网站里面挑选自己可能想去的组了。一般大公司都会有一个内部job posting的网站，我在选组的时候，第一轮我没有给自己选定方向，大概除了不
做纯frontend不做machine learning，只要符合我的level，工作地点在南湾， 是
software engineer的岗位我都大致看了一下。除此之外，之前的TL和走掉的大manager也非常nice，给我推荐了好几个组，并且他们还告诉了我哪些org内部相对混乱不要去
，哪些比较好推荐的。最终筛选出来30多个candidate。虽然这第一轮选下来的很多，
但是我谈的组并不多，具体就是因为下一轮的打分和筛选只留下了几个最想去的组。
建议把这些组和信息放到一个Google sheet里面方便管理，也方便追踪自己选组谈组的进度。里面列举了项目名称，地点，manager，项目类型，每个老板1:1 question doc 的link，还有初步打分和最终打分，详情请移步这个Google Sheethttps://docs.google.com/spreadsh ... nhuqa9So/edit#gid=0
3. 好组/好项目的表现
这一部分无论大公司和小公司都会适用。里面可以说的东西太多了。如下排名不分先后，如果大家有什么想法的话欢迎补充。
3.1 团队操作流程和文档 （Team Process）
每个组都或多或少有non coding或者ops的工作。launch ticket（或者post），代码有什么merge的规范，monitoring或者oncall，release和rollback，做experiment，基本不需要多少coding，但是有具体的操作流程。一个好的组会把这些流程详细记录下来，做成一个正式的team page，实时更新。新人来了之后只需要照着doc就可以学会大部分流程。而一个不好的组，通常没有任何doc，哪怕有也都是过期了很久没更新过，这些
流程基本都是需要老人来带，没老人手把手交个机会都不敢自己上手。
另外，文档是一个对于team velocity来说非常重要的东西。文档的作用在于把知识留
到团队而不是团队中的某一个人身上。平时可能大家都不觉得有什么好写的，但是一旦有一个呆了几年的人想跑路，没有充足文档的情况下，老板最头疼的往往就是
knowledge transfer有没有做到位，尤其是那些只有老人懂的legacy system。根据我
的经验，很多项目走人之后一点点垮掉，就是因为有能力带这个项目的人，或者项目的owner跑路了，东西没人有能力维护，更没有人知道之后这个项目该怎么做。没了相关
的知识背景，自然这个project就没人能做下去。虽然说所有软件系统最终都会慢慢腐
蚀掉慢慢成为tech debt，但是没有好文档，知识全靠口口相传的话，这种项目垮的会
更快，组里的tech debt也更多。
3.2 团队技术水平 （Team Professionalism）
如果想多学东西的话，团队技术水平很重要。如果一个组里有一个能打的大佬，学东西最快最好的方法就是抱紧这个大佬的大腿。一般一个组至少要有一个这样的TL，这个人要了解系统的每一方面，甚至需要了解的非常细致。对于组内的design review，TL可
以提出很多建议，并且要至少把握住团队技术走向。TL不一定写多少代码，但是很多
proof of concept，很多搭架子的东西都是这个人做的。有TL在，组里的product
quality才有保证，大家做出的东西能对组对于org 的goal带来长期的好处，而不至于
为了一个goal，做一个project， 不久就deprecate再换下一个。大公司内一个成员的
主要工作还是拧螺丝钉，这样的TL可以保证大家拧的最有效率质量最高。
当然团队成员的平均技术水平也很重要，这个就不是很好评价了。不过可以通过大家交的代码，写的doc来略知一二。
3.3 团队满意度 （Team Satisfaction）
团队满意度有一个直观简单的标准，就是这个组的人员流动率。走的人多了自然肯定跟组里风气差，或者org搞事情有关系，但是如果大家promo都快，wlb不至于太差，并且
老板对于组员很好的话，大部分人是不会换组跑路的。
3.4 个人成长空间（Growth）
这个很大程度取决于个人需求。如果追求升职的话，L4进了一个全是L4L5L6的组自然是很吃亏，好的活论不上，想要论上也得等ramp up完或者做出点什么取得manager的信任，这时间大概率不会很短；但是如果主要想学东西的话，这种组反而很适合，L5 L6的
人本身往往就很有经验，跟他们学东西会比自己摸索快得多得多，而且减少了很多试错的时间，往往他们解释问题的时候会解释为什么会产生这个问题，扯到一个项目的发展历史，去除糟粕留下精华的过程，这对技术水平的提升帮助是非常大的。
或者比方说想要自己出去做product，在公司内找一个product组，组里工作跟PM交流紧密，同时有完整的实验流程，对于feature该不该做，做出来效果好不好有详细的数据
分析，launch之后也能给eng分一块蛋糕；想出去创业，就去一个新组，impact大的同
时，还能了解一个新产品是怎么一步一步走起来，项目初期要怎么做需求分析，怎么和PM沟通，都需要哪些人参与什么项目，如何争取资源或者跟新转来的同时合作。
3.5 老板管理水平（Manager Management Skill）
对于刚进组的L3 L4，最重要的因素之一就是老板好不好。如果老板懂得如何管理组员
，如何抢到好scope好project，如何让组员满意的话，对组员的帮助会非常大。我比较喜欢的老板能做到这些：
* 一般management style都偏向以组员为本，比如1:1的时候主要关心组员的心情而非
着重于工作内容，因为工作内容在scrum meeting上面都能涵盖到。之前聊过一个老板
的观念我很认同：他和组员1:1首先关心的是员工目前开心不开心（5分制），如果不是很开心的话，会具体问原因。我个人觉得对于老板来说，在公司最大的财富就是手下的组员。如果能调动组员的积极性的话，维持组员的好心情，对于一个组的效率提升有很大帮助。
* 如果组员遇到blocker，老板能够调动手边的资源，或者跨组和对面的老板协商把事
情搞定；
* 能吵架，开会的时候有能力把好的scope都尽量抢过来分给组员；平时大家任务很多
，老板心里面有一个非常清楚的优先级标准，并能组织大家把注意力集中到high
priority的项目，对于优先级低的可以踢出去；
* Perf（PSC）上可以帮助你review你的package，并且以perf committee member的角
度提出意见。我之前的老板看我的perf package就是good good good了事，现在的新老板我跟他1:1看perf讨论了一个多小时，他从他自己的角度对我每一句话每一点都讨论
过一遍，并且能帮我把我的package和ladder requirement对上号，并且提出了不少我
没想到的问题（尤其是中国人不擅长的书面表达，有些句子别人的理解跟我们的理解是不太一样的）。
* 了解每个组员的优点缺点，和大家的发展规划，并对每个人的规划都能有所帮助而非仅仅“知道”
* 对于组里有一个很清晰的核心价值和愿景。这两个东西概念很虚，但是用处很大。很多老板很多组往往是来一个项目做一个项目，在实现上也非常短视，能解决问题就行，能hack就hack，实在不行过一阵deprecate。个人觉得产品组可能会赶deadline，但是
没有一个长远的发展目标和价值的话，所做的一切都在追求“局部最优”而非“全局最优”。不重视quality，不管eng累不累，东一耙西一耙大力出奇迹的管理方法迟早会让组里乱套。一个组应该追求的是，寻找组里在外部环境org的goal如何变动都能位处不
变的东西（比如产品组的customer empathy，狗家一贯注重的quality，和提高组员生
产力的collaboration和build trust），要这样才能让team相对良好地发展。
3.6 老板技术水平（Manager Technical Skill）
很多组里并没有专门的TL，往往老板就充当了TL的角色。这种情况下，老板的技术水平就很重要了。比如做product的组，经常拿到的项目都带有hard deadline，要在什么会上present，答应了customer什么时候ship，时间紧急的情况下，技术水平到位的老板
能平衡项目的质量和速度。另外对于team growth，好老板往往对team有全面（不一定
细致）的了解，知道项目以后可以怎么走，有什么样的发展点可以用上，更好的老板会对组里的目标有长远的（1-3年）规划，即使项目或者需求有变更，也能做到大方向不
改变，不浪费eng hours。其他的跟一个好TL的评判标准相似，这里就不多说了。
4 制作打分表
每个人对于上述表现的评判标准都不一样。因为考虑的因素太多，为了避免比较过程过于主观，下面提供了一个量化的打分表模板 （还是上篇的那个表格，暂且不放出来，
看看上篇是不是因为放了这个链接被审核了）
首先在这个Google Sheet的Scoring Template里面修改Weight一列。这里现在放的是我自己对于每一项的权重，对于好老板，好项目和有前景能学到东西的组我的权重都差不多，如果有额外看中的点（比如说做machine learning，是在某个你喜欢的org有你认
识的人之类的），也可以单独加一条上去，别忘了改总分公式（Total一行）。每一项加权得分这里用原始得分（我一般会用10分制）乘以该项权重再除以总权重来算。
打分表模板做好了之后，对于每一个组都建议单独添加一个sheet，然后把打分表的模
板复制过去。等背景调查和1:1做完之后，只需要填写Raw Score就能自动算出来这个组的加权得分。
5 项目背景调查
在1:1 和聊组员之前，有很多背景调查可以自行完成，通过背景调查就能把组里的事情大致了解的七七八八，还能交叉检验老板口中套到的信息。一般大公司内部公开的资料非常非常多，比如狗家的code review系统（和clstats），很多现成的query scripts
，还有team公开的邮件列表，ticket system，g3doc文档网站，里面有太多东西可以自己挖了。在背景调查完成之后，可以结合自己的需求，给选组清单（见上篇）中每一个组打个分，排序后选得分最高的几个来跟老板安排1:1
5.1 团队工作压力
如果一个组有超过2个人是工作狂的话，对我来说是半个减分项。一般就看看大家交代
码的频率和时间，如果有那种晚上6-12点还交一大堆代码，甚至交代码统计从早晨9点
到晚上10点几乎平齐的这种人，一个两个无所谓，但是如果超过2个那这个组的工作压
力可能就过大了。要么是事情太多，事情太多的根本原因是这个组planning做不好，揽来的活超过了eng capacity。一些eng主动加班是ok的，但是如果影响了整个组的风气
，我个人不太喜欢。我自己有选择加班与否的权利，如果不加班我完全可以看看doc，
做做别的系统的codelab，或者自己看看视频是什么的，如果因为peer pressure被迫加班，首先效率无法保证，健康肯定也有影响，同时完全失去了自我提高的机会（我认为习惯性加班对长期自我提高没有任何帮助，并且危害不小），这样的组我会给一个比较低的分。
5.2 团队成员技术水平
至于组员平均技术水平不是很容易看出来，并且每个公司怎么看出入也挺大的。狗家的我主要就综合看每个成员的level （FB看不到这个），交代码的comment数量（一般应
该没多少，但是如果是TL review的话comment有可能不少。不知道除了狗家其他公司
code review做的怎么样），各种doc的数量和质量（狗家非常重视doc，虽然给人看的
doc往往写的烂的一笔，但内部很多不错的design doc，并且好的design doc和一般的
design doc还是挺容易看出来的。外部doc烂主要是因为technical writer太少了），
在组内的tenure，综合这些因素评判每一个人的技术水平。
5.3 团队满意度
狗家有一个内部公开的数据库可以查一个人谷歌内部所有的management chain历史，也可以查一个manager所有手下带过的人什么时候来，什么时候走的。这是了解一个组组
员满意度最重要最直接的标准。好像FB也有这么一个地方查老板手下带过的人，知情的同学可以分享一下。另外，如果走掉的组员还在公司的话，可以ping一下组员了解一下为什么要走。看组员满意度看优点用处不大，但是了解缺点很重要。跟manager 1：1的时候，几乎没什么manager会提到组里有什么缺点，但是走掉的组员心里是最清楚的。
可以ping一下他们，发个邮件，他们往往都会告诉你。有些人是因为家庭原因或者其他个人原因，但也有不少人是因为组里实在太差了。如果有两个以上的人对组里不满意，这个组的人员流动率也不会低。
另一个重要信息来源就是公司每年的survey。Google的Googlegiest，FB的Pulse，一般每个公司都会有这么个东西来让高层了解公司内部对于公司发展的满意度，并且根据结果来调整公司的管理策略。在谷歌，这个结果并非默认公开给所有人，但是换组的时候是允许向新的manager要这个survey结果的。好的manager会很爽快地掏出来，他们可能不知道怎么share，但是肯定会通过各种方式share（如果结果好看没道理不share）。
如果跟manager聊下来感觉不错，但manager用各种理由推脱不交的话，就得小心了，好好的。在survey里只需要具体关注个team和technical相关问题的结果就行了。
6 和老板和组员1:1
6.1 让老板了解你
很简单，丰富自己的简历，如果是换组的话，着重突出在公司内部的贡献而非来公司之前的贡献，同时一定要假设读我们简历的人对我们简历上的项目了解为0 （有些人在简历上写了很多缩写写了很多和组内项目相关的代名词，别人大概率看不懂）。跟老板发邮件聊天的时候，也可以把简历内容稍微带一点点。
6.2 该问老板什么问题
这一步主要为了获取公开资料里没有的一部分，或者交叉验证一下之前背景调查获取的信息。比如组里如果很多人加班，但是老板说组里WLB很不错的话，那要么是老板根本
不了解组里，要么就是老板故意隐瞒问题。不过我不建议在1:1时做太多的交叉验证，
因为本来1:1就只有半个小时，大部分时间应该花到了解组内成员和工作范围上面。
一般除了和老板1:1，我也会至少选择1-2个组员聊，其中一个是组里相对元老的或者比较偏TL的成员，另一个会是跟我等级差不多的组员。和TL聊天主要聊一聊组里技术的发展方向，之后有没有什么重点要做的东西，同时也问一问组里tech debt之类的问题。
跟等级差不多的组员主要聊他们现在在做什么，对组里的满意度，老板怎么帮助组员成长之类的问题。如果条件允许，我还会找一个之前从这个组换走的人发个邮件，大致问一下从组里离开的原因。
和老板1:1之前，我给每个老板都准备了一个问题清单，让老板大致准备一下我想要了
解的东西。有些比较好的老板甚至会在开会之前就把他们的对问题的看法提前写到我的清单里。
Team
* [Team Scope] What is the scope of your team, (or how do you divide your
scope into)
* [Team Goal] What are the goals for this year? How do you prioritize them?
* [Team Goal] What is the vision (near future / 1 yr / 3 yr ?):
* [Team Process] What are the current tech debts, how do we mitigate them?
* [Team Process] Do you have oncall / onduty?
* [Team Process] Link to your Team page?
* [Team Satisfaction] What is the team member rotation rate?
* [Team Process] In case people leave, how do you keep his knowledge and
ramp up a new team?
Project
* [Project Description] What will I be doing in the first half year
* [Project Description] What will I possibly work on in two years
Growning
* [Member Growth] Growth plan for Ln to Ln+1
* [Personal Growth] What can I learn from team members
* [Member Growth] Your own growth plan (career plan)?
Management
* [Management style] What is your management style?
* [Management style] What topics do you talk with team members in 1:1
* [Management style] How do you see the balance between shipping fast and
shipping w/ high quality?
* [Management style] Your Googlegiest/Pulse/Survey result?
Others
* Any questions you recommend adding onto this list?
很多问题如果在team doc或者某些slides里面已经能找到答案的花我就不会问了。每一个问题我考察的点在于：
Team Scope + Goal：
老板对于一个组当下状况和日后的大方向是否有把握。大部分组都会遇到需求频繁变更，无法把握大方向的问题。我认为，好的老板能至少了解整个org的大方向，甚至能有
一个以文档形式存在，和组里senior，TL，大组manager或者director讨论过的大方向
。有时有deadline赶deadline没什么问题，但如果一直在赶ddl，那就有问题了。或者
如果有些老板没有这样一个文档，但是对之前org的发展历史了解的很清楚，知道之后
org的大方向的话也可以。除了定大方向之外，定goal，调整优先级也是个很重要的项
目。可以问一下老板最近有没有什么项目是优先级很重要，为什么有这么高的优先级之类的。
Team process：
一般这个内部搜索都能找到，比如文档啊，oncall的频率，oncall ticket多不多，不
知道的话问一嘴也没什么大问题。另外tech debt每个组都有，但是好的组里面，老板
会想让组里会尽量减少tech debt，并且有计划地处理先前的tech debt。
Team Satisfaction：
我一般都会先查好这个组的人员流动情况，然后1:1也会同时问问老板之前组员离职率
做交叉检验。有些离职率高的组，一整组的人两年内都跑光了（就是我们组之前的状况。。。）。另外也看到过有些组，3年内几乎一个人都没走过，并且来了好几个人也都
没走，这种就比较好了。另外这里一定要要公司调查的结果，就是类似于Pulse，
Googlegiest这些能详细反映组员对组里满意度的资料，我认为这个survey的结果和内
部查到的组员流动情况是对这个组组员满意度最好的资料。
Project description：
基本就是检查一下老板对项目的描述和内部posting上面的描述是否一致了。有些
posting其实写的非常不清楚，也没怎么说进组之后会做什么，用什么样的技术，多大
的项目什么时候要做完之类的。往往可以用1:1跟老板要一下项目的详细介绍。
Growth：
一对我来说老板的个人水平非常非常重要，所以这是我用来考察老板个人水平的一个很重要的问题。一个好的工程师要对自己的职业发展有个清晰的规划，那一个好老板肯定也要有对自己的职业规划。有些老板可能会把这个问题误解为对组员对这个组有没有什么发展计划，这时候要提醒老板，我们问的是老板对自身的职业规划。
Management：
老板的管理水平几乎就决定了这个组是否有前途，同时对组内技术栈的了解程度也为扩大自己组能拿到的项目，和在定goal会议上吵架有不小的帮助。老板和组员接触最多的时间就是每一周或者两周的1:1，对于组员来说这是跟老板交流的最好时机。我会大致
了解一下老板在1:1的侧重内容。我不太喜欢在1:1纯聊工作的老板，首先我自己对我自己项目的时间和进度规划肯定有充分的把握，而且一般老板也不可能了解组里面每个人每个项目的进展，很少能有老板对组里每个人都了解的很细。我比较喜欢相对更关心组员的老板。扯扯生活上的鸡毛蒜皮可以让老板了解你的心理状况，同时如果有blocker
我认为也没必要只在1:1提（除了是1:1上面突然想到的）。现在这个老板对于1:1的态
度是，先让我把我想说的想问的都说完，等充分解决了我的问题之后再聊他想知道的问题，这我觉得挺不错的。另外一个老板的技术水平其实和他在组里的工作年限关系不小。工作的久了，积累的不仅是经验，拿到问题知道该是哪个人，哪块项目有关；更关键的是积累了充分的人脉，大家都认识你，知道遇到这个问题该找你，相信你能帮忙，这种信任也是一个老板能力的体现之一，并且年限短的老板很可能就没多少这样来自同级之下其他组的信任。
另外，记得要Pulse的结果。
6.3 和组员1:1
这一章节是临时加上来的，突然想起来和组员问的问题与和老板问的问题不太一样。放一下我自己的问题列表：
* What is the ramp up process?
* How are your tasks assigned to you? Anything that is forced to be assigned to you?
* Do you have a clear roadmap?
* How often do your team hit hard deadlines?
* Anyone working overtime?
* How much does your manager talk with you about your career in your 1:1?
* Does perf look fair to you?
* Are you happy with your team?
* What did you learn here
一般组员对与大组发展方向了解的都不深，所以这里主要问组员对于这个组方方面面的满意程度。组员的回答会更加主观一些，但是因为组员提起某些问题的时候。他们往往有发生在这个组里的活生生的例子，所以我认为这些回答的价值更高一些。我主要会问组员对于组里工作压力，升职预期，项目分配等问题的看法，最后了解一下组员对这个组是否满意，有没有对自己有所发展。如果你有其他看法，可以多加一些你自己的问题。
6.4 完成打分
回到先前的那个Google Sheet。建议在1:1时收集好组员和老板对组里的评价还有自己
的背景调查，打分的时候，最好不仅给出每个组每个项目的原始得分，同时给出每一项得分的加分点减分点，这样不仅能客观地给每个组排名，更能更明确自己对不同项目不同管理风格的偏好。最后，统计最终得分后，尽快跟对面的老板确定意向，往往对面老板也在面试很多人，尽早定下意向可以提高最终被老板选中的概率。
7 总结
换组选组是件麻烦事，往往选择少了觉得选不到好组，选择多了又怕挑到的不是好组。多花点时间多留点耐心，毕竟选组花的一周两周对之后一年甚至几年的个人发展都有很大关联。希望大家都能选到喜欢的项目，有能力的老板，让自己的职业生涯得到快速发展。
good post!
mark