從華為離職了

作者：Bai Bing
原文：https://zhuanlan.zhihu.com/p/485029198

遺憾的是，我轉正后看到了大家的能力和努力，也意識到在預期的時間內難以達到我想要的高度，最終經過各方面的考慮，決定放棄這個職位，重新回到外企找回適合我的節奏，

依依不舍的離職后，回想起來，覺得我在華為的經歷特別珍貴，所以在此做個記錄，

試用期與加班工資

一般而言，試用期持續的時間為3-6 個月，工資、獎金都按正式員工的標準計算，據我所知，唯一的區別在于，試用期的員工，周末加班不能轉調休，相當于白加班，因此，不到最忙的時候，組長（PL）不會叫試用期的員工周末加班，如果非得加班，也會通過外出公干的方式讓他們調休，

我聽前輩們說，在2019年~2020年的時候，由于華為被美國制裁，曾采取過所謂的戰時狀態，那時候的壓力是最大的，作為補償，華為也額外劃撥了資金進行激勵：正式員工周末加班，會直接換算成雙倍工資下個月發，如果周末兩天都加班，雙倍工資就是4天，這樣相當于基本工資漲80%，接近翻倍了，當然，這種連續的周末加班也很消耗精力，無論你有多么強的體魄或是多么年輕，最終都不得不承認：命要緊，

現在周末加班，依然按雙倍工資計算，但不會下月發，而是給你累計，直到8年一次換工號，或者離職的時候，才會統一給你結清，并且，周末加班也需要主管審批，不再按打卡時間直接計算，

隨著作業的深入，我逐漸開始理解華為制定一些政策的原因，開始理解它為了獲得最大的收益而做出的取舍，

招聘

我們剛畢業那會，就聽說過華為只要是985/211的學生就招，編程題通過就行，幾乎不看你的個人經歷，當時我不理解，覺得這樣很容易招到一群廢物進來啊？

進來以后我發現，華為會以不信任員工為基礎，建立一套完善的制度和流程讓員工把活干漂亮，承受不了壓力的人被淘汰，承受住壓力并遵從制度和流程的人能活下去，在這基礎上智商、情商特別高的人會拿錢到手軟，

在這邊，每個員工都可能參與招聘，這幾乎成了他們在華為職業生涯中的必經之路，他們會根據現有的人才庫，挨個打電話詢問就職意愿，并引導他們做面試題、在線編程并參與面試官的1對1面試，

我猜測可能是存盤的預算不太夠，因此招聘的時候傾向于招OD/WX的員工，OD的員工工號以300開頭，WX的員工工號以WX開頭，這兩種員工都不算華為的正式員工，其中OD的員工相對更優秀些，主要從事開發作業，而WX開頭的員工基本只能從事測驗作業，他們按照測驗檔案一步步執行并查看是否符合預期，絕大多數WX員工并不知道自己為什么要這么執行，預期的結果代表著什么，因為他們沒有資格參加方案的設計和串講，也沒有TDE(Test Design Engineer，負責設計測驗用例的華為員工)愿意跟他們講解，

由于存盤這邊的人員流失較大，因此招聘的任務就很重，同時，存盤又傾向于招聘OD/WX的員工，所以招聘難度會很大，總結一下就是：有能力的人看不上OD/WX，沒有能力的人又過不了在線編程等考核，

月度答辯和轉正答辯

在試用期，每個月都會有一次月度答辯，你要做PPT詳細描述在這一個月內你做了啥，學到了啥，并現場回答評委的問題，在轉正那一次，又需要準備轉正答辯，把整個試用期的作業進行總結，

幸運的是，由于專案過于緊張，最終我從試用期到轉正僅僅參與過3次答辯，包括轉正答辯，

在答辯程序中，評委們都會認真聽你講，并經過思考詢問你一些問題，這種氣范訓是不錯的，實際上，答辯對績效的作用并不是特別大，因為你平時做的事情大家都能看到，也能估算出分量，

答辯最大的作用，在于防止新員工偷懶，當一名員工進入公司后，在完全熟悉流程，成為一顆忙碌的螺絲釘之前，會有短暫的空窗期，在這個階段，由于你啥也不懂，沒人會找你，也沒法給你分配任務，這時，如果你知道每個月都需要報告作業和學習進展，就會產生足夠的動力，盡快融入團隊，

轉正答辯完成后，基本上你已經是一顆標準的螺絲釘了，這時候不再需要答辯，通過績效考核進行激勵即可，

可信認證

對于存盤的開發而言，每個人都需要通過可信考試，

可信考試分專業級和作業級，一共四門課，四個考試，往往新來的員工更容易通過，因為他們有更充足的時間；而老員工沒有時間學習，幾乎都是裸考，最多有一兩個晚上的時間看資料，因此通過率更低，

我比較幸運，很容易就通過了專業級（畢竟要求17級及以上的員工必須通過專業級），從我的角度看，可信認證的知識真的總結的挺好，是下了功夫歸納的，除了科目一的在線編程，其他科都是理論知識，涵蓋的范圍包括編程語言語法和技巧、編程語言規范、需求分析、安全紅線、設計模式、敏捷開發等等，我在閱讀那些學習課程和資料時，有強烈的似曾相識感覺，因為很多都是我經歷過的場景，摔過的坑，這些經驗被總結成精煉的語言，通過以考促訓的思想灌輸到每個員工的腦子里，

可惜的是，由于極大的作業強度，所有人都是以通過認證為目標，他們幾乎不看課程和資料，直接在心聲論壇里面搜索往期的考題，背答案，以盡可能快的速度通過考試，白白浪費了好多精典的資料，這一點挺遺憾的，

介面人

從入職到導師脫手，其實就差不多兩個月時間，這段時間應該是最幸福的時光，最重要的任務就是通過可信考試，兩個月后，開始接手一些簡單的任務，修改問題單或者承擔一些簡單的功能開發，

但在一些部門，這時候往往會給你一個恐怖的任務--介面人，

一般而言，一個產品會被分為多個模塊，每個小組維護一個或多個模塊，當測驗發現屬于某個組的模塊出現問題，或者別的模塊依賴該模塊的部分作業不正常時，他們需要有人能幫忙查看原因，這個人就叫介面人，

一個組大概10個人，負責的模塊代碼量在數十~數百萬行的級別，乍一看，會覺得應該選一個經驗豐富的員工，對組內負責的模塊、歷史情況等掌握很清楚的人作為介面人，但實際上，幫他人看問題找原因，是一種吃力不討好的作業，因為領導看不到，身邊的同事也感知不到，

在外企，這個介面人通常是主管(Manager)，他會對問題進行簡單的分析，再根據組內成員的擅長領域、負載情況 ，選擇合適的開發去分析該問題，在華為，類似的崗位是PL，為了績效，他們不可能每天把時間浪費在這上面，同時，組內的每個人都忙得要命，最熟悉該領域的人可能正在完成緊急任務，根本沒時間去分析，因此，PL通常會找組內資歷淺一些的同事去充當介面人，并按固定期限輪換，

一個組維護的代碼量不算小，讓新員工去做介面人，美其名曰“鍛煉”，實際上是讓他去抗壓，作為介面人，PL的要求就是盡可能不打擾到組內其他人，所有問題，除非真正是Bug，否則不能讓測驗提單，這樣的要求看似簡單，但對于新員工而言，很多時候測驗咨詢的問題你連他講的啥意思都不明白，再加上設計又存在各種歷史原因、特殊情況的考慮，新員工大多是懵逼的，想求助經驗豐富的同事？如果專案不太緊張的時候還好說，專案緊張起來，每個人都戴著耳機在通話，你可能好幾個小時都見不到他們空閑下來，而測驗對你的回應時間是有要求的，一小時不給清楚解釋？那就提單吧，

舉個例子：你在分析A問題發生的原因，閱讀完全陌生的代碼，另外2個測驗給你留言，找你咨詢B、C問題，你簡單掃了一下B、C問題，都不是你熟悉的領域，需要花時間去讀代碼，了解設計，才知道是不是問題，所以你暫時沒回復，兩分鐘后，兩個測驗分別給你打電話，你很煩，不想接電話，但他們不停的打，并在留言中告訴你再不接電話就提單，你只能接起電話好言相勸，告訴他們現在真的很忙，只能請他們先登記，排隊等你的訊息，沒多久，你讀到A問題中一部分看不明白的邏輯，想找人問，一抬頭組內所有人都在打電話，于是你咬咬牙一邊跟A的測驗確認測驗用例的邏輯，一邊忽略部分看不懂的代碼去猜測后續的邏輯，這時候B、C的測驗告訴你不能再等了，上面催著要提單，你只能暫時放下代碼再次解釋，給他們合理的截止期限并請求他們接受，突然電話又響了，是一個電話會議，問題很嚴重，線上四五個開發正在一起討論，需要你做確認，TDE催促讓你趕緊看，搞不定就往上捅，你趕緊放下A問題，一邊讀D問題的現象，一邊憑你的理解去回答這幾個開發的問題，D問題的難度不大，但涉及的條件特別多，變數也多，邏輯很繞，你得理一下，正在理的程序中，A測驗的TDE氣憤的給你留言：都看了兩個小時了怎么還沒結果？必須提單了，

如果實在搞不定了，測驗等不及要提單，一般是要跟PL講的，但作為新員工，你要做好心理準備，因為這時候免不了一頓臭罵，因為PL永遠是忙得要死，他有方案要討論，有設計要做，還有大量組內雜事，本來已經焦頭爛額，你不僅不能幫他分擔，還告訴他現有的某個問題搞不明白，他也是很崩潰的，但這頓罵往往又是值得的，因為PL會快速給你指明方向，因為如果是定位偏了，他會快速糾正你的方向（順帶著煩躁的大罵幾句），

這大概就是介面人的作業狀態，上午9：40_{11：30，中午14：30}18：00，晚上19：30~21：30是高峰期，

問題單

剛才提到很多次“提單”，就是指的問題單，測驗提的問題單，一般代表某個模塊的功能有Bug，

問題單的跟蹤，華為有一套系統叫DTS，測驗提單，開發解決的流程大致如下：

1. 測驗外包員工在DTS系統中創建一個問題單，填寫產品、版本、問題描述等資訊，
2. 問題單提給負責該模塊的測驗TDE（華為正式員工）審核，
3. 測驗TDE把問題單轉發給負責該模塊開發的組內PL，
4. 組內PL再把問題轉發給需要解決該問題的開發，
5. 開發把問題解決，提交代碼，填寫根因分析并把問題單轉給組內PL，
6. 開發同時需要與測驗TDE預約時間，與測驗TDE串講問題單發生的原因和修改后的影響，
7. 組內PL等串講完成并且最新的Build包含開發的CommitId后，將問題單轉給測驗TDE，
8. 測驗TDE將問題單轉交給測驗外包員工進行驗證，

這么一套流程走下來，感覺脫了層皮，這大概就是所有開發都聞問題單色變的原因吧，

對于上級領導來說，他不需要知道細節，只需要要求一個組的問題單的目標數量即可，比如今天整個組剩下40個問題單，明天的要求是35個，后天是30個...

于是，為了達成目標，PL非常反感問題單走到自己組頭上，有的問題單涉及到模塊間的協調處理，測驗提單的時候發現的是A模塊的問題，但A模塊經研究后發現，實際問題出在A模塊依賴的B模塊身上，B模塊由另一個組維護，于是跟B模塊的介面人溝通，這種情況，即使已經基本確定是B模塊的問題，B模塊的PL、介面人也會想盡一切辦法拖延問題單走給B模塊的時間，定位問題根因和修改方案后，才會同意問題走到B模塊，畢竟每天的問題單目標放在那里，多一個在自己頭上，都是沉重的負擔！這種時候，A模塊的PL肯定也不希望問題單在自己組，所以這時候就看他們兩個PL的PK了，作為PL，至少都在華為奮斗了好幾年，大家像戰友一樣有感情，互相理解下，這次留給你，下次留給我，互相不撕破臉，

在這套流程中，開發最不喜歡的步驟就是測驗串講，這個設計的初衷是好的：擔心你的改動造成的影響測驗不清楚，從而無法對受影響的場景進行測驗，但遺憾的就是這個規定太死板，絕大多數的串講根本沒有意義，只需要測驗進行原場景復現，并檢查問題是否解決即可，

我覺得之所以問題單的設計如此復雜，依然是對員工的不信任，在外企，流程就簡單多了：

1. 測驗創建問題單，填寫產品、版本、問題描述等資訊，
2. 問題單提給需要解決該問題的開發者，
3. 開發把問題解決，提交代碼，填寫根因分析和需要重點測驗的場景，把單轉回給測驗驗證，

步驟的簡化，就對員工的素質要求高，就拿問題單與測驗的串講來說，一般開發人員覺得這個改動的影響比較大，可能需要重點測驗一些場景的時候，就會在問題單上注明；同理，測驗如果意識到開發人員的改動有風險，或者對開發人員的根因分析不太理解時，也會主動找開發人員溝通，

華為的流程復雜，它的基本邏輯是：信任DE/TDE這種在華為干了很長時間的優秀員工，新員工不值得信任，配套的激勵也是傾向于PL/DE/TDE，這會讓新員工做得很憋屈，但這沒關系，因為總會過濾出一批忍得住憋屈，愿意遵從規則堅持努力下去的人，外企的流程簡單，每個員工都干得很開心，但是如果出現一些想偷懶的員工，公司的確沒有太多拿得出手的整治方法，頂多就是長期不漲工資，

復雜的流程導致了一個問題，就是測驗TDE的繁忙程度超乎想象，因為一個測驗TDE往往負責多個模塊，也就是對應著多位開發，當問題單較多的時候，容易形成了單點瓶頸，舉個例子，假設一名TDE手上有10個外包測驗員工，分別測出了10個問題，這10個問題對應著8個開發，那這8個開發人員修復完問題后，跟外包測驗員工串講并不算數，必須排隊給這名TDE串講，從而形成了單點瓶頸，

測驗TDE忙得找不著北，脾氣自然也不會太好，開發更是一點也不敢得罪測驗，如果TDE不爽你，別的不說，就單單在串講里給你挑刺、或者把你的串講排到最后，都會大大拖慢你的作業進度和作業熱情，

代碼檢視與Committer

代碼檢視，也就是Code Review，每個開發寫好代碼后，都必須發代碼檢視才能合入主干分支，

在外企，一般開發會找對這個領域比較熟悉的兩個開發進行檢視，得到兩個Approve以后，就順手合入了，

在華為，代碼合入理論上需要以下步驟：

1. 選擇兩個開發檢視
2. 檢視通過后選擇一個Committer審核
3. 審核通過后，選擇具有合入權限的人合入，

一般Committer是在一個團隊里的資深員工，技術比較強，并且做事仔細認真，

在一般開發階段，權限會放松很多，步驟簡化為：

1. 選擇一個開發檢視
2. 檢視通過后找一個Commiter檢視并審核再合入，

Committer的數量是很少的，大概占20%左右，100個人要合入代碼，都得找這20個人進行代碼審核，這部分人基本已經是DE(Design Engineer)，主要承擔方案設計、困難問題攻關等任務，同時還要幫大量的同事檢視代碼，所以他們大多也會忙到找不到北，

這些Committer一方面承擔著方案設計等專案上對自己未來有利的作業，另一方面檢視所有人的代碼，有任何問題得會得到耐心的解釋（不解釋清楚就不會給你審核通過），所以他們的進步會很快，而新員工大多只是執行者，對整體規劃、背景原理等都搞不清楚，他們想讓Committer耐心解釋是不可能的，只有在審核代碼的時候，能學到點東西，但也是零零碎碎的，

這樣以來，新員工和老員工(Committer)的差距就拉開了，最終導致的結果就是知識斷層，新員工很容易流失，因為他們只能在繁瑣的作業之余進行自學，老員工沒時間教他們；同時他們得到的激勵也相對較少，除非拼死拼活爬到Commiter這個位置，否則未來的發展一片渺茫，

推薦一個開源免費的 Spring Boot 最全教程：

https://github.com/javastacks/spring-boot-best-practice

功能開發

一個需求過來，需要評估完成的時間，但這只是一個參考，每一級都會想辦法把時間往短了壓，導致最后到開發者這一層，幾乎是不可能完成的任務，

舉個例子，一個任務，參與設計的開發和測驗預估12+4天，版本給的要求是10+3天，但當這個任務真正給到參與實作的開發和測驗時，可能只剩下6+1.5天，

中間的時間到哪兒去了？從上到下，每一層領導都擔心任務完不成，所以想預留一點緩沖，所以時間從10+3天傳達到下層變成8+2.5天，逐漸往下最終變成6+1.5天，

所以，功能的開發極其緊迫，你想在規定的時間里完成幾乎是不可能的，

一開始，我會因為完不成任務非常焦慮，后來我發現，原來大家都完不成，目標放在那兒成了擺設，雖然目標時間快到了就開始催，但實際上做不完也不會怎么樣，不過，催你的人心里是有底線的，這個底線就是他的上級給他的要求，只是這個底線他永遠不會告訴你，

出征海外

出征海外，一般是指的上一線去海外銷售我們的存盤產品，可以選擇的駐扎地很多，幾乎全球都可以，但是選擇歐洲那些條件好的國家，補貼很少，選擇非州那些條件不好的國家，補貼很給力，

在存盤這邊，每年需要出征海外的人數是有指標的，幾乎每個團隊都要出人，

除了極少數愿意舍家棄子去海外打拼的小伙伴，絕大多數人是不愿意去的，所以，要求你去海外，和逼你離職差不多，基本成了淘汰人的方式，

我看過幾個能力還不錯，經驗也比較豐富的員工，被要求出征海外，他們雖然沒有Committer這么拼，但五年左右的時間也讓他們積累了很多知識，也算是骨干員工，無奈的是，由于這個硬性規定，不得不選擇離開開發崗位，

其實我很不理解，這些作業五年左右的員工，對他作業過的模塊應該是很熟悉了，好不容易達到了這樣的水平，也適應了華為的作業強度，這時候應該是他們發光發熱的最佳時期，但華為卻讓他們出征海外，重新招新員工進來再經歷一次痛苦的學習和適應程序，

實際上，這些開發者的知識對海外銷售而言起不到多大作用：你掌握了產品中你們組負責的某個模塊，里面包含數百個結構體和數千個欄位，你能理解每個欄位的含義和設計它們的原因，所以呢？那又怎樣？在銷售的時候，客戶對此是不感興趣的，客戶感興趣的內容，還是需要參加培訓才能掌握，那為什么不直接讓新人去做銷售呢？

選擇離開

其實對我而言，錢給到位以后，最在意的有兩點：

1. 作業輕松
2. 前途光明

這兩點只要滿足一點，我就不會考慮離職，如果兩點都滿足，那我會誓死效忠，

首先，主要是我自己的原因，因為我一直知道華為作業不輕松的，

我家離公司車程大約40公里，雖然樓下就有班車，但班車以早上08:30到達為目標（以行政的標準上班時間08:30~18:00為準），所以發車時間為早上07:10，也就是說，我最遲06:50就得起床，刷牙洗臉后趕緊下樓上班車，然后在班車上搖搖晃晃的睡覺，

我有好幾次做噩夢，夢到因為莫名其妙的原因導致沒趕上班車，內心崩潰到了極點，

兩個月后，我實在受不了，決定在公司附近租房，平時騎自行車上下班，這樣，早上可以睡到08:50，每周末回去一次，一開始還好，但隨著作業壓力逐漸變大，周末慢慢開始變成單休，相當于我周六晚上回家，周日晚上10點左右，又得坐地鐵回出租屋（為了周一早上睡個懶覺），本來這樣也能適應，但我女兒滿一歲以后，變得越來越可愛，我舍不得那種離開她的感覺，我在家里客廳安裝了一個360攝像頭，每天吃晚飯的時候，就看著我媽和女兒玩耍，有時候透過攝像頭喊一聲“甜甜”，女兒以為攝像頭就是我，經常仰著頭對著攝像頭喊爸爸，令人心酸，

其實在入職前，這個問題我也有想過，當時的想法是，在華為如果能安定下來，就在郫縣租一套好點的房子，把一家人都接過來，每天中午可以跟家人吃個飯，晚上偶爾也可以跟家人一起吃飯，但后來我媽不太愿意搬走，我老婆也遲遲沒有找到合適的房源，最后不了了之，另外，每天中午、每天晚上都要騎行5公里左右回去看一眼女兒，確實也挺折騰，加上作業越來越忙，人也越來越疲勞，哪怕真的興師動眾的搬到郫縣，效果也不大了，

記得那段時間，最難受的就是每天晚上吃過晚飯，從園區散步回公司的那一刻，我會問自己，天已經黑了，我為什么還不能休息？我干的事情有多大價值，對我到底有多大吸引力？每天都這樣，我該怎么享受生活？當時有句話特別火，叫青春才幾年，疫情占三年，那種感覺類似于此，

其次，就是個人職業的發展問題了，

作為新員工，我所在的部門，我只能勉強跟入職一年左右的同事共事，有一種說法：你的績效在PL給你分任務的時候就已經確定了，PL可以分給你有價值、有曝光度的重要任務，也可以分給你吃力不討好的雜事，作為新人，自然是要從打雜開始，而身邊的人都兢兢業業，我擅長的知識在這里又起不了作用，發展的前景可想而知了，

我仔細思考過，如果我要達到骨干的水平，至少也要兩年的時間，這么長時間沒有自己的生活，而且年齡越來越大，還面臨被派去海外的風險，實在不值得，

跟我同級別的同事，基本都是DE，他們在存盤作業的時間大概是8~12年，我的作業年限差不多，但作為新人加入，要學習各種工具，了解華為的存盤架構、代碼細節甚至是各種設計的歷史原因，哪怕拼盡全力也要5年才能達到他們的水平，

最關鍵的是，這些作業了10年甚至更長時間的員工，還一個比一個卷：你以為每天晚上2點回家很卷了？又冒出連續作業30小時的，你覺得任務太重，一周完成是不可能的，人家可以五天完成還順帶做了很多其它任務，相比之下，我充分認識到自己精力、智力和能力的差距，

這種巨大的競爭壓力，也使得我神經上出現了些問題，我記得有一次晚上10點，我坐地鐵回出租屋，到出租屋快12點了，我洗漱完后想著玩會手機困了就睡，結果一直到2點也絲毫沒有困意，我玩半小時，試著睡半小時，反反復復好幾次，一看時間，已經5點了，那種時候是最恐懼的：眼看著天快亮了，一點睡意也沒有！

那天我一直挨到天亮，早上7點過，才在外面熙熙攘攘的車流聲、人流聲中睡著，這應該是我這輩子唯一一次失眠，鬧鈴在08:55準時響起，我又得拖著疲憊的身體騎車奔向公司，經歷從早上09:30到晚上22:30的忙碌一天，

在輕松和前途兩頭都不占的情況下，我最侄訓是決定投降放棄，其實，還存在轉崗到其他部門，開發新產品，大家在同一起跑線的機會，如果新的作業機會晚點出現，我可能會提出轉崗，或許就不會離開華為了，

總結

總體而言，華為的競爭力真的比外企強太多，它通過殘酷的內部競爭，讓員工把活盡可能干漂亮，這雖然換來了大量員工的抱怨，但不妨礙公司的快速發展和進步，

最終離開華為，回想起來還是非常不舍，想起跟大家一同奮斗的場景：站會時PL跟我們挨個定目標，同事間的討論和幫助，測驗串講，Story設計，多個模塊的同事共同實作的功能等等，還是讓我覺得這是一段珍貴的經歷，

只能說為了家庭和生活，我做出了妥協，放棄了作為奮斗者的機會，最后，希望跟我一同奮斗的小伙伴們都能得到自己想要的，不留遺憾！

近期熱文推薦：

1.1,000+ 道 Java面試題及答案整理(2022最新版)

2.勁爆！Java 協程要來了，，，

3.Spring Boot 2.x 教程，太全了！

4.別再寫滿屏的爆爆爆炸類了，試試裝飾器模式，這才是優雅的方式！！

5.《Java開發手冊（嵩山版）》最新發布，速速下載！

覺得不錯，別忘了隨手點贊+轉發哦！

標籤：Java

上一篇：自定義注解實作加解密及脫敏

下一篇：day40-網路編程02