從碼農角度談談Facebook的優缺點

標題有點 click bait,跟上次的真裸辭相比這次下家找得八九不離十了算是半,另外辭職也不全是臉家的問題。不過終於決定了下家去哪之後也算展開了人生新篇章,可以把承諾給大家的(Who cares)年終居家旅行上班劃水必備良品總結一下了,自己整裝待發的同時希望也娛樂一下大家。

我在一畝三分地和知乎都有號,之前有人盜帖已經被 Warald 親自打臉抄送我然後把盜文者刪貼扣分了,所以請某些人潔身自好,淪為跟營銷號一樣沒節操。人都在美國了就別玩天朝貼吧那套了。

另外大量中英夾雜預警,不爽請提前退出不用留言告訴我了(Honestly why are you still reading my post)。

TLDR: Just get into FB (or better, Google) first and then figure out from there. 萬一喜歡皆大歡喜,不喜歡想跳走也非常容易。

雖然平時在豆瓣上麵沒少黑你臉(見工作吐槽合集豆列,和“出道”日誌就大黑你臉 ),但毋庸置疑 FB 作為一個工作選擇優點還是很多的(我承認先寫優點部分原因是被友鄰指出我再吐槽你臉快要成為豆瓣低配版王垠了,沒有垠神的技術還得了垠神的病,which I'm trying to avoid)。

1.1 The good

1.1.1 錢

普通小公司因為有明顯 pay cut(Senior 及以上級別 up to or more than 50%),因此在此隻比較 FANG 及同級別大公司。錢的優勢不是指同 level 比較,而是同樣年資、水平的普通人(非大牛)在工作幾到十幾年,在臉家可能招聘 bar/升職更容易(以下 level 僅針對 IC,individual contributor,不包含 PM,EM 等管理崗)。如 E4 遠比狗家 T4 容易,E5 遠比 T5 和 Amazon L6 容易,E6 - E7 比狗家 L6、7 常見,更不用說 Amazon 的 L7 了。E3 - E5 的情況基本確認屬實,往上僅憑個人觀測和道聽途說,僅供參考。level.fyi 上有所體現,但現實裏 zoom in 到普通人 level 裏,差距可能比看起來更大。

拿臉家 E4 - 狗家 T4 - Amazon L5(SDE II) 來說:

- 臉家 more like ”能獨立幹活有一點工作經驗的社招最低 level“,給的包比較標準不至於太掉價,但不是 terminal level,有升職時間壓力,基本上 new grad 全 meet 從 E3 - E5 標準升職時間線應該是三到三年半,再慢有被 PIP 風險。社招基本 1 - 5 年經驗常見 E4,上次甚至在見到一個 8 年經驗的在有 compete offer 的情況下被 down level 到 E4 的,給的包可能還沒人家在別處拿到的一半,也是沒自知之明。

- Amazon 是能獨立 deliver 在組範圍內有影響力的大 project,但 range 也比較廣,見過很多有一到三年甚至接近四年工作經驗的人被 down level 到 L4 (SDE I)的,也見過許多靠譜實幹的中年碼農(七八年以上甚至十幾年工作經驗)的 SDE II,這兩年有錢了給的 comp range 也比較大,基本加上 signon 勉強跟上臉狗兩家,臉內部也是把 high level SDE II match 到 E5。L6 (SDE III,Sr SDE)前些年 bar 比較高,地裏出了個 4.5 年升的前所未聞的大神,如果有人能在亞麻呆那麽久的話從 new grad 到 L6 花六七年算是比較正常的時間,一直 L5 也不會有升職壓力。這些年 bar 稍有降低,從外麵招 5 年經驗的也不在少數。

- 狗家則是瘋狂 low ball down level,很多兩三年工作經驗優秀的碼農都是衝著情懷和“進去馬上升職”的餅 T3 進去的(當然也有麵試出色拿到 T4 甚至 T5 的)。

雖然三家衡量標準不同但是 comp band 基本一致,這就造成了職業早期去臉家很可能在錢上就贏在了起跑線(據說狗家 refresher 多,但我沒有特別關注過具體數據)。臉家的理論是我們 move fast 所以我們的人成長速度快,事實如何就見仁見智了。

1.1.2 福利

見識短淺的我隻經曆過著名血汗工廠的洗禮,這次找工作也大概瞥了一眼小公司的福利,對比起來 FB 真是對員工慷慨得很。開始對 FB 有 grudge 的時候也經常戲稱 FB 是拿錢買幸福感。

先從我之前 take for granted 的醫保來說,很多小公司是不 cover 員工本人月費的,甚至 frugal 著稱的 Amazon 也不;Onsite mental health support 和 medical center 很多小公司當然也沒有資源去做,更不要說免費 25 次 therapy 了;意外死亡險公司免費 cover 到 2X 還是 3X base,作為對比,我這次麵的小公司有才 cover 70k 的——對,死了才給 70k;公司免費 cover 全球旅遊保險,不管是 business 還是 personal trip;可以用來 gym membership、滑雪票或者 massage 的 wellness reimbursement 很多公司都有就不說了。

園區設施周到到 ridiculous——網紅樓頂空中花園、鮮蔬現榨攤、種類豐富的零食、免費冰淇淋、奶茶、gym、boulder 就不說了,還有街機廳、音樂室、木工間、印刷館、手工坊、獻血點,人工免費的自行車店,收費修車、幹洗、理發、牙醫、massage、SPA……在在各個 campus 之間有內部 on demand 專車接送往返服務。真是牢牢把員工套在園區,生活服務一條龍,甚至園區本上都是個不錯的旅遊景點。

電子產品配件有免費 vending machine,電池鼠標 touchpad 這種東西直接自取。公司 Amazon business 賬戶辦公用品、書什麽的一定金額以下自動 approve。每四年還有 300 刀耳機 credit,前兩年人手一副免費 QC35.

很多服務也有折扣,turbo tax 稅後報銷, 50% 的 headspace subscription,免費的 financial times subscription 等等。先前還有免費 lyft code,後來為了省錢取消了,改成發 corp commuter/parking card 了,也有每月幾百塊額度。

1.1.3 鍍金

不需要鍍金的大牛請跳過本段。對很多人來說,鄙視”工作這麽多年了能炫耀的還隻有學校/第一份工作的公司“在網上說起來輕鬆,工作了年發現很多人的高光時刻還真就那些了,如果對其他路線沒有絕對激情的話走 easier path 並不可恥。

說來好笑,有個朋友吐槽他以前在某養老公司,social 圈裏的人都愛理不理,進了 FB 之後立刻被積極 social。之前亞麻在簡曆上已經很好投了,但臉家更甚,部分小公司甚至會擔心你 over qualify(麵試都不給的很少,不過這種公司你八成也不會去)。甚至在 blind 上講同樣的話的仿佛你 credibility 都高了一些(對比起來目睹了很多 Amazon 的人被揶,大家也知道 blind 上大家多喜歡 troll 的,哪怕是嚴肅話題)。

所以非大牛 new grad 有選擇的話,還是建議在職業早期進有名大公司遠多過有些哪怕當時看起來 prestigious 的小公司,除非認定了那個公司是千載難逢的下一個 FB 能讓你暴富。想要追求情懷等簡曆鍍好金多幾年經驗什麽地方都能投進去再去不遲。我工作短短幾年已經見到好多當年逼格高的公司跌落神壇了(比如 evernote)。有經驗的 recruiter 可能知道當年誰家 bar 高,但是市場上沒有經驗也不懂業務的 recruiter 多得是。過了幾年你當年的 startup 不幸沒有成為下一個 FB 甚至 Uber 的話,這些水 recruiter 眼裏你的簡曆含金量打折扣。跟進名校鍍金一樣,進 FANG 蓋了兩三年的戳受益十幾年。

1.1.4 內網

Workplace (一個類似 Facebook 功能的內網)用來工作是一大毒瘤,用來幹其他的真是寶藏。包括——最詳細真實無私的理財、職業經驗,最好用靠譜的二手交易平台(多次貨還沒交錢就打來了),同事為你精選的最好看的貓狗視頻和各種 meme 等等。我辭職的時候最懷念的不是福利不是經曆而是內網。

1.1.5 Autonomy

雖然不敢保證每個人都有時間做 20% project,但是我見聞的組大多數都沒有 micro management. 我第一個組沒有 standup, 每天在工作組裏 update + weekly meeting sync,後來大家甚至連 update 都不寫了。第二個隻有 weekly sync,到後來甚至 sync 也偷偷取消了。 self-driven 的人可能如魚得水。

1.1.6 internal mobility

我換過一次組,基本上是 manager 挽留失敗發現我去意已絕之後,我跟對麵 manager 碰個頭,倆 manager 碰個頭就換了。IC 轉 manager 應該也較為容易。不同職位轉崗也見過(別的職位轉 PM 等等)。

1.2 The bad

眾所周知,大公司的組間差距很大,所以不排除我運氣不好碰到許多問題,也不排除有些人碰到良師益友組。以下問題 case by case。

1.2.1 Messy code base and shitty code

我 Bootcamp 的時候發現整個 FB 還是 monolith 的時候震驚了,無法想象一個工程師數千(可能上萬?)的公司還是這樣運作的。我這次在麵的小到隻有 200 多人的公司都要麽已經有 micro services,要麽正在 refactor/service split。這次求職一個麵試官麵完 system design 答完無題可問之後閑聊問我 FB 各個 service 之間用什麽 protocol,我說是 monolith 之後他震驚了半天反複跟我確認了兩次 I meant what I said。

有人認為(這麽大規模的) monolith 也有好處,比如(更正,此段 pending monolith vs monorepo 的區別,我本意是吐槽 monolith 但是被友鄰提示好像瞎子摸象了?)可以自由地去別的組別的產品的 code 裏改代碼(/更正完),take ownership. That's not my understanding of ownership though. 我認知中的 ownership 是在你的職責或者能力範圍內積極工作、幫別人解決問題、self driven、不甩鍋,不是醫生在前線奪過士兵的槍擾亂戰術去送死,不是園丁為了剪草坪而把你種在地上的菜鏟掉,不是 loan agent 拿了你的 downpay 私自換了套抽成更高的房子賣給你。

然而現實裏這不是一個幾十人的 startup,任何東西都有一大堆 context。But here people have to go around changing other people's code without actually understand their code,更沒有責任維護,one time hack and workaround are everywhere, 久而久之代碼質量越來越差,連自己組都不知道很多部分怎麽 work.

由 monolith 和沒有 design 及 documentation 聯合產生的問題是很多 service 沒有 well structured or even stable API,頂多算一堆隨手亂放的 functions。功能模糊,命名混亂,參數拆東牆補西牆,deprecation and migration 隨處可見,隻能一次又一次地”亡羊補牢“式 code quality 項目中大規模反複造 impact 互相消磨”升級“到新的一套輪回中。

Teams consistently migrate, update and deprecate things without communicating to either their upstream, downstream or each other. 本來經常維護、improve 代碼是好事,但在沒有 API doc,沒有 context ,沒有 timeline and milestone 協調下各自為政對整體效率是巨大的災難。我見到過不止一次,正確的 document 給出完全錯誤的答案;大量 API 無法分辨新舊程度,也沒有 guideline,用的時候沒頭蒼蠅般瞎找或者在 Q&A group 裏搜有沒有人問過 hope for the best,push 的時候沒有人 review;因為以為早就協商好的項目 dependency team 暗中 migrate API 導致 client team 發出去了 code review 才發現代碼作廢;Upstream partially migrated schema 導致中間層舊 code 在原地,按新方法寫出來的跟舊 code 不兼容,且無法手動 fallback 舊方法,最後用更 hacky 的方法繞過本來是為了提升代碼質量的 migration。

有一次我在 work group 發帖->ping -> cut ticket 了別的組一周,每次都反複被甩鍋說不是他們的問題,為了 unblock 自己我去 office hour,A 告訴我啊這個問題我們已經在上個 release 修複了,我問哪個 commit 修複的,曰不知道。我回去查了所有 commit history 找到 suspect,問 diff 作者 B,作者說哈?I have no idea what does the code do。又 ping approve 那個 diff 的 eng C,C 說我不知道那個 diff 幹嘛的,你問 reviewer D 他更熟. D:哦是嗎?修複了?我:×%&……#¥……%

還有一次我要加一個新 logger,居然發現全公司的 logger 不分組不分功能全都在一個大 directory 裏,然後下麵的 sub folder 是按首字母命名的。比如 GoodDayLogger 會在 /go 目錄下,BadDayLogger 在 /ba 目錄下。When I saw it my face was like

bootcamp 的時候因為 package 太大公司發我的電腦甚至 index 不了 bootcamp Android project。

1.2.2 System design isn't a thing

我先開始以為是組的問題,於是在內網找重要 infra 組的 design doc,結果找到一張白板手寫照片:)這還是好的情況,大多數組根本沒有。

我又以為是我 level 的問題(meanwhile 幾年前 new grad 的時候進 Amazon 幾個月就有受益良多的 design review 了),參加了多次 tech discussion meeting 之後發現,不,我常接觸到各 level 的項目都沒有 design。我兩天瞎湊出來的 tech notes 已經比組裏我參考的所有 doc 都係統化了。其他亞麻前同事也碰到過類似情況。

甚至有想跳槽的同事跟我表達怕麵試時候在 FB 的項目拿不出去手,不會 system design 題的擔憂。雖然我用 Tushar Roy 安慰了他說突擊就好,但是實際麵試中還是發現 past experience 輪在 FB 的項目真的需要多層次加工才能說。高 level 可能有複雜的項目(which I haven't seen a single proper design doc),但同樣的 entry level 亞麻和狗家的碼農有 design review 和學習的機會可能更多。

1.2.3 Test coverage is surprisingly low

我聽過不止一個人跟我說入職幾年沒寫過 test。We just push the code and hope for the best. 雖然大多數 engineer 不喜歡寫 test,雖然把 test 從個體 engineer 工作中分離出來是 test infra/process 成熟的表現,雖然 setup test run test 比在 Amazon 方便好幾條街,但是在無需為 test 負責的情況下終究有很多沒有 test coverage 的海量新 code 被生產——既沒人知道 test coverage 百分比也沒有 test 來測試被新寫出來或者已經在運行的邏輯。加上糟糕的 oncall metrics, tools, alarms , documentation and triage,用戶抱怨的邊角 broken feature 再由客服層層傳遞踢皮球接到對的組手上往往幾周已經過去了。

1.2.3 管理、維護機製成謎

多次發現以為已經協調好的組間協作等發 code review 給對方的時候對方甚至不知道這個項目的存在;Launch 了之後又要反複跟 marketing/legal 扯皮;甚至做好了個隻管執行的 email 項目,準備發送之前跟我 PM double check did legal sign off for GDPR?My PM was like, what's GDPR? 過了兩星期告訴我,還是先 hold off 吧,要 legal review。所以我要不是 happen to hear about GDPR complains from my friends at other companies we would be in deep shit now???

換了個組有 TPM 了想說話這下不會出現項目協調問題了吧。結果 TPM 除了在每半年的 plan meeting 上帶著大家 review 一下要做什麽項目之外就沒見過人了。

另一個槽點是用 workplace 工作,每天早上看各組和關注的人綜合 newsfeed 或者專門打開各個組看 post,日常工作可能來源於 post,task, direct IM ping,email,基本無法 track 的 workplace/intern notification……這裏還夾雜著其他非工作內容群組,如 meme 群貓狗群生活竅門群公司福利群。There's no proper backlog grooming, sprint planing, milestone tracking。

我某個組的 dashboard/tool 多到一個 wiki 都寫不下,那個 wiki 內部還有多層不同級嵌套,連組內的人都找不到應該用的東西在哪,更別說別的組的人來找資料了。

單就 oncall 就有若幹個 tool 來 monitor metric/set and trigger alarm/find logs/file ticket,每一個都難用的要死,更別說光每個組的 runbook 就有三四套,根本不知道哪個是新的。 我就抱怨過:

亞麻出了問題:打開 sev tool,描一眼關鍵詞通常已經找到原因,不行的話搜關鍵詞,找到問題 p90 = 5s, p99 = 5min. Ticket 裏條理清晰實時更新 root cause, solution, ETA。大問題過幾天參加批鬥大會,metrics/root cause/future task/ownership 一目了然。

你臉出了問題:打開 sev tool,描一眼關鍵詞,沒有一個 sev 把 end impact 寫著,搜關鍵詞搜 affected area,找不到。搜 work group,找到有人提了相同的問題,在下麵 +1. 過一陣子等相應組 oncall 回應,然後有人說 shouldn't this be a sev,然後才開一個完全看不懂關鍵詞的 sev。找到相應 sev 50% 靠相應 tool 裏的彈框提示,50% 靠消息靈通人士把 sev 發到群裏。 點進去 Sev 裏不是相關組的人完全看不懂到底發生了什麽,隻能等老司機段子手們總結 TLDR。

1.2.4 急功近利

我切實聽到過"This project won't have any impact this half so let's put it back in backlog”,即便所有人都知道哪怕一年內這個項目對全組和用戶大有好處. 我 manager 在所有 eng 都覺得 plan A 好很多的情況下為了省兩周的時間,跟我們爭了兩周應該用 hacky plan B(黑人問號)。

adhoc 地幫助別人最多獲得幾個 thanksbot,對個人 PSC 幫助甚微,很忙的 infra/internal tools team 有沒有 support,support 質量如何完全看你挨個試出來的 POC 心情,甚至有時候 dedicated POC 也一問三不知。

宏觀上來說,幾個不同組做 slightly different 的東西,不完善舊的提高效率而是做完就扔著重新做一個的情況屢屢發生。往好了說這是我們 try and fail and learn,往壞了說是各組甚至各人反複造輪子,反正從 1 到 2 哪有從 0 - 1 寫在 performance review 上好看。

1.2.5 Performance review related

因為橫向對比經驗較少(隻有亞麻一家),此處隻主觀覺得 FB 的 PSC 問題很多。

全公司彌漫著最高目標是 PSC rating / 升職的氣氛,應該跟年輕人們的升職 timeline 也有一定關係。這一點跟上麵急功近利那一條也直接有聯係。對比起來亞麻可能因為 band 較寬也沒有 timeline,整體氛圍中比較明顯的目標還是 deliver project。

過於強調 impact,比如一個 engineering wise complicated or valuable 的項目,如果最終用戶數據不好,是會反映在 IC 的 PSC 結果上的。理論上來說這是為了讓每個人都 drive for the most impact,但是現實中做什麽項目、項目走什麽方向對初級的 engineer 來說根本 out of their hands。美其名曰失敗的實驗也是寶貴 lessons learned,但現實中沒看到具體體現,做出來東西數字不好被用“impact”不夠卡了 PSC rating 的還是屢見不鮮。

每半年一次的 PSC 聲勢浩大,跟 FB 有交流的外廠人員都能察覺到 nothing get's done two weeks before 7/1 and 1/1(後者本來就 holiday 還能忍)。這是理想狀況,實際中 PSC 前後幾個月全公司基本都生產力低下。

一個評價係統本身的問題是,四個評價的方向平均要求的教條標準。Engineering Excellence, People, Impact, Direction,看起來跟其他公司沒什麽兩樣,但是執行過程中 got carried away too far。如 People 本意是 better coordination, communication, mentorship, recruiting 等等,在實際執行過程中則變成半強製麵試、帶 intern/bootcamp mentor。公司縮招和 recruiting training pipeline 黑箱管理混亂把這個標準的良好初衷變得進退兩難—— 一方麵麵試官被告知沒有那麽多麵試機會,一方麵繼續拿麵試數量當作 performance 的一部分。跟我同期入職的幾個人 end up 在 reverse shadow 裏排超過一年,meanwhile 被用 people impact 不足來卡升職/rating even though they did a ton of XFN work and got excellent peer feedback during PSC。然後這個所謂的 pipeline 並不像該司其他處處 over engineer 連發 tshirt 都有 self check tool 一樣,是人工/郵箱 inquiry 並且得不到具體數據, 完全不透明,無論是 IC 還是 EM 多少次催都沒用, 寫全了 availability 也得不到麵試(Bootcamp、intern 或多或少有類似狀況)。作為對比,亞麻完全不麵試也不帶 intern 的 L6 都大把存在,喜歡麵試的哪怕 L5 也可以自己去向 bar raiser 方向發展,想要 mentorship 的要到 intern 也不難(個人觀察),幾個考量標準有部分達到下一級標準就有 strong case,術業有專攻。

1.3 Verdict

綜合下來,I'm not so sure should I recommend this place to average new grad or not. 一方麵職業早期升職迅速的環境確實在物質,心理乃至社交圈上好處良多,被公司照顧的妥妥貼貼沒有簽證、綠卡、刷題壓力也確實是個 relief,另一方麵急功近利和 bad engineering practice everywhere 又讓人懷疑普通 new grad 能得到多少真正的職業”成長“。不過轉念一想,you can learn that shit anytime anywhere,還是不要跟錢過不去了。早早鍍金再去追求理想/幸福也是個挺好的選擇。

我當初也是抱著“反正不愛上班,不如去個錢多的地方上班”的心態選了碼農這條路,也跳到了 FB。但是此基礎上自身有了更多選擇權之後發現老老實實當合格社畜的能力還是沒有想象中的容易的。所以,才有了這次斷斷續續一年多的不如意之後的重新選擇。

作者:黃信滾(來自豆瓣)

頂: 2踩: 1

來源:盧鬆鬆博客



相關說明:

1、VIP會員無限製任意下載,免積分。立即前往開通>>

2、下載積分可通過日常 簽到綁定郵箱 以及 積分兌換 等途徑獲得!

3、本站資源大多存儲在雲盤,如出現鏈接失效請評論反饋,如有密碼,均為:www.ipipn.com。

4、所有站內資源僅供學習交流使用。未經原版權作者許可,禁止用於任何商業環境,否則後果自負。為尊重作者版權,請購買正版作品。

5、站內資源來源於網絡公開發表文件或網友分享,如侵犯您的權益,請聯係管理員處理。

6、本站提供的源碼、模板、軟件工具等其他資源,都不包含技術服務,請大家諒解!

7、源碼、模板等資源會隨著技術、壞境的升級而存在部分問題,還請慎重選擇。

PS.源碼均收集自網絡,如有侵犯閣下權益,請發信件至: admin@ipipn.com .


源站網 » 從碼農角度談談Facebook的優缺點

發表評論

讚助本站發展 維持服務器消耗

全站源碼免費下載 立刻讚助