Skip to main content

6年+FB员工:META/FB最需要的是正视自己的位置(ZZ)

 
这次的大跌加上其他公司的强烈对比(比如Snap),显示了Meta在目前这个阶段无比尴尬的局面。作为老员工我对大跌并不惊讶,惊讶的是它今天才到来而不是更早的时候。最近在看到帖子提到以后是MAGA的时代,我很赞同。META最需要的就是正视自己的位置---不是一线大厂,而是有赚钱能力但需要艰难寻找增长点的中厂。这并不丢脸,市面
上大部分科技公司都是这个局面,微软谷歌和亚麻广泛的业务线对于其他公司来说都是难以企及的,那才是一线大厂该有的标准。

事实上,N年前Google和FB的offer同时摆在面前时,我几乎毫不犹豫的选择了FB。钱的原因是其次(当年FB的comp确实领先),更主要是我喜欢FB和其他几家比起来,员工数量少得多但赚钱能力惊人,每个员工的impact和重要性自然更大。虽然只是纸面分析,但还是一定程度上反应了公司的风格。进公司的前几年体验真的太好了,同事聪明且优秀,拥有真正的eng-driven文化,话语权大的惊人。产品里也还有各种可挖掘的潜力,何况公司对待员工也是十分的豪爽,挑不出毛病来。

走下坡路应该是从18年的剑桥门开始的,股价大跌其实只是一小部分,更严重的后果是一:公司的牌子烂了,做其他产品从起跑线就输了。二是让公司在执行层面开始迷失方向,失去了“move fast”和“focus on impact”的初心。开始大幅扩招,企图用堆人来解决暴露出来的问题。管理层高频变动,团队被像打牌一样来回reorg。再加上整体
上buttom-up的文化,其实对每个员工的要求极高。在短时间内大量新人进来后,没有
合理的空间又不得不拿出足够的impact,除了卷确实没有更好的选择。

从某种意义上来说,FB没有大厂的命,却被迫得上了大厂的病。其实就算今天FB也只有小几万员工,能继续维持我们曾经引以为傲的“骇客”文化,我觉得也挺好的。可惜在不切实际的“大厂”期待面前,丑媳妇总有见公婆的一天。FB的潜力被挖尽是几年前就能看见的事情,内部的大部分产品(如果不是全部的话),都是把同一批流量左手倒右手。很多人干的不开心我可以理解,也挺为他们可惜的,毕竟错过了最好的时候。现在的FB还有200多的股价,纯粹靠当年高瞻远瞩的收购续命。如果你仔细看FB自己做出来
的东西,别说成功的,连活下来的都没有几个。这个锅应该员工背吗?maybe。但管理
层肯定是难辞其咎的。

昨天安慰了不少进公司没多久的人,晚上躺床上梦回若干年前我背着包第一次站在彼时还没那么拥挤的MPK园区门口。那仍然是我印象里人生最开心的一天(之一)

会不会离开META?

不会,至少短时间内不会。一方面职业生涯到了某个阶段,care的不光是TC啊股价啊之类的,更多的是自己的职场set up是不是够好,老板是不是支持,活是否干的舒心。换句话说,让我操“卖白粉”的心可以,但得给我足够的recognition。这一点我现在是
有的,不舍得放弃,除非顶头上司走了另当别论。再加上带着有一批很有潜力的小朋友,希望至少把他们培养到独当一面再走。对公司的前景,尤其all in元宇宙这事,我实在是不看好。所以即使离开meta还有一段时间,倒计时是开始了已经。希望公司别在那之前就凉凉了吧😂

Comments

  1. FB就是前面赶上风口发展太快了,技术积累严重不足。慢下来,积累几年,只要不死,就还是有前景的。毕竟FB的员工不蠢,这和另一家有根本区别。

    ReplyDelete

  2. 不操心公司赚不赚钱,不代表不需要知道公司赚不赚钱,为什么不赚钱。要在公司对外露出颓势之前,及时从沉船上跳下来,才能更好的爬ladder呀。

    ReplyDelete
  3. 很困難,二把刀不會讓一把刀進去幹活。如果一人掙個2,30萬還有可能,一個人掙了
    1M以上,誰都不會放手,就算看着公司眼睜睜地走下坡路。

    這就是我說的,G的狀況決定了,能夠找到他們目前頂級技術以下或者相當的人,至於
    用不用,用得好不好是另外一回事。但是FB不行。

    ReplyDelete

  4. CTO还是给CEO打工的,大家一起找新蓝海,他一个人作用不大。肥逼瞎忙活了很多年,却白白错失了短视频这波机遇

    小札在马桶上憋出来的“元宇宙”,看起来没啥鸟前途

    ReplyDelete

  5. 只需要预感一下什么时候会裁人就行,归根结底还是什么时候跳槽好。

    赚不赚钱不是普通员工需要考虑的。

    ReplyDelete
  6. FB公司内部缺少上书渠道,下面的声音被压着,上面做决定的人用迷信开道,不挫败才怪。

    ReplyDelete

  7. 也说明员工完全不重要,方向对了,雇一群蠢货使劲虐待员工,员工一年换三遍也没事。方向错了,员工越开心公司死越快

    ReplyDelete

Post a Comment

https://gengwg.blogspot.com/

Popular posts from this blog

OWASP Top 10 Threats and Mitigations Exam - Single Select

Last updated 4 Aug 11 Course Title: OWASP Top 10 Threats and Mitigation Exam Questions - Single Select 1) Which of the following consequences is most likely to occur due to an injection attack? Spoofing Cross-site request forgery Denial of service   Correct Insecure direct object references 2) Your application is created using a language that does not support a clear distinction between code and data. Which vulnerability is most likely to occur in your application? Injection   Correct Insecure direct object references Failure to restrict URL access Insufficient transport layer protection 3) Which of the following scenarios is most likely to cause an injection attack? Unvalidated input is embedded in an instruction stream.   Correct Unvalidated input can be distinguished from valid instructions. A Web application does not validate a client’s access to a resource. A Web action performs an operation on behalf of the user without checking a shared sec

CKA Simulator Kubernetes 1.22

  https://killer.sh Pre Setup Once you've gained access to your terminal it might be wise to spend ~1 minute to setup your environment. You could set these: alias k = kubectl                         # will already be pre-configured export do = "--dry-run=client -o yaml"     # k get pod x $do export now = "--force --grace-period 0"   # k delete pod x $now Vim To make vim use 2 spaces for a tab edit ~/.vimrc to contain: set tabstop=2 set expandtab set shiftwidth=2 More setup suggestions are in the tips section .     Question 1 | Contexts Task weight: 1%   You have access to multiple clusters from your main terminal through kubectl contexts. Write all those context names into /opt/course/1/contexts . Next write a command to display the current context into /opt/course/1/context_default_kubectl.sh , the command should use kubectl . Finally write a second command doing the same thing into /opt/course/1/context_default_no_kubectl.sh , but without the use of k

亲身经历告诉你慎重去Meta WLB差的卷组

 楼主终于要离职Meta了,终于离开了某卷组,原本以为自己是不怕累不怕加班的,心想如果多付出换来多回报也是值的。但事实给我上了一课,来跟大家分享一下不要选卷组的原因,以下都是楼主个人经历和想法,如有不同意见,轻喷。 1. 当卷组每个人都在疯狂contribute的时候,manager的期望会调整成组里的平均值,如果每个人都在疯狂加班,你也得被迫疯狂加班。我有时候甚至都怀疑有的人睡觉中途醒了是不是都会review个diff再继续睡。这种情况下,结果很可能是疯狂加班后也没有被recongnize也没有得到更多回报,简而言之就是rating未必更好,升职也不一定快。 2.  卷组的culture一言难尽。当大家都在疯狂赶工的时候,还顾得上考虑culture吗?当人在很忙很焦虑的时候,心态也不会很好。很多人在忙的时候说话就很冲,而且一不小心自己说错了什么也容易得罪人。Meta还有要peer feedback的习惯,有的时候感觉真的很憋屈... 3. 有的组太卷的原因是上面要的太多,而manager又很难或者不太会push back造成的。这种情况下,Eng加班是不情不愿的,疯狂赶工自然会牺牲质量,出了SEV以后,psc上面是要记一笔的。曾经见过某人疯狂赶project三四个月(上面期望的timeline不合理,但是push back无效),基本每天忙到凌晨12点到1点,但不小心搞出来一个SEV,最后psc给了个MA。大写的心疼... 4. 用lines of code 或者diff number作为一个重要的psc评判标准的组,要小心!个人认为这不是一个好事,有的project是需要investigate的,有的bug是需要时间才能查出来的。但是manager很难体谅,只会认为你能力低效率低(如果能体谅和理解,也不会把代码行数和diff 数量看那么重了 是吧),这种情况下,很考验一个人在这个组待了多久和有多熟悉codebase里有多少坑(一般这么move fast的组,codebase很多都是shi山,暗坑无数),组员都很忙 没有时间也没有义务告诉你哪里有坑,自己慢慢踩吧。 现在就想到这么多吧,真心建议大家不要走我的老路选卷组了。珍爱生命,远离卷组!