在加拿大
拿了CMU PhD的offer读了一年就转成了Master跑路（和科长当年的轨迹一模一样），跑路时候也没有刷什么题拿什么大包裹，最后随便就从了亚麻的标准new grad包结束了自己的学生生涯。说到签亚麻也实在是机缘巧合。本来也是随便投的，结果电面OA啥也没有，recruiter 一封邮件让我去西雅图面试。我当时一边上着3门load很重的课一边面试，根本抽不出时间飞西雅图（当年匹兹堡到西雅图还没有直飞）去面试，所以找了个理由跟recruiter说不去面试了。然后刚好又有了两个西部的面试，中间多一天，就跑过去面试了。面试当时是群面，给了一台很破的ThinkPad写代码，然后跟面试官讲解自己的代码。4个小时时间我好像1个多小时就写完了，剩下的时间都在写注释和unit test。然后第二天就拿到了一个标准包。在工作中你通过完成领导给你的任务来赚钱，而在学校里你付钱来让老师和助教帮助你完成课业任务。所以工作中的任务必须按时高质量地完成，切不可偷懒。学校中的作业和项目都是 well-defined, well-understood，而工作不是。接到的任务可能非常地模棱两可，或者你不是完全懂该怎么做。去弄清楚弄懂如何完成这个任务是你的工作的一部分，而不是别人的。launch plan 里，你老板大多数情况下都会让你跟组里的每个人聊一聊。不要小看这个过程，这是你给你组里的同事留下的第一印象，而且取决于这个第一印象，他们会在潜意识里透露出更多的信息或者在接下来的过程中对你提供更大的帮助。其次，每个人在组里的情况都是不一样的，每个人给你提供的角度都是不太一样的。但是如果好几个人都跟你提到某个事，可能这是一个所有人都觉得重要但是没有时间去做的事。这一点非常重要等下还会再提到。前几个 project 都是给组里干一些没人愿意干的脏活累活，基本不可能有什么好的内容。想想吧，组里有那么多可干可不干的杂活，当你老板手下突然多了一个人（虽然这人基本没啥用但也是个人吧），是不是可以让这个人去做做这些事情。而且，能不能按时，保质保量完成工作谁的心里都没底，怎么可能把重要的活交到你手上。所以，你必须把这些活勤勤恳恳任劳任怨不折不扣地完成，因为你如果做的不好还不自知的话，你在这个组的初始印象就很差了。在做的过程中不断了解组的 software stack 和 business，去理解为什么这个活需要完成（而不是其它的）。不动声色地观察组内的情况，鉴别组内大佬、帮派，以及组内关系。通常老板都会指定一个人带你，但是带你的人可能本身不愿意带人，带人的能力有限，或者在组内缺乏话事权。所以盲从带你的人的指导有时可能适得其反。注意，我说的是盲从，在绝大多数情况下带人的人都是好的，但是还是要鉴别少量的坑，因为一旦你进去了就要花大把的力气把自己挖出来。
评论
挺科长的职场经验之谈。
评论
当老板分配任务的时候，考虑的内容有谁能在最短时间内完成这个任务，给某人的风险有多少，某人现在做的事和这个事相比哪个更重要，等等，并且很多时候会问组里核心人物们的意见。这个时候，如果有人愿意举荐你，并且你能再此之前展现出足够的 domain knowledge 和能力去完成这个任务，那将它分配给你的风险降低而几率上升。介绍一下我自己的经验。我2015年5月入组的时候，分配到的任务是搭一个测试环境。除了各种杂活（比如创建数据库，设置运行环境）以外，唯一的 coding 就是把所有系统中的 ID 从 int 改成 long。虽然这个项目烂到爆，但是能熟悉AWS内部的各种环境，工具，以及流程，并且可以打开熟悉各个组件。其次，在跟组员 1:1 时候所有人都说组内的系统没有 document，因为所有懂的人都忙着干活。于是我向每个部分的 domain expert 了解各个部分的细节和实现，并且把所有的内容汇总成一个 wiki。虽然写得很烂还有错误，但并不妨碍组内每个人都把这个破烂 wiki 向外推广，以至于时至今日，这个 wiki 还是组内软件架构的主要参考资料。在同年8月某次讨论如何提高某个重要组件性能的讨论上，组内最资深的 engineer 说到了关于 throttling 的内容，而且他的理解是错误的。我刚好前几天看到相关 wiki，于是提出不同的见解并展示了这个 wiki，使大家对我刮目相看，并且我提出的改进很小，但是直接获得了3倍的性能提升。自此以后，我没有继续打杂而是开始做好项目，继而在16年底就有足够的内容提交SDE2的升职报告。
评论
软件工程，首先作为一个工程项目，注定需要协调各方，多人合作。所以尽管代码、设计、实现和 debug 能力很重要，其它的软实力是让项目进展顺利的重要部分。而项目的进度则是你老板的指标。所以在硬实力达标的情况下，软实力很大程度上决定了你能否升职，以及多久可以升职。无论 Amazon 的 leadership principle 多么洗脑，无可否认的是大大小小的事都用它来衡量。于是深刻理解公司文化并掌握其精髓则是 align 并提高自己 performance 的一条捷径。无论 Amazon 的 leadership principle 多么洗脑，无可否认的是大大小小的事都用它来衡量。于是深刻理解公司文化并掌握其精髓则是 align 并提高自己 performance 的一条捷径。和组内同事高效合作是一个合格的工程师的基本素养，而和 org 里其它组，甚至不同 org 的组合作则更有讲究。首先，根据组之间的关系远近和先前的交集，两个组之间的合作意愿大不相同。其次，不同组的 priority 不同。如何说服其他组正确理解你的需求，估计所需时间则需要一些技巧。我的经验是了解对方的行事方式和语境，并将需求用对方可以轻易理解的方式表达出来，也就是所谓的 speak in others' language。这个在大公司里更为常见。做到这些可以让你成为一个称职的SDE2，而要升到 senior level 则需要一些其它的技能。
评论
1. 鉴别风险的能力。如果你能运用你对技术和系统的深入理解来准确预测系统风险，比如 scaling 或者 operational 的风险，并及时向上提出，那么即使没有被采纳而发生事故，它也会是证明你技术能力的重要依据。此外，如果能够在早期甄别项目管理中的风险并及时应对，可以帮助优化项目进度。一个例子就是鉴别项目中 unknown unknown 的能力。2. 项目管理能力。大多数情况下，你的老板，或者 program manager 会进行项目管理。但是很多时候他们太忙管不过来，或者项目不大他们不想亲力亲为的时候，项目管理能力将会起到很大的帮助。试想一下，如果你的老板可以放心地将一个多人，甚至跨组的项目交到你手上，可以信任你将技术设计和项目进度都搞定，他就可以减少工作量并花更多时间在其它事情上，提高组内的总体产出。3. 谈判能力。无论是与其他组交流，还是和老板沟通，如何通过谈判实现自己想要达到的目的是一个很重要的能力。很多时候，在合适的时机以恰当的沟通方式表达出自己的意愿可以达到事半功倍的效果。 4. 学习能力。随着级别的提升，工作的广度和深度都有大幅度地提高。如何快速地理解你原本不熟悉的内容，并根据经验判断方案的可行性和合理性是衡量一个 engineer 是否达到更高层级的重要能力之一。
评论
这些能力是提升至高级别的必要不充分条件。特别是升至L6及以上的级别，其它的因素也必须要考虑在内。大部分公司的升职报告都需要经过某种 committee 讨论通过，如果 committee 是由 org 的 leadership 带头，那么上层的政治斗争也会起到很大的影响。如果你的老板 performance 不好，或者在 org 内被边缘化，那么你的升职报告很有可能会被其他组的比下去。如何看待政治生态 ？有句话说得好，有人的地方就有江湖，在公司里更是如此。在一个 org 里机会总是有限，各个组之间的关系也非常微妙，领导平衡各路诸侯的手段也各式各样，所以了解、分析、掌握上层政治生态十分重要。 首先，了解跟你相关的直系 org 的分界线，比如某个VP，Director，和 senior engineer。了解每年的计划和 head count 的分配是怎么运作的，以及你所在组的 visibility 的边界。其次，了解你的老板和你老板的老板在 org 内的表现和地位，以及这两者的趋势。如果你老板和你的组在 org 中处于边缘地位，没有什么 visibility，或者常年没有新的 head count 和较大的成就，那么你就要小心了。毕竟在整个 org 中，你的 performance 是基于你老板（甚至是你老板的老板）的。再次，了解和你的组合作紧密的组的情况。如果两个组分属不同 org，那么你作为 engineer 必须和对方 engineer或者 manager 维持一个良好的关系，哪怕做到脸上笑嘻嘻，心中mmp也是必须的。特别是你的老板被对方压制，而且你的组还有求于人，那么就算跪舔也得做。毕竟你把关系搞差了，影响工作的是你的老板。如果是同个 org，那通过比较两个组的话事权可以大概分辨出它们在 org 中的地位高低。最后，了解每个组的决策者和最有话语权的人并与之建立良好的关系可以在关键时刻为你的工作或者升职锦上添花。所以，作为 engineer 们，选择一个好的老板至关重要。一个有能力有远见有进取心的老板会完全改变你的职业生涯。就像 Sheryl Sandberg 所说，When companies grow quickly, there are more things to do than there are people to do them. When companies grow more slowly or stop growing, there is less to do and too many people to be doing them. Politics and stagnation set in, and everyone falters. He told me, "If you're offered a seat on a rocket ship, you don't ask what seat. You just get on."如果不选择 start up，那么大公司里迅速发展的组也可以实现一样的目标。一个好老板可以在较短时间内提升你的能力，提供足够大足够多的机会来满足你的发展，剩下的就靠你自己了。最后说说和老板的关系。一个有远见的老板需要有能力的人来实现她的梦想，而一个人的精力总是有限。那么你需要做的是帮助你的老板实现她的目标，减少让她操心的内容。比如：1. 提供解决方案 2. 适时给老板挡枪
评论
每个组都有无数的杂活要干，college hire招来都是干杂活的。干杂活是最能体现一个junior engineer 能力和态度的。如果杂活都干不好还整天想着要干别的 meaty project 那么不好意思有个成语叫做好高骛远。但是，如果你能把杂活干出花来，比如说 automation, 发现并修复 bug，甚至于就读懂code，也比无脑干杂活强太多了。最怕的就是干了1年杂活还只是勉勉强强能干到80%。
评论
入职后， 需要尽快确认manager关不关心你的职业发展， 如果太只care deadline的话，尽早换。组里的核心人物是谁，老板technical吗，tech lead solid吗。 在组里找个senior的dev，作为组内的mentor，每周问问自己的表现如何，哪里能提高吗。确定掌握核心资源的人是谁，积极主动的去合作，拿可见度最高的活儿。很多事情，自己组里同事塞给你，因为他们知道是坑，学会如何优雅的避开，比如我觉得xx任务的优先级更高，我先focus on做完xx。别的组的人来找你帮忙的话，适当的给一点帮助，千万别花太多时间。如果需要花很多时间的帮忙，让他找你老板，老板通常会帮你推掉的。每周/每2周，把做过的事情总结下 email给老板，要feedback。一方面可以帮助提高自己，知道哪里能做的更好，老板也知道你做了啥，能帮你说话，另一方面，别人要害你的话，你都有written的证据。能不去tech debt重的组就尽量别去，否则，天天修东西，没时间学习，也没时间做项目。
评论
工厂砍人斩立决执法流程：Step1：把你放在dev-list，老板可以不跟你说这个事情，你可能不知道你进了list。老板可能隐晦的提到给你制定些小目标什么的。也可能很坦诚的说你进了list，要完成xx目标。Step2：step2a: 完成了小目标，老板写文档，救你出来。step2b: 完成了部分小目标，老板会和hr聊去延长你的list时间，通常总时间不超过半年。step2c: 很多人一被通知进list，就刷刷题走了Step3：如果你没有成功从里面出来。那么有2个选项，一个是做pip，一个直接拿3个月工资走人。每年要进行4次review，每个季度一次，每季度会着重评出Top tiers和Dev list的人选。谈加工资的时候，如果base的涨薪幅度小于等于inflation，那就说明被dev-list了，当年大概率LE(least effective) 。连续2次LE的话，会被开。Dev list如果不成功是进pivot, pivot 3个选项直接拿钱尽快走人,钱多一些，pip，钱少一些但能继续拿1 - 2个月工资，所以总共能拿的钱差不多，appeal, 通过hr找人仲裁appeal成功的话，恢复自由身，有2-3个月左右的时间选组，也可以留在本组，失败的话，选剩下两个之一。所以除了和manager撕破脸皮以外，appeal没啥坏处，毕竟进pip已经不用再考虑脸了。pip结果完全由manager决定，pip过程中manager可以随时fire,但是一般懒得在pip结束前fire以免给自己找麻烦pip如果成功，也是有2-3个月的时间选组，或者留原组进pivot后如果appeal成功或者pip成功，在 1 -2年如果再进pivot，不能appeal,只能pip或走人(也有说只能走人连pip都不能）如果在devlist或者pivot状态下离职，ineligible for rehire，除非override by vp approval。
评论
转加拿大温哥华分厂，当经理加拿大，温哥华，新的组，新的人，雷同的故事又开始了，组里东西不复杂，很快就摸透了，而且需求很少。来组里的第二个月我把组里的所有的backlog和feature request全做完了进入了无事可做的的状态。老板在西雅图，很少管我们，感觉看不到什么希望，对所谓的长远计划我既不看好也不感兴趣。就在这时，西雅图我之前组的大领导（忘了是VP还是director，反正现在是个VP了）来了温哥华，然后我们就在公司偶遇了。当时H1B没抽到的时候他也听说过我的签证问题，但是不知道我最后来了加拿大。他和我谈，说他们要在温哥华建个组，人都是外面招的，问我有没有兴趣参加。当时我心里已经有了转行当manager的打算，毕竟对之前组里的东西我还是很了解的，心里觉得这可能是个很好的机会，就一口答应了下来。然后第二周我就被调走了，变成了温哥华这个组的一号员工，自己开始边干活边看着我的队友们一个一个的加入，然后再带着他们开始干活，很轻松的成为了lead，同时和我老板说我想当manager，问他我应该怎么做。当然了，后来发现这都是徒劳的，在这边建组manager早就找好了，根本没有我的什么机会。可惜我在温哥华一年多了后才看透他们每次给我画的饼并不存在。不过人不会总这么不走运，2017年初西雅图有个PM开始想要尝试一些新的项目，虽然也是这个组相关的，但是现有的组没有适合做这个的，想要在西雅图新建个组来尝试这些想法。上头看我也有意向就让我俩认识了一下，然后两个人开始计划着下一步。当然了，在我看来这种高风险的事给我这种人正合适，成了他们有功，败了可以说我没有管理经验。虽然如此，我还是一边做着平时的工作，继续lead之前这些人，一边开始写vision doc，开始定义这个新的组的charter，op1，roadmap，三年计划。虽然很累，但是第一次感觉到起码一部分工作开始对我长远的职业规划有贡献了。之后事情还算进展的比较顺利，2017年中旬我们的proposal被批准了，我签了L1签证在2017年10月重新回到了美国，和另外一个SDE I一起干这些我自己的项目。2018年年初，隔壁组一个SDE II也加入了我们，他的2升3的项目被我们无缝衔接到了我们年初的项目里，这也是我们第一个大项目，一个大胆的尝试。没想到这个项目上线后效果非常的好，隔壁组的哥们这次新建的服务把他带到了SDE III，上头给了我们更多的人（5个人），我们的roadmap突然就变大了，我在我们的all hands上台讲过这个项目，写成了doc和VP们review过，得到了很多潜在的新use case。2018年后半年，一个follow up的项目也取得了成功，通过这次成功，我帮我们的SDE I升到了SDE II，我也得到了第一次给别人升职的经验。这段时间我既要保证做好SDE II的工作，同时要负责团队的每日运营，roadmap，backlog，op1，等等。终于做到2018年11月后这些人正式变成了我的direct report，手下终于有了5个人，转职文档也写得差不多了，我也可以终于放下SDe的工作专心做SDM的工作了。我很高兴上面给我的组批了7个SDE，我在grow手下的人的同时还会有机会去接触new hire，同时还要开始考虑backfill（组里有个人要走），当然还要开始考虑更长远的计划。更开心的是我老板说上面已经批了我的转职文档，title很快就能真的变成SDM了！离30岁还有半年，我终于如愿以偿当上了一个小小的SDM，管理着自己从无到有建起来的团队。回头看看这些年，我十分庆幸自己在不断地争取和等待，终于等到了自己的机会，同时也很感激这一路上的各种经历和最后的时来运转。
评论
好贴！！！
评论
点赞+手工赞
评论
《From survive to thrive》26万美金的 Facebook Data Engineer 工作三年总结DE写query跑job并不能支撑职业发展，想要往前一步就得学习一些新的技能，或者business sense、管理能力，或者调参、建模能力，或者像SDE一样的工程能力。software development engineer：生产数据（15 - 25）data infra engineer：管理数据（20+）data engineer：抓取数据（18+）data scientist：分析数据（16+）BI developer：展示数据（12+）About DE很久很久以前有一种工作叫DBA, 他们管product database. 管analytics db，等等。然后在大公司，出现了细分，一种是data infrastructure, 类似于user profile, transactions 啊这种product database，被他们拿走了，但是还有一部分，就是管理analytics database, 没人做了，于是就给了data scientist/analyst 自己管。那么问题又来了，他们又做分析，又管data, 是不是很忙， 是的，data quality是不是很差，是的...那怎么办呢？boom, 再分个data engineer 出来。他们用着data infra engineer(software eng) 建好的tool, 帮data scientists管着他们需要的data sets, 把logging, data quality, storage compute quota, pipelines 啊等等都管着...那么请问，他们怎么在公司quantify impact 呢？呵呵当然因为在FB，所以也是有很多优点的：一个项目组是由 ds, de, software engineer, pm构成，而并不是所有的data engineer自成一个组。你跟software engineer合作很多，你可以学到很多知识，你跟data scientist 合作也很多，公司还鼓励你自己做分析，你还要自己drive project,因为这种内部的东西，在product组是很少会有pm 来drive的你同时跟好几个组合作，又能借机了解下machine learning,了解下 backend, 还能了解下front-end.About FB缺点1: impact driven, 很多人可能知道，fb 6个月一个review, 跟年底发新股票和升职挂钩。可能3年前这个真的很好，帮助大家选项目,我记得那时候我们的用户增长好像还在30% ~40%之间。到现在我觉得这个有点畸形（可能有个人偏见），尤其是在一些不温不火的产品组。而且这个impact 很多时候需要量化，非常恶心优点1: 升职快，据我所知，虽然可能3, 4的工资，给的跟其他公司差不多，但是很多人一年3升4， 2年4升5。从soft skills 来说，很早就能自己单独做项目，带项目，确实很好。（另一说，一年如何积累3年工作经验的梗...缺点2:还是impact driven, 所以很多组大量的时间都在看data..ab test 结果, 很多product ranking engineer 甚至有点像feature engineer. 另外就是公司大了之后，组跟组之间的skill set 差距会更大。所以其实 最终review的结果并不公平。优点2: 想想你在一个核心组做一个巨大的项目，在大牛面前也就是个渣渣，但是在渣渣组，做点啥看起来都不错, 想想就开心...缺点3: 这一点可能有个人偏见，我不太喜欢fb的manager. 很多时候他们真的太官方了，动不动就跟你扯，这个项目impact很大，或者说你看，这个东西很难drive,你做出来了别人做不出来，你就greatly exceed expectation.（嗯，是的，但是好像我也没法drive..）。优点3: 强行说的话，就是在天真烂漫的年纪(level)，承载着与年纪(level)不相符的压力，挣着与自己综合能力不完全匹配的高工资。自己当pm，自己分析data, 自己去跟别人撕* launch 项目.
评论
Software Engineer vs Product Manager Salaries
评论
美梦成真1808 说:这个九章算法里好像读过点击展开...九章算法，汉化版的山寨leetcode，码工里的新东方。
评论
亚麻在大厂里不算口碑好的
·中文新闻 韦克利教堂刺伤事件：马尔·马里·伊曼纽尔基督好牧人
·中文新闻 就业数据：失业率上升，所有人都关注通胀