手把手教你在Google升职 2

感谢楼主分享！

其实我觉得最最重要的是选组，我见过在几个差组努力十年4都没到5的。（没错，就是我们组…）

写的挺general的  不仅仅是google， 其他公司也适用

感谢分享，很受教。其他大厂其实也差不多

ymsfd007 发表于 2020-10-3 12:53
太赞了，给楼主100+赞。
很多人诟病，狗家的升职过于学术圈子化，估计在改革边缘或者改革中

我倒是感觉这种学术界工业界取中间值的做法还不错

在Google生存可能不太一样，感觉努力的策略很重要

yayafuture 发表于 2020-10-3 08:01
赞分享 请问4到5一般要多久呢

现在变慢了 通常2-3年  

有问题请教lz 如果希望做的项目有impact的话，是不是可以在接受项目的时候只同意接受容易产生impact的项目，拒绝其他的项目，这样做有什么弊端吗？

sshou14 发表于 2020-10-4 05:33
有问题请教lz 如果希望做的项目有impact的话，是不是可以在接受项目的时候只同意接受容易产生impact的项目 ...

其实我个人不太建议这么做。建议用更长期的方式思考，build up credibility。过于挑活对长期不好。 当然你应该和team priority align，尽量做对组重要的项目（往往也是有impact的项目）。

🐎住！好贴！

tq5124 发表于 2020-10-3 11:36
感谢分享！

有一个问题我一直比较疑惑，就是描述difficulty。我经常在写perf的时候扪心自问，说实话我觉 ...

. From 1point 3acres bbs不管是tech还是non-tech difficulty，首先要确定是不是L+1的，然后才是怎么描述。最简单的方法就是设想大多数同级的人能不能handle，如果80%甚至90%都handle不了，就是很好的例子，直接往上写就行了。如果一半的人都可以handle，这个例子的说服力就不够，最好不要写，写了反而冲淡亮点。

另外针对你这几个例子，convince大佬一般算leadership，没人做的你做了算impact，TL觉得有用的也算impact。tech promo的difficulty核心还是技术问题， 或者是产品技术相结合。

ydybati 发表于 2020-10-3 14:44
感谢大神分享！

如果现在工作中有很大一部分是operation load以及解决tech debt这样的task，感觉impact很 ...

product team一样有这些问题，关键是要以小见大，抓本质找机会。比如service migration难做如果是因为某块代码烂，那就把这块代码的全部问题都整理出来，搞个refactor plan，重构之后不但migration cost降低，还能提高stability by % etc. 如果operational cost高是因为error handling混乱，就可以搞出个项目来整一把。大多数PA都有org level的infra/stability okr，能把bug fix做成infra improvement，在cost/risk合理的范围内，老板一般都是支持的。