这里是《齐姐聊大厂》系列的第 5 篇git
（前 4 篇见文末）github
每周五早上 8 点，与你唠唠大厂的那些事。web
小齐说：面试
你们周五好，又到了每周五早上 8 点的《齐姐聊大厂》系列。数据库
今天邀请到个人校友，Evens，跟你们分享他在谷歌的实习和工做经历。app
Evens 大佬先是暑假在谷歌实习，毕业后正式加入谷歌，而且在超级短的时间内完成了升职，让咱们一块儿来学习下吧。框架
实习的时候是在纽约的 office，当时项目是搭建一个小平台完成一次数据迁移。由于谷歌的编译、运行、发布全部工具链都是内部自研的，所以花了很多时间在学习和熟悉新工具上。这也是全部新员工入职以后面临的第一个挑战。ide
不过这些新工具不难学，由于谷歌提供了一系列的 codelab。codelab 会一步一步地指导该在哪里修改代码，作什么样的配置，最后搭建出一个 RPC server，或者联通数据库，或者开发一个小 app。svg
基本上每一个内部工具 都有一个或多个对应的 codelab 帮助你们快速上手工具
新工具的文档和 wiki 一般比较完善，不然无法吸引新用户。若是看完文档仍是有地方不懂，或者遇到了文档没提到过的问题，内部还有一个相似于 quora、stackoverflow 的问答平台，你们能够去提问，也能够去回答。而后通常用户量大的工具，他们的 team 还会提供 office hour，能够直接面对面问问题。
小齐问：那有用到什么技术框架吗？
用的是 Java 加上谷歌的一个 API 开发框架，Google Cloud API。由于是数据迁移，因此 Spanner 数据库打了很多交道。
由于都是内部的工具，因此遇到的问题一般无法在互联网上搜索到。震惊：世界上最大的搜索公司内部居然是一座“孤岛”！
实习项目的 scope 是 intern host 早就定好而且获得 approval 的。通常都会控制在能让实习生在 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，可是若是碰到问题 他会很热心的帮忙解决，可是对新人来讲可能不是很友好。由于新人也不知道本身该作什么，这时候通常更但愿有人能够指明方向。
我以为老板仍是挺对我脾气的。给我留了（过于？）充足的空间本身发挥也不会过问太多。可是来问的时候我总有成果能够汇报。而后虽然不怎么过问可是要找他他必定在那里可以帮到我，这个过程当中彼此就创建了信任。
过了一段时间老板也熟悉他的新角色了，咱们组开始扩张，新不少内部转组和新员工加入进来了。
等入职快 九、10 个月的时候，我已经在小范围 lead 一个项目了，这时候老板主动鼓励让我尝试去准备升职的事，而后给了不少意见和建议，对我却是帮助很大的。
谷歌的升职有一套 ladder 和对应的标准，老板当时跟我一条条解释他对个人 expectation 是什么，而且我当时达到了什么的程度，还有那些地方能够提高。而后在接下来的半年里提高个人 promo packet，最终是在 16 个月的时候升职。
小齐说：这么快升职，有什么心得吗？
一点当心得就是要尽早搞清楚游戏规则。升职的那些 policy 内网都有专门的网页详细介绍，熟悉这些规则会少走些弯路。
另外就是按照下个级别的 expectation 来要求本身，工做的时候多想一想怎么提高本身的 impact 和 leadership。除此以外就是提高本身技术实力啦，能出活才是硬通货。
接下来就专门讲讲对我影响最大的 TL 小哥。
TL 小哥人很是聪明，反应特别快，而且业务能力出色。一我的能搞定很复杂的问题而且对项目各方各面（设计、开发、测试、集成、上线、监控等等等等）都具有丰富经验。因为是美国长大，语言文化彻底不是问题，人很 nice 而且玲珑剔透，和组员及 manager 关系很是融洽，而且很是得上几级老板的器重。
多是我见过真人里最聪明的了。他的聪明有别于典型的学霸，是真的由于智商高因此通常人以为难的问题在他手上能够迎刃而解（学神？）。对于这种老天赏饭吃的猛人，我等普通人是羡慕不来的。
不过这些都是他本身得天独厚的硬实力。接下来想说的是他做为一个 TL，好在哪里（可能也是好 TL 共同具有的一些素质）。
因为对 codebase 很是熟悉，所以在 design review 的时候可以一针见血地指出设计所存在的问题。例如可能与某种场景冲突，可能会在别的地方形成反作用，可能违背长期规划会引入 tech debt。。。
因为熟悉产品中 tricky 的地方以及背后的缘由，老板遇到一些产品层面上的问题都会来询问他的意见，而且他提出的见解也深受重视。也是 TL visibility 的体现。
因为很是聪明，定位线上问题、在代码中找 root cause 也是快得飞起。有几回当面问他问题，我还在读方法前面的注释，他已经跳转了几回找到了关键的代码行。
狗家技术框架自成一套，而且不断更新换代。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。
小哥仍是挺践行狗家价值观的，例如老是假设他人的观点和行为是出自于善意。组员犯了错误，他也不会记仇，很宽容地帮助你们复盘，而且从规范流程的角度出发尝试预防错误再次发生。
小哥是真的热爱自家产品，由衷地感到骄傲的那种。而且很是积极热情地在各自 mailing list 里回答用户关于咱们产品的问题。
很是感谢 Evens 大佬给咱们带来的分享和思考，这是《齐姐聊大厂》系列的第 5 篇，若是你喜欢这篇文章，不要忘记点赞哦！～也欢迎留言告诉小齐你感兴趣的大厂～
更多干货文章见个人 Github: https://github.com/xiaoqi6666/NYCSDE
我是小齐，终身学习者，每晚 9 点，自习室里咱们不见不散 ❤️