老习惯，开个学习贴，学办公室政治和管理

Resources:
Rands http://randsinrepose.com/archives/category/management/
Radical Candor: Book & Podcast
HBR Guide to managing up and across沈公子：人家的屋顶
. 1point3acres.com =================================

quote from 沈公子：人家的屋顶
（各级的研发管理，到Senior Director为止）管理什么：
除了处理人事(就是口碑堪比五仁月饼的“people management”)，
EM要参与制定产品长远计划，协助搭建技术架构，预估工程量，制定优先级，处理跨组跨部门的。
要负责招聘，组建合适的团队，推行健康的工程文化，优化团队效率。
有些时候则要考虑拆分重组以期达到与产品商务市场等部门的高度alignment。
职业规划(career planning)培养人才(people development)也不能占用EM的所有时间

Storytelling in interview:
比如说，你是line level manager，可以谈谈你如何transition为啥transition，然后怎么let go你的technical responsibilities，怎么找到接替你的TL，或者你怎么从一个不是组里最资深的engineer转变成EM然后manage原本比你资深的peers。你就讲你的故事，面试官会去归纳你转EM的动机和你对这个职能的理解，不需要刻板的一问一答。Let go tech ownership, find successor TL这些看似是你经历的事，其实映射的都是管理理念！再来，假如你是个senior manager，那不妨谈谈你管理的各个组之间的联系和区别，谈谈你如何diversify your plate，如何context switch，然后有没有开始培养first level manager，怎么跟PM合(撕)作(逼)等等。把一个组的scope扩大，或吞并或拆分寻求资源最合理利用是你想要呈现的“卤蛋”，但是如果不放在“拉面”里一起端出来，索然无味。到了director level，要讲怎么定义自己的org了，为什么这么划分，跟其它org在技术架构和组织架构层面的关系。比如你是管infra的，那肯定要讲如何服务internal customers如何把cross-org dependencies体现在你团队的planning中；什么时候centralize solution，什么情况下让product-eng teams自己做，个中得失trade-off。工程文化和运营规范也是你必须要想过的事，而且不能只有教条，得有落地的事例。然后你的剧本里要有business context，最好请些Ops, BD, Marketing, Recruiting的配角来衬一把。

EM的故事越个性化越令人信服，下面分享一个真实的案例。S君要新建的组成天和analytics org打交道，斩不断理还乱的关系。然而analytics那边招人放水，S君这边engineering面试bar高很多，一时出现了S君一个寡头司令要带领一群不属于engineering org的analysts工作。眼见整个项目的人总体technical depth捉急，S君想出依靠contractor consultants暂补空缺。实际操作的难度可想而知，但却是可遇不可求的组建团队和跨组合作的经历，面试时拿出来讲，妥妥地展开很多话题。

https://mp.weixin.qq.com/s?__biz=MzIwNTQ0OTg4MQ==&mid=2247483651&idx=1&sn=fab9b406b119544d4067eedc5aeda163&chksm=9731fef5a04677e3c02ff7393b813cac33409e8dcdb87dbc6e62aa97f71f0da4bd24658021a6&3rd=MzA3MDU4NTYzMw==&scene=6#rd

沈公子面经之Senior/Staff SWE

2017-01-15 沈公子 人家的屋顶

以前软件公司对工程师等级评估考核各自为营没有统一的规范。有些地方升职可以单靠熬资历，而另一些公司则卡得特别严。近年来很多公司慢慢开始采纳和Google匹配的工程师职业等级规划 (Engineering Career Pathway)。

Google系的工程师等级大致是这样的。

T3
Software Engineer II (entry level, 其它公司一般叫 SWE I)
T4
Software Engineer III (其它公司一般叫 SWE II)
T5
Senior Software Engineer
T6
Staff Software Engineer
T7
Senior Staff Software Engineer
T8
Principal Software Engineer
T9
Distinguished Software Engineer
T10
Fellow
T11
Senior Fellow (专门为Jeff Dean增设的)

T6是广大码农的一大目标，被视作职业发展早中期的一个里程碑。再往上就接近金字塔顶部了。许多公司T7+的比例不到15%。一般3-4年很多童鞋就到了T5，T5升T6的经历variance却很大，不少人一直达不到。大多公司也接受engineers可能stuck在T5上的事实(若是很多年依旧达不到T5是要被放PIP的，performance improvement plan的)。

在公司内部，T5和T6的分界线往往不是很清晰。经常能看到顶着T6头衔打酱油，贡献还不如T5的。但是跳槽面试，T5或T6的leveling跟面试表现就直接关联了。大家都知道考design/architecture是公司评估candidate是否达到Senior+ level的关键, 也是面试官衡量candidate是否有充足tech lead经验的时候。

举个栗子－我之前的团队负责filter推特上的垃圾信息和违反产品用户协议的帖子。面试的时候如何介绍这方面的技术架构，我们看一下几种不同的呈现方式。

Take 1
I worked on the real time content filtering project and was responsible for the mechanism of hiding spam and abusive tweets from the recipient's timeline. We had two choices -- (1) every time we construct a timeline, call the Safety service and pass ids of every tweet; the Safety service would return a potentially filtered list; or (2) every time a tweet is identified as spam or abusive, write the verdict as a piece of metadata to the tweet storage; the metadata is checked on any subsequent read. We chose the latter because the former would have led to extremely high QPS on the spam systems, i.e. high hardware cost and sophisticated reliability work.

Take 2
I worked on the real time content filtering project and was responsible for the mechanism of hiding spam and abusive tweets from the recipient’s timeline. One key architectural decision we had to make was between a pull model (call the Safety service every time a timeline is constructed) vs a push model (the Safety system writes the verdict of each tweet to DB). Even though the pull model follows the service oriented architecture (SOA) paradigm, it is not a preferable solution because it’d require the Safety service to scale horizontally to handle the total read volume of the site and be on the critical path of each read request. The push model leaks some business logic, but is a reasonable trade-off since the chance of a tweet going from good (on creation) to bad and needing a verdict update is very slim. To ensure consistency in interpreting the safety verdict of a tweet (which can be a struct as opposed to a simple boolean), we provide a library that other services can import.

Take 3
Before we dive into the technical details, let me first explain some of the product desires that affect the architectural decisions. The tweets to filter are in two categories: (1) clear violation of ToS; (2) unwelcomed contents to the recipients. While the action against the former case is straightforward -- we simply do not want/allow such contents on the network, the solution for the latter is more complex since it is perspectival. In other words, the visibility of a tweet is not just a property on the tweet object but varies according to whose timeline it would appear on. It is also worth noting that the overwhelming majority of tweets are good and need no verdict update or filtering. Only a tiny percentage of tweets would receive a negative verdict. And the identification may take some time, i.e. the verdict may not be available on tweet creation. But as soon as a tweet is identified “bad”, we need the filtering to kick in immediately.

With the requirements in mind, we first made a choice between the pull and push model. Even though the pull model follows the service oriented architecture (SOA) paradigm, it is not a preferable solution because it’d require the Safety service to scale horizontally to handle the total read volume of the site and be on the critical path of each read request. In that case, we would probably need some caching, but the presence of a cache means lag in filtering. The push model leaks some business logic, but is a reasonable trade-off since the chance of a tweet going from good (on creation) to bad and needing a verdict update is very slim.  To ensure consistency in interpreting the safety verdict of a tweet (which can be a struct as opposed to a simple boolean), we provide a library that other services can import.

This worked well until recently when the perspectival check became complicated enough to involve multiple rpc calls to a number of services. The library interpreting the verdict metadata now requires not just unit test but integration and stress tests.

三种表述关键内容都是一样的，但立意不同可以体现平时工作的scope。强调paradigm展现的是理论知识，至少T5 tech lead的质素。从产品要求谈起，虽然有点答非所问，但是表达的是你对产品的拿捏(product acumen)。

https://mp.weixin.qq.com/s?__biz=MzIwNTQ0OTg4MQ==&mid=2247483662&idx=1&sn=fda079583f69fa9706ce2da84d4c9682&chksm=9731fef8a04677ee65556d27f2c1a3bdbdd0a4eed2fffa8d3dbf8e97fff25b9fa706e8f553eb&3rd=MzA3MDU4NTYzMw==&scene=6#rd

沈公子面经之TL/EM

2017-02-09 沈公子 人家的屋顶
这篇文章写给做了EM (Engineering Manager)没多久或是较长时间TLM (Tech Lead Manager)的并打算跳槽去有一定规模的公司的童鞋们。比不得书中黄金屋，实践随笔而已。



面试EM和SWE position的区别就好比演讲的不同风格。Slides上密密麻麻都是字，条理清晰地Section 1, 2, 2.a, ... , 3.b.i, … 是一种风格。这种风格对应的是software engineer面试，因为有知识框架有题库，大家准备的时候套路比较一致，所以也有培训班(这里插播广告：包子培训 baozitraining.org，联系人小雨石)。另一种non native speakers不容易handle的演讲方式叫story telling，就是slides上几乎没有字只放图片，而且很多时候是抽象概念的图片。演讲者完全不照本宣读，slides只是辅助作用。TED的演讲大多是这个型。Story telling对应的是EM面试。换句话说，面EM position，要会讲属于自己的故事。

我常遇到EM candidates一上来就说“我很technical，很hands on，不喜欢只做people manager”。几年前的我也是这个德行。其实这里有两个误区：第一，hands off并不是做EM的禁忌；相反的，在有了一定规模的公司，hands off甚至是被鼓励被要求的quality。第二，hands off不意味着每天就是manage people。稍微有些经验的EM面试官马上会怀疑你并不完全理解EM的定义和职责，会怀疑你不确定自己长远的职业发展方向，甚至会怀疑你先前选择做EM的动机。你如果觉得这么形容自己，在被target team的TL/senior level engineer面的时候可能更有用，能拉近距离，我提醒你也可能事与愿违。稳定的大公司也好，高速扩张的startup也好，很多时候就是需要一个实打实的EM来带团队。组里的TL并不一定愿意做管理，或许还担心来一个hands on的EM会micromanage或overlap。所以，想靠说自己stay hands on来博好感一般都是自己想多了。

我觉得，说自己hands on其实是块遮羞布。掀开了，暴露出来的其实是还不懂得做一个好的EM应该怎么分配时间精力，需要具备什么技能。除了处理人事(就是口碑堪比五仁月饼的“people management”)，EM要参与制定产品长远计划，协助搭建技术架构，预估工程量，制定优先级，处理跨组跨部门的。要负责招聘，组建合适的团队，推行健康的工程文化，优化团队效率。有些时候则要考虑拆分重组以期达到与产品商务市场等部门的高度alignment。真的不是每天坐在那里等着韩梅梅来抱怨印度三哥或是盯着看李雷有没有项目进度不佳。职业规划(career planning)培养人才(people development)也不能占用EM的所有时间。澄清一下，这里说的对EM的expectations，并不是对湾区的所有公司都适用，但沈公子认为值得阁下关心的科技公司一般都是这个游戏规则。还有一点，本文提到的EM泛指各级的研发管理，到Senior Director为止。想了解VP以上的世界，这个公众号帮不了你。

言归正传，走不走management这个track，要仔细想想自己能否擅长做上述这些事情，能否通过这些方面给团队的程序猿媛们创造价值。已经是EM的童鞋，对照看看自己到底多少时间花在这些东西上，多少时间真的在做implementation。文化背景造成我们中的很多人觉得management等同于事业腾飞，其实最近有愈来愈多以李飞飞为代表的励志故事说明华人在美国科技公司的整体事业进步也可以多途径。但是倘若你确定engineering management是你的菜，就不要再模棱两可地说自己EM/TL dual intention，承认想走management的职业路一点不可耻不低人一等，本身这个社会就需要不同的人扮演不同的角色。换个角度看，你若真的很懂技术架构，在面试中会自然流露出，毕竟EM面试也不是问类似“曼哈顿一天要用掉多少瓶shampoo”的那种问题的。让interviewer去conclude你作为EM也有能力在技术上把关，你要专注的是证明自己是个合格且有经验的管理者。

EM interview是个对话，面试官通常不希望是靠一个一个discrete的问题来评估你，更愿意通过半聊天的形式很自然地把想听到的management点滴收集起来。这就说回一开头提到的story telling了。应征EM，一定要有(没有也要编，但是这不是沈公子说的哈)自己的故事。比如说，你是line level manager，可以谈谈你如何transition为啥transition，然后怎么let go你的technical responsibilities，怎么找到接替你的TL，或者你怎么从一个不是组里最资深的engineer转变成EM然后manage原本比你资深的peers。你就讲你的故事，面试官会去归纳你转EM的动机和你对这个职能的理解，不需要刻板的一问一答。Let go tech ownership, find successor TL这些看似是你经历的事，其实映射的都是管理理念！再来，假如你是个senior manager，那不妨谈谈你管理的各个组之间的联系和区别，谈谈你如何diversify your plate，如何context switch，然后有没有开始培养first level manager，怎么跟PM合(撕)作(逼)等等。把一个组的scope扩大，或吞并或拆分寻求资源最合理利用是你想要呈现的“卤蛋”，但是如果不放在“拉面”里一起端出来，索然无味。到了director level，要讲怎么定义自己的org了，为什么这么划分，跟其它org在技术架构和组织架构层面的关系。比如你是管infra的，那肯定要讲如何服务internal customers如何把cross-org dependencies体现在你团队的planning中；什么时候centralize solution，什么情况下让product-eng teams自己做，个中得失trade-off。工程文化和运营规范也是你必须要想过的事，而且不能只有教条，得有落地的事例。然后你的剧本里要有business context，最好请些Ops, BD, Marketing, Recruiting的配角来衬一把。

EM的故事越个性化越令人信服，下面分享一个真实的案例。S君要新建的组成天和analytics org打交道，斩不断理还乱的关系。然而analytics那边招人放水，S君这边engineering面试bar高很多，一时出现了S君一个寡头司令要带领一群不属于engineering org的analysts工作。眼见整个项目的人总体technical depth捉急，S君想出依靠contractor consultants暂补空缺。实际操作的难度可想而知，但却是可遇不可求的组建团队和跨组合作的经历，面试时拿出来讲，妥妥地展开很多话题。

最后说一个发生在沈公子自己身上的事例。当他还年轻的时候。。。也就几年前啦！面一家startup，跟VP of Eng对话。VPE似乎想以TL招了最稳妥，美其名曰公司还小，结构很flat，不直接招EM。沈公子表明了自己的职业目标后，VPE改口说了tech leadership人有三种，愿意统一期望值。
Only enjoys managing teams; not very comfortable with technical details.
Wants to manage teams; but also capable of helping with technical tasks if needed.
Enjoys tech leading teams; can help with management if needed.
然后就没有然后了。

好习惯，我就克服不了这心理障碍，怕自己学的不好让人家看笑话。

Mark一下，慢慢学习

沈公子讲的是SWE的级别，回头有空我可以讲讲数科的级别

ldpraymond 发表于 2017-5-23 15:42
Mark一下，慢慢学习

这。。。你点bookmark吧，无内容回复我会定期删。。。

Thanks much for sharing. There isn't a lot of discussions about team management. Especially like the sharing of interviewing for a manager. Storytelling is very important for manager candidates.

咱这个没有后续了吗