在我看來，程序員是一個流動性很大的職業。

找工作就像找對象，也講究緣分二字。

只有找到適合自己的工作，才能和“這份工作”過得長久。

想要去一家公司，一定要提前打聽好這家公司的風格，自己是否可以接受。

每家公司都不會盡善盡美，但要找到最適合自己的。

今天分享一位博主，從華為轉正到離職的經歷，一起看看他的故事。

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

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

試用期與加班工資

一般而言，試用期持續的時間為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這個位置，否則未來的發展一片渺茫。

功能開發

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

舉個例子，一個任務，參與設計的開發和測試預估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準時響起，我又得拖著疲憊的身體騎車奔向公司，經歷從早上0930的忙碌一天。

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

總結

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

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

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