入职谷歌不到一年就升职是一种怎样的体验？
今天邀请到我的校友，Evens，跟大家分享他在谷歌的实习和工作经历。
Evens 大佬先是暑假在谷歌实习，毕业后正式加入谷歌，并且在超级短的时间内完成了升职，让我们一起来学习下吧。
实习的经历
实习的时候是在纽约的 office，当时项目是搭建一个小平台完成一次数据迁移。因为谷歌的编译、运行、发布所有工具链都是内部自研的，因此花了不少时间在学习和熟悉新工具上。这也是所有新员工入职之后面临的第一个挑战。
不过这些新工具不难学，因为谷歌提供了一系列的 codelab。codelab 会一步一步地指导该在哪里修改代码，做什么样的配置，最后搭建出一个 RPC server，或者联通数据库，或者开发一个小 app。
基本上每个内部工具 都有一个或多个对应的 codelab 帮助大家快速上手
新工具的文档和 wiki 通常比较完善，否则没法吸引新用户。如果看完文档还是有地方不懂，或者遇到了文档没提到过的问题，内部还有一个类似于 quora、stackoverflow 的问答平台，大家可以去提问，也可以去回答。然后一般用户量大的工具，他们的 team 还会提供 office hour，可以直接面对面问问题。
❝那有用到什么技术框架吗？
❞
用的是 Java 加上谷歌的一个 API 开发框架，Google Cloud API。因为是数据迁移，所以 Spanner 数据库打了不少交道。
因为都是内部的工具，所以遇到的问题通常没法在互联网上搜索到。震惊：世界上最大的搜索公司内部竟然是一座“孤岛”！
实习的项目
实习项目的 scope 是 intern host 早就定好并且得到 approval 的。一般都会控制在能然 intern 在 9-10 周左右完成的那个量。
我当时的项目是已经有了 design doc 和详细的大步骤，我只需要按着这个一步步实现就行了。
后来跟 host 聊天了解到，这其实是他本来要做的东西，然后打包给我了，所以他自己对这个项目的内容和难度有很深的认识 也指导我少走了很多弯路。
❝host 是类似于 mentor 的角色吗？
❞
不全一样，每个实习生既有 host，也有 mentor，还有一个 cohost。。。
host 负责 intern 的项目进展和技术指导，cohost 也是对 intern 项目提供帮助和做一些 code review，mentor 不负责项目的进展和技术难题，而是回答一些非项目相关的 general 的问题，比如怎么转正呀，怎么找到好吃的食堂呀 那层楼有好吃的零食呀之类的，以及回答一些 intern 不好意思问 host 的一些问题，比如觉得自己压力大，项目难不知道怎么快速入手，或者 pair 的那个 intern 不太给力我该怎么办之类的。
总结来说就是，host 和 cohost 负责项目进展，确保 intern 能完成这个项目。mentor 更多是给 intern 安利谷歌。。
实习中穿插了很多 intern events，主要是帮助实习生之间互相认识，以及结交一些已经在谷歌工作的员工，尤其是自己感兴趣的组/部门里的大佬。
实习末期
等到了项目的末期，整个 PA(production area，大概是“部门”的那个概念)的实习生会一起给 VP 做 presentation，介绍做了啥项目，三个月的实习期收获了什么（不过我也不确定是不是每个 PA 都这样）。
我记得 VP 要每个实习生说实习中最痛苦的事情是什么。
10 个里面有 9 个抱怨 learning curve 太陡峭了，来了一堆新概念新名词要学，VP 眼镜都直了。。（因为对于待了很多年的员工来说，这些工具都像呼吸一样自然了）
然后他跟其他人说以后设计 intern project 的时候一定要预留 ramp up 的时间给 intern。
之后 host 和 cohost 会分别写一份 feedback，在加上两轮转正面试，一共四个 feedback，交给 hiring committee 决定是否转正成功。
正式加入谷歌
然后毕业就入职成为全职员工了。
因为之前实习过，所以入职之后感觉都是熟悉的感觉。
有很多谷歌员工自造的单词，比如 googler，noogler。很多内部东西都以 g 开头，比如 gbike, gbus, gride。我个人感觉有点自成一派的“傲娇”?
领了一顶 Noogler(new googler)的帽子，才发现实习时候发的帽子上面印的是“intern” 是不同的帽子。奈何搬家的时候扔掉了 ?
❝入职感觉咋样～比实习更累吗？
❞
其实还好，因为实习的时候项目有 deadline，结束前做不完就挂了 LOL
全职的很长一段时间里反而没有 deadline。
一般新员工约定俗成会有一个月的时间 ramp up，并且刚入职会有各种新人培训。但是我实习的时候都经历过了 所以很快进组干活了。。
一开始从修 bug 开始 组里已经提前留好了 bug 给我 ?
然后慢慢会有一些好项目交给我独立完成。
我老板当时刚从 TL 转成 TL manager，可能也在适应他的新角色。所以除了 1:1 以外都没有过多过问，基本上是我自己野蛮生长。
❝TL: tech lead，每个团队都会有一个 manager 和一个 tech lead
❞
那同时组里有个小哥就被任命为 TL 了，此时他才加入谷歌 3 年，就已经从 L3 升到 L5，而且在组里还有其他 L5 老员工的情况下被委任为 TL。
❝所以是这个新 TL 对你影响更大吗？
❞
对的。打交道更多是 TL 基本 code review 都是他负责，然后各种问题也只能找 TL。
（下文会有一段专门来讲 tech lead）
老板（manager）的话，直接的影响其实不太多，更多是那种润物细无声的。从来不会 push，但是如果碰到问题 他会很热心的帮忙解决，但是对新人来说可能不是很友好。因为新人也不知道自己该做什么，这时候一般更希望有人可以指明方向。
我觉得老板还是挺对我脾气的。给我留了（过于？）充足的空间自己发挥也不会过问太多。但是来问的时候我总有成果可以汇报。然后虽然不怎么过问但是要找他他一定在那里能够帮到我，这个过程中彼此就建立了信任。
过了一段时间老板也熟悉他的新角色了，我们组开始扩张，新很多内部转组和新员工加入进来了。
升职
等入职快 9、10 个月的时候，我已经在小范围 lead 一个项目了，这时候老板主动鼓励让我尝试去准备升职的事，然后给了很多意见和建议，对我倒是帮助很大的。
谷歌的升职有一套 ladder 和对应的标准，老板当时跟我一条条解释他对我的 expectation 是什么，并且我当时达到了什么的程度，还有那些地方可以提升。然后在接下来的半年里提升我的 promo packet，最终是在 16 个月的时候升职。
❝这么快升职，有什么心得吗？
❞
一点小心得就是要尽早搞清楚游戏规则。升职的那些 policy 内网都有专门的网页详细介绍，熟悉这些规则会少走些弯路。
另外就是按照下个级别的 expectation 来要求自己，工作的时候多想想怎么提升自己的 impact 和 leadership。除此之外就是提升自己技术实力啦，能出活才是硬通货。
接下来就专门讲讲对我影响最大的 TL 小哥。
最好的 tech lead
TL 小哥人非常聪明，反应特别快，并且业务能力出色。一个人能搞定很复杂的问题并且对项目各方各面（设计、开发、测试、集成、上线、监控等等等等）都具备丰富经验。由于是美国长大，语言文化完全不是问题，人很 nice 并且玲珑剔透，和组员及 manager 关系非常融洽，并且非常得上几级老板的器重。
可能是我见过真人里最聪明的了。他的聪明有别于典型的学霸，是真的因为智商高所以一般人觉得难的问题在他手上可以迎刃而解（学神？）。对于这种老天赏饭吃的猛人，我等普通人是羡慕不来的。
不过这些都是他自己得天独厚的硬实力。接下来想说的是他作为一个 TL，好在哪里（可能也是好 TL 共同具备的一些素质）。
对组里产品的整个框架、业务、到代码细节都非常熟悉
由于对 codebase 非常熟悉，因此在 design review 的时候能够一针见血地指出设计所存在的问题。例如可能与某种场景冲突，可能会在别的地方造成副作用，可能违背长期规划会引入 tech debt。。。
由于熟悉产品中 tricky 的地方以及背后的原因，老板遇到一些产品层面上的问题都会来询问他的意见，并且他提出的看法也深受重视。也是 TL visibility 的体现。
由于非常聪明，定位线上问题、在代码中找 root cause 也是快得飞起。有几次当面问他问题，我还在读方法前面的注释，他已经跳转了几次找到了关键的代码行。
对技术具有一定的掌控力，能够为整个组设立 technical direction
狗家技术框架自成一套，并且不断更新换代。TL 小哥对常用技术的了解自不必说，对于新技术也广有涉猎。得益于此，他常常很积极地推动新流程和使用新技术。
当组员对某些技术问题争论不休时，他能很果断地做出决策，并且清楚解释决策背后的考量，让人信服。
有一点令我感到尊敬的地方在于，他从来不会因为自己是 TL 而忽略其他同事的看法。如果同事对他的决策有质疑或者未能完全接受，他会很耐心的与之继续探讨并作出修正。
维护组员并且指导组员成长
他曾经跟我说过，如果项目作出了什么成果，credit 都是我的；但是如果过程中出现了什么问题，他永远会会给我兜底。
我堂堂八尺男儿，听完竟然有些感动。
他也确实是如此践行的。
比如：
a). 某次大组出游，正值我 oncall，收到一个用户 page。我回酒店房间处理。他知道后给我发消息，说这个时间点我们算是 out of office，不用响应用户 support 的 ticket，只要我们的服务没有 down 就可以等回去了再弄。我问如果用户很着急怎么办，答曰用户的 priority 不是我们的 priority，只要我们的 service works as intended，问题就不在我们这边。因此也不用花费私人的时间去处理。
b). 另一次 oncall 结束，有一个用户 ticket 我忘记交接给下一位 primary。后来用户过来 ping 有什么进展。TL 过来问我，我心想这是我留了收尾当然得把事情负责到底，于是跟他说这是我遗留没做完的事情，我继续把它完成。他说他来找我只是单纯了解下一些细节，看看是否是交接流程本身有一些遗漏；他来找我也并不代表他要我继续跟进这个事情，既然我的 oncall 结束了，他建议直接交给当前的 oncall 就好。不过又说如果我一定很想做完这个事情，他当然不会拦着我。
我刚进组时，TL 小哥侧重指导具体技术的用法。等我也渐渐成为组里较资深的组员时，TL 小哥身体力行指导我如何综合各方各面的考量去做 technical decision。
践行 G 家价值观
小哥还是挺践行狗家价值观的，例如总是假设他人的观点和行为是出自于善意。组员犯了错误，他也不会记仇，很宽容地帮助大家复盘，并且从规范流程的角度出发尝试预防错误再次发生。
热爱产品，积极响应用户的问题
小哥是真的热爱自家产品，由衷地感到骄傲的那种。并且非常积极热情地在各自 mailing list 里回答用户关于我们产品的问题。
非常感谢 Evens 大佬给我们带来的分享和思考，
后记
最近写的一些干货，每篇都很用心，欢迎各位小伙伴阅读/点赞/分享：
我是Guide哥，Java后端开发，会一点前端知识，喜欢烹饪，自由的少年。一个三观比主角还正的技术人。我们下期再见！