独家：大厂导师们精心分享的不为人知的职业发展秘籍
不久前TJC(Tech Job Community)的Mentorship Program举行了第一次engineering panel discussion。Mentors和mentees一起讨论了过去一段时间大家在职场中的一些改变，体会和疑惑。这次panel discussion主要围绕着两个问题来展开:1)如何规划自己的长期职业发展道路？2) 现在流行的系统方面的技术或者发展的趋势。我们整理出几位导师的发言，希望对大家有所启发：
长期的职业规划是一个非常难的问题。我确实从几年前开始(工作五年后)给自己制定了一些规划，但都是以三年为一个跨度。这样的三年规划，再加上每年的milestone，对我很有参照意义。倒不是说必须要去实现某个目标，而是这样的thinking process让我能够想清楚什么东西对自己来说更重要，以及哪个方向我更感兴趣。举个例子来说，我在几年前，给自己定了如下的目标：首先我想在mobile engineering方面学到更多的expertise，在工作中可以去drive一些能够给公司带来business impact的项目， 而且我想在下一个阶段做到managerial的角色(engineering manager)。在这些目标确定好之后，我就可以很清楚的知道下一步努力的方向。目前来看，我的职业发展路径大致是和当时的期待一致的。最让我受益的还是制定规划的那个过程，可以让我理清将来的方向。如果把时间跨度放大一些来制定目标(5年,10年甚至更长)，我觉得真的特别难，在公司的层面做很长远的规划也是如此。
我认为并没有一种普适的办法可以让我们做长期的职业规划。但我个人认为长期的职业发展道路，应该是跟个人的天赋和兴趣相关的。 如果你是一个内心奔放的艺术家，然而被迫于一些原因去选择做了码农，可能即便做的非常成功也并不会感受到发自内心的快乐。职业规划和你的天赋和兴趣爱好最好能够on the same page。从另一个角度来看，这也是一个发现自己了解自己的过程。然后尽量把自己的职业发展跟你自己最终想做的事情align在一起。另一方面，职业的发展很多时候也依赖于一些我们自己无法控制的外因。所以如果能够把发展道路跟自己的兴趣联系在一起的话，就算职业发展不是很顺利，自己内心也会比较开心充盈。
职业发展确实有很大运气的成分在里面。更多时候我基本是随着公司的发展，然后做自己能够做的事情。我可以分享一点关于我和组员对于职业发展的讨论。有很多时候，大家会面对继续做IC(individual contributor)还是转成管理岗位的选择。对于这一点，我对自己组员的建议是要遵从内心的决定，不要因为公司或者职位的需求而在两种career path之间做决定。有很多IC，在公司，职位，经验和一些其他原因下从IC转到了管理岗位，但是之后的工作却没有之前做IC开心。因为职位的原因，再退下来会有阻力，所以就会过得很miserable。另外一种情况是对于managerial的角色并没有很实际的了解，认为manager不用太多的干活，给人一些指导就可以。如果缺乏关于managerial责任的了解， 等到真的去做管理之后，才发现和期待中的很不一样。更糟糕的是可能导致该做的事情没有完成。我经常对自己的组员建议，如果感兴趣的话，可以通过各种渠道先去尝试一下，看看 manager的 career path是不是真的适合你。尝试过后你也许就会意识到自己是否真的感兴趣，是否具备应有的技能。然后再决定是否想锻炼相关的能力等等。
站在recruiter的角度，我很同意各位导师的分享。做职业的规划要follow your heart。在职业生涯早期，拿engineer来说，大多数人努力的方向是成为一个比较senior的工程师。到了下一个阶段后，会考虑成为manager还是继续做IC的问题。导师们给了一个比较好的指导，就是不要把自己不喜欢的东西硬塞到自己的职业规划上。我们做招聘也是一样，看到很多在业界摸爬滚打多年的工程师并没有考虑过管理的岗位，他们在IC的职位上一直做的很开心。
不管技术怎么发展，有一些基本面的东西是不会有很大变化的。比如说分布式系统，data driven application 还有 product development mindset，在最近的几年里面，都没有特别大的变化。变化更多的只是体现在具体的工具 - 在不同的领域有自己的长处。还有怎样和 application 能够有更好的 integration。这一方面也是需要我们去探讨的-每个领域到底是适合什么样的一个系统。以及非常成熟的一个系统，可能会有一个什么样的比较长远的应用。
从我们公司角度（Airbnb）来看，我能感觉到从产品开发上来看，有一个是比较有意思的想法，就是 server driven UI。之前很多时候在开发一个 application 的时候，都是 server只负责提供一个 data model，然后前端根据数据模型去负责所有的用户体验，包括商业逻辑的实现，图形界面的显示和互动。这样的话，经常会导致一些问题，比如不同平台功能的偏差，或者是开发之后的多平台的维护负担。现在如果做 server driven UI，就是说后端负责所有的商业逻辑，返回到前端的始终是一个 view model，然后前端只要知道 view model 在前端应该怎么样去 render 成什么样的界面，没有任何跟商业逻辑相关东西，这样的话就商业逻辑和显示解耦了，也让后端成为source of truth，前后端的职能分工更清晰了。
这跟我们很多之前讨论过的很多 technical principle 也是一样的，比如说怎么样能够让整个系统更加解耦，基本就是这些理念在开发的框架里面的一个应用。但不见得这是一个rule of thumb，就是所有公司都适合的技术，不同公司的理解也不一样，像Amazon，Youtube还有Airbnb 其实都在做 server driven UI，但实现上的 granularity 是完全不同层次的。针对不同的公司，也需要去从 neutral principle 或者 product requirement 的角度出发，去确保能够有一个最好的匹配。
目前我观察到的一个趋势是，可能最后大多数的 infra 团队最后都变成了一些 integration 团队。比如说自己做 Kafka 或者 Flink，这种团队应该会越来越少了。build 起来一个 infra 团队实在是太难了。作为一个 infra 团队的经理，如果团队没有合格的 tech lead 自己要承担 tech lead的责任，在 people management 方面要帮助团队成长，同时要做 PM，因为 infra 团队没有 PM，所经理要领导团队方向。作为 infra 团队的经理，不仅需要 people skill，还需要很 hands on 的 technical skill。我感觉走了好久弯路，但这也是一段难得的成长过程。我在和我的 manager 讨论，如果我们 restart from scratch，那我们可以 acquire 一个团队，或者就直接用 cloud，自己从头开始建一个团队的成本会非常高。
我觉得所以现在 cloud provider 像比如说 databricks，或者说各样公司对各种 infra components 都有比较好的 management service。我觉得一个未来的趋势是各种公司不管是小公司到中型公司，可能除了一些 cloud provider， 或者比如 Facebook 一样的大公司，大多数公司都会直接上云。各种 infra components 都是直接用云，data 团队更多是做一些 integration，而并不是说自己去开 infra，因为开发 infra 的代价实在是太高了。除非这个 infra 是对公司业务是有直接联系的，比如说 Linkedin 最有联系的是做 graph，对 Linkedin 来说我们来说有一个自己的 social network graph，这个可能别的公司做不了，因为只有我们有这个 use case。但大多数的一些情况，比如说什么做 AI，或者说比如说做 Kafka 或者做 Flink，Spark，就没必要说自己管理一个团队来做 infra，更多时候是采用提供商来做这个事情。
Server driven UI 也是我们最近公司在做的一些事情，并且我们在做的比 server driven UI 还要再前一步，比如说我们现在正在做 unified design system，就相当于说要在 server driven UI 之前，每个 client，比如 Android，iOS 和 web， 都要 match，有一个 common design language。比如说一个 button，每个 client 都要是同样，这样大家用起来client才不会有不同的看法或者不同的体验。或者有简单的 pop-up 简单的 dialogue，dialogue 也在不同的 client 端要有相同的相同的体验。这一步做完之后才能我们才能够真正 server driven UI，比如在 client 端可以定义 pop-up 永远是这个 style，这样 server 告诉 client，client 就会永远是这个 style 的 pop-up。想我们在做一些 unified design system 的工作，这也算是一个 trend 了。
我也同意刚才的说法。实际上真正 infra 团队到最后都会变得越来越接近 integration 团队。对我们来说，我们是慢慢的在探索怎么样找越来越便宜的 solution。刚开始我们也是直接就去租服务器，当时我们是租了一个 location center，就相当于我们是直接租那种真正的服务器，然后我们自己会有人去管这服务器。后来我们就觉得这些觉得太贵，然后就直接去租 AWS 的EC2 的 instance，就是从租 physical 的服务器到租 cloud instance。后来我们发现有时候租 instance 也太贵了，因为有时候 instance 的 CPU 也不需要跑这么久，也不需要这么多 instance，我们有尝试 dynamic scaling，但是也是不太好用。这时候我们就开始想，能不能直接就租某个 instance 的时间段，然后后来就有点向 serverless 向 lambda 那方面走，就是说我们就只有真正需要的时候，我们才去租，然后不要的时候，我们就一分钱都不出，这个目的都是为了省钱，为了能够最大化的给公司节省钱。
包括我们现在也有很多其他第三方的 logging 的解决方案，然后觉得这些都太贵了，然后就觉得说我们还是要自己做了。所以虽然说我们有一部分是 infra integration，但有一部分是 infra 是自己来做，因为说我们觉得说自己做能省更多的钱，能比用第三方服务更好。所以说这些都是一些在公司 leadership 方面都是说要做的一些决定，因为有的时候比如说 tradeoff 没有那么的明显，并且有时候 tradeoff 还有一些历史原因，比如如果要做 migration 的话费会是多少，这些实际上都得自己考虑。但总结来说，这个趋势是为了省钱。
最后我觉得还有想说一个，虽然也不是一个非常新的想法了，是 passwordless authentication， 就是登陆再也不用输入密码了，因为有密码的话，各种各样的网站全部都需要通过密码，所以总会有网站密码泄漏之后，用户密码就会被盗。所以说我们现在也在考虑各种各样其他authentication method，比如说通过 2FA，通过 MFA，通过邮件或者短信之类的来让用户登录，这样用户登录以后都不是靠输密码而是靠一个trusted device 就可以.这个方案也是我们在考虑的。因为我们电商的网站经常会有用户的账号被盗，或者信用卡信息被盗的风险，这些信息我们来说都是一个很敏感的东西，所以我们都想要尽量减少这些账号被盗的可能性。
价值百万的职场干货 全球科技&金融职位周报
大咖分享会 & 职场会客厅 最优质硅谷科技社区
更多你想看的内容戳这里👇
Coinbase：从一个被称骗局的想法，到一家860亿美金的公司
最大的风险就是不冒任何的风险｜Sam Altman对话Facebook创始人Mark Zuckerberg
后疫情时代跳槽秘籍分享