入職微軟一個(gè)月感悟
本文是云峰入職微軟一月后的感悟，談及了他的面經(jīng)以及入職體驗(yàn)。
前言
提到微軟，你首先會(huì)想到什么？外企？Windows Or Office？還是 955·WLB？
我在前司待了快三年，自覺到了一個(gè)打工人的黃金跳槽點(diǎn)，于是就想出去試試不一樣的工作環(huán)境。
前司是一個(gè)典型的互聯(lián)網(wǎng)公司，提倡短平快的工作節(jié)奏。彼時(shí)的我，負(fù)責(zé)一個(gè)不大不小的項(xiàng)目，卻遇到瓶頸，怎么也做不大。在我面前有兩個(gè)選擇：吃老本 or 跳槽。
我選擇后者，因?yàn)樵谝粋€(gè)人分飾多角的項(xiàng)目中，我察覺到了我的能力短板：不夠?qū)I(yè)。這又導(dǎo)致了我想好好做成一件事的話必須加班來完成（開會(huì)、溝通用戶、梳理需求、設(shè)計(jì)項(xiàng)目架構(gòu)、編寫代碼、測(cè)試、上線和運(yùn)維、技術(shù)支持和 oncall），而這又讓我失去了業(yè)余時(shí)間去提升我的能力短板，最后的結(jié)果往往達(dá)不到專業(yè)的水準(zhǔn)，從而繼續(xù)惡性循環(huán)。
在環(huán)顧了一圈市場(chǎng)上的企業(yè)后，我選擇嘗試微軟，因?yàn)樵谖铱磥恚兄辽僖韵氯c(diǎn)我非?？释麚碛械臇|西：
全英文環(huán)境，鍛煉英語技能
坐擁多個(gè)大型項(xiàng)目，可以學(xué)習(xí)到專業(yè)的項(xiàng)目開發(fā)流程
可以體驗(yàn) wlb 的工作節(jié)奏
面試
在某一天，我在某 App 上被一個(gè)微軟的陌生人勾搭，簡(jiǎn)單地電面后一拍即合，我向他投遞了簡(jiǎn)歷。
正式的面試一共有四輪，三輪技術(shù)面 + 一輪 AA 面（大老板），每輪持續(xù)時(shí)間一個(gè)小時(shí)左右。
除了最后一面聊了聊人生、理想、邏輯推理等非技術(shù)內(nèi)容。其他三面基本上是項(xiàng)目算法各半小時(shí)。
算法
算法基本落在 leetcode 前兩百道題非 hard 范圍內(nèi)，有個(gè)別題在原題的基礎(chǔ)上進(jìn)行了變式。（我被考察的是數(shù)組、樹、圖、遞歸類型的題目）
與某些公司對(duì)算法題的考察不同，我的面試面板沒有 AC 要求，換句話說就是白板編程，面試官提供的只是一個(gè)空白的在線編輯器。
他們似乎更注重和你的溝通而不是僅僅得到答案，每一輪算法部分我都是先向面試官確認(rèn)測(cè)試用例的形態(tài)，也就是輸入什么得到什么輸出。然后才開始做，做的過程中面試官會(huì)提醒你，然后如果做快了，面試官會(huì)添加限定條件，將這個(gè)題的難度提升一些（類似 leetcode TwoSum -> ThreeSum）。
項(xiàng)目
項(xiàng)目基本上就是我將自己簡(jiǎn)歷上的項(xiàng)目背景以及實(shí)現(xiàn)亮點(diǎn)介紹清楚后，他們從他們的視角進(jìn)行提問，比如為什么使用 XX 技術(shù)方案？權(quán)衡的原因？如何衡量哪個(gè)方案好？怎么用數(shù)據(jù)驅(qū)動(dòng)項(xiàng)目做的更好？
最后一般就引出類似系統(tǒng)設(shè)計(jì)的問題，比如如何設(shè)計(jì)一個(gè)組件庫、設(shè)計(jì)一個(gè)狀態(tài)管理層、設(shè)計(jì)一整個(gè)應(yīng)用（比如 office online 版本）。
看到這的讀者可能也明白了，這個(gè)團(tuán)隊(duì)是偏前端的，所以沒有問太多關(guān)于后端的東西。當(dāng)然，換個(gè)團(tuán)隊(duì)面可能就不是這樣了。
英語
因?yàn)槲颐嬖嚽罢f明了自己英語不太好，所以面試全部采用中文進(jìn)行。
其他
面試完成后第二天我就收到了通過的通知，接著就是發(fā) Offer，接受背調(diào)，約定入職。薪資方面總包大概降了 30% 左右，這主要看個(gè)人取舍了。
會(huì)議
入職后我第一個(gè)想說的部分就是關(guān)于會(huì)議。前司我每周的必參加會(huì)議只有一個(gè)，那就是小組周會(huì)，時(shí)長(zhǎng)也就半小時(shí)。其他會(huì)議都是按需加載。
但在這，每周有 8-9 個(gè)小時(shí)必參加會(huì)議（5 - 6個(gè)），如果按標(biāo)準(zhǔn)工時(shí)一周 40 小時(shí)計(jì)算的話，每周 20% 以上時(shí)間都在開會(huì)。如果可選的會(huì)議多的話，每周占到 35% - 50% 也不是不可能的（比如我的 manager）。
如果僅僅是參加會(huì)議倒也還好，對(duì)我來說最有挑戰(zhàn)的是，它們幾乎是全英文的（除了我和 manager 的 1：1），而且我還必須要發(fā)言。
英語
這場(chǎng)面有點(diǎn)出乎我的意料了，我原以為只是郵件等書面材料需要用英文，沒想到除了口頭溝通（僅限中國(guó)同事）之外全部采用英語形式。
有的同事說的很快，有的口音千奇百怪。每天我到公司上班，就好像出國(guó)了一樣。
針對(duì)這種情況，除了制定學(xué)習(xí)計(jì)劃并執(zhí)行下去，好像沒什么好辦法。
對(duì)于我這種典型的 “啞巴英語” 用戶而言，
讀的優(yōu)先級(jí)最低，因?yàn)榭梢噪S時(shí)用工具翻譯（瀏覽器的劃詞插件，office 的翻譯工具等）。
寫其次，主要要考慮單詞量和語法，這個(gè)可以用機(jī)器翻譯 + ai改作文（語法、詞語替換等，如 grammarly、微軟愛寫作）解決。
而且讀寫是異步的，用工具后效率大大提高，但聽說是實(shí)時(shí)的，是工作中最可能成為阻礙的部分。
目前聽的話我每天抽出 1-2 小時(shí)來聽寫了，找自己感興趣的美劇、播客等先 0.75 倍速聽寫，然后對(duì)照字幕標(biāo)出錯(cuò)誤的地方，然后換正常倍數(shù)聽，再換到 1.25 倍。
說的話報(bào)了某 APP 上的一個(gè)班，每天通過課程練習(xí)半小時(shí)左右。每周再抽空去參加英語角和類似水平的中國(guó)同學(xué)用英語交流一個(gè)小時(shí)。
做了以上學(xué)習(xí)計(jì)劃后，每次開會(huì)輪到自己發(fā)言，還得提前打草稿，只要不遇到復(fù)雜問答的問答環(huán)節(jié)，基本可以應(yīng)付了。
目前的英語水平評(píng)測(cè)結(jié)果：
希望半年后可以全面達(dá)到 C1 level~
如果讀者有什么更好的英語學(xué)習(xí)方法，歡迎和我一起交流~
coding
由于我目前還在新人 （ramp up ）階段，所以沒有分很大的活給我。
不過小需求，在這里不一定代表著簡(jiǎn)單。
看似增刪改查傳參數(shù)的邏輯，代碼不足百行。
但其實(shí) code review 的時(shí)候就被吊打，反反復(fù)復(fù)刪改代碼幾十遍，才合入了主分支。
一部分是因?yàn)榇a不夠優(yōu)雅，沒有遵守最佳實(shí)踐（比如函數(shù)設(shè)計(jì)、變量命名、注釋、排版）。
另一部分其實(shí)是因?yàn)閷?shí)現(xiàn)方案的權(quán)衡，如果有更好的方案（性能更優(yōu)，成本更低，風(fēng)險(xiǎn)更低）就需要重構(gòu)來達(dá)到。而這部分其實(shí)需要大量 coding 之外的工作。
非 coding
可以說一個(gè)需求的上線里，coding 其實(shí)只占用了 10% 的時(shí)間。
40% 的時(shí)間用來溝通：在微軟，想一個(gè)人做成某件事是非常難的。從提交代碼時(shí)，就有技術(shù)同事幫你把關(guān)，到上測(cè)試環(huán)境和產(chǎn)品、qa 溝通，再到部署。特別是依賴別人的項(xiàng)目或者產(chǎn)品基礎(chǔ)上做事情時(shí)。
郵件溝通，郵件溝通在微軟起到了一個(gè)非常重要的環(huán)節(jié)。因?yàn)榇蠹铱赡茉诓煌臅r(shí)區(qū)工作，所以異步且正式的郵件方式成了官方推薦的溝通環(huán)節(jié)。這樣的好處就是每個(gè)人都可以按照自己的節(jié)奏安排工作。 IM 或口頭溝通，這種屬于非正式溝通，比較高效，但是基本定不下結(jié)論。而且 Teams 經(jīng)常出 bug，大家稍微正式點(diǎn)的溝通還是用郵件，和前司 IM 為主的模式不同，這里的 IM 看起來是輔助郵件而存在的。 會(huì)議溝通，這種一般是針對(duì)特定的議程得到特定的結(jié)果。有的是工程師們針對(duì)技術(shù)方案的討論，有的是工程師、pm、設(shè)計(jì)師對(duì)項(xiàng)目和產(chǎn)品的討論。還有的是跨團(tuán)隊(duì)溝通。 code review 溝通，這種就是提交代碼后全組的同事來挑你代碼的毛病了，幾十行代碼得到幾十條 comments 是常事，有時(shí)候因?yàn)榇罄械囊粋€(gè) comment 推翻重寫也是常有的事。
20% 的時(shí)間用來設(shè)計(jì)：
做的事影響的范圍。如果影響范圍較大需要拉相關(guān)的同事一起來討論。 可維護(hù)性，有的技術(shù)方案雖然可以解決問題，但是可能會(huì)對(duì)提高同事后續(xù)的維護(hù)成本。（所以要應(yīng)用各種設(shè)計(jì)模式的時(shí)候很容易被人說過度設(shè)計(jì)） 性能。包大小、應(yīng)用加載速度、服務(wù)穩(wěn)定性等都是被考量的因素。畢竟這些可以被量化。 安全，此處細(xì)節(jié)略過。 用戶隱私，此處細(xì)節(jié)略過。 可訪問性，微軟還是很重視殘障用戶的需求的，對(duì)于視障聽障或者運(yùn)動(dòng)障礙等的用戶也照顧到。 兼容 IE...
20% 的時(shí)間用來測(cè)試：
自測(cè)，自己測(cè)功能看是否達(dá)到預(yù)期 內(nèi)測(cè)，組內(nèi)同事幫忙測(cè)功能是否達(dá)到預(yù)期，以及一些邊界情況。這需要單獨(dú)組織個(gè)會(huì)議。 單測(cè)。主要集中在數(shù)據(jù)處理和 ui 組件上。 e2e 測(cè)試，還沒接觸到，但有人在維護(hù)。你提交的代碼一定要通過這些用例。
10% 的時(shí)間用來總結(jié)和分享：在會(huì)議上總結(jié)自己的工作，同步給參與的同事。如果這段經(jīng)驗(yàn)復(fù)用價(jià)值比較高的話，還需要做 PPT，舉辦一場(chǎng)分享。
一個(gè)例子
一個(gè) sdk 升級(jí)引來的慘案。
我接到一個(gè)活，是修一個(gè) bug ，但它其實(shí)是第三方庫 A 的問題，然后我引了個(gè)另一個(gè)第三方庫 B 來修它，不過這樣做會(huì)讓整體的代碼 gzip 后大概大了40 k，即使我用了懶加載。然后大佬 code review 評(píng)論別用 B 了，直接升級(jí) A，改代碼升完了，告訴 PM，又說很多地方用了 A，我要是升級(jí)的話得同步一堆人先討論這個(gè)變更是否值得，ROI 高不高。然后又是一通郵件 + 會(huì)議，現(xiàn)在還沒個(gè)定論...
wlb
整體公司大環(huán)境還是慢的，提倡 wlb，排期也不會(huì)特別緊。但是我這個(gè)組氛圍比較 push，主動(dòng)加班的人也多。
每晚八九點(diǎn)打開 Teams，一定有人在提 pr，再晚一點(diǎn)甚至周末也有同事在干活，估計(jì)我過了新人期（這邊叫 ramp up），也不會(huì)比前司輕松。
當(dāng)然，沒有加班費(fèi)。自愿的。
manager 的管理風(fēng)格屬于那種 MicroManager，需要進(jìn)行日常匯報(bào)（可能也解釋了為什么會(huì)議那么多），現(xiàn)在已經(jīng)哪天不匯報(bào)進(jìn)展和問題就心慌了，每天高（jin）效（zhang）地工作，不存在摸魚。
如果輪值成 oncall，需要 7x24 待命，那應(yīng)該是最忙的時(shí)候，不過要半年后才輪到我。只能期望那時(shí)候已經(jīng)熟悉了整個(gè)項(xiàng)目和相關(guān)的合作同事了吧。
總結(jié)
再回顧一下我最初來微軟所追求的三樣目標(biāo)：
鍛煉英語技能 ?? 但是難度超過預(yù)期了，需要額外付出精力提高
學(xué)習(xí)到專業(yè)的項(xiàng)目開發(fā)流程 ?? 倒是很享受這個(gè)痛苦而又滿足的過程
體驗(yàn) wlb 的工作節(jié)奏 ? 業(yè)余時(shí)間用來學(xué)習(xí)英語或者了解項(xiàng)目
我只想說，微軟其實(shí)并沒有想象的那么輕松。
關(guān)注我們
我們將為你帶來最前沿的前端資訊。