今天給大家分享一篇阿里面試過程記錄的文章。看完之后你會發現在 P8 的這一輪面試中，其實具體的技術問題問得并不多，都是圍繞著項目進行展開的。

這種面試的體驗和收獲會比直接干巴巴的考察技術點好的多。而且作為面試官來說，也并不想問你干巴巴的技術點，關鍵是你得有拿得出手的項目和業務知識儲備，才能在技術之外的地方和面試官進行纏斗，從而增加自己面試通過的幾率。

這次分享就是一次非常成功的在業務領域和技術領域都有來有回的面試，只是在業務領域交互的更多。

背景

這次面試流程足足橫跨三個部門，其中既有側重業務的部門，也有側重技術的部門。在省略三次面試的前提下，實際面試輪次有七次。

整個過程的心理壓力還是比較大的，畢竟每多一次面試輪次，就多一份落選的可能。尤其轉戰三個部門還都是由于公司方面的原因...

面試范圍廣。由于涉及多個部門、多個面試官，所以面試內容涉及方方面面。技術、管理、業務、個人規劃等等均有所涉及。其中技術也涉及基礎、中間件、架構，以及應用等。

這里非常感謝我的原二級主管，在我面試過程中提供的幫助。他多次幫我梳理業務、梳理思考邏輯等。

這篇文章主要分享和 P8 級別的面試官 battle 的過程。問的粒度也比較大，整體發揮也比較完整。

所以，我經過整理，直接按照面試核心模塊進行拆分，進行了總結，分享給你們。

• 應聘方式：原二級主管，內推。
• 應聘崗位：技術專家-Java-零售 Saas
• 面試時長：兩個小時左右
• 面試核心：55%業務(新零售)、35%技術、10%人生
• 面試結果：面試通過，面試官很是認可，并讓我準備后續的 P9 面。
• 面試形式：線下(因為原二級主管表示，我線下表現力強很多，結果也證明確實如此)
• 面試地點：阿里西溪園區 B 區

面試內容

1.介紹一下門店數字化作業項目(簡歷項目)

面試準備中，一定要有一個核心項目，可以用于展現自身價值的實際例子，而且一定要足夠硬。大廠 P6 及以上，一般都是需要的。

簡單來說，就是說清楚項目背景、項目價值、然后再到自身貢獻，以及最后的效果&復盤。可以參考 STAR 法則。

• 項目背景，要說清楚這個項目從何而來。比如作業這個概念是零售行業一直存在的。而之所以數字化，是因為盒馬支撐線上業務，所以數字化是必要的。而數字化作業系統，可以完成信息流轉、提高效率等等。這其中比較擅長的點，就多說兩句。甚至可以引導面試官去詢問。
• 項目價值，要從商業價值，到業務價值，最后到實現的價值指標。比如價值流中，如何拉新、增加用戶粘性。再到如何提高業務流轉效率，最后到開發成本節省等。但凡項目，必然是有價值的，否則過不了商業論證的。
• 自身貢獻，一定要體現自己在項目中的價值。即使項目再大，自己沒有參與其中也是白搭。比如負責整個項目的項目管理、整個系統的技術方案設計、核心模塊的編寫等。這個過程，可以先強調* * 工作的難點，讓面試官切實認同難點，再提出解決方案。這樣比較容易獲得面試官對自身價值的認可。比如，你和面試官說，這個系統要求 10W 的 TPS。面試官立馬就有興趣了。如果，你能提供一個切實可行的解決方案。那么面試官對你價值，就十分認同了。
• 效果&復盤，效果要體現項目完成度，而復盤則體現了自我反思提升的能力。很多人對大廠說的潛力，不太明白。而自我反思提升的能力，就是潛力的一種表現。比如我實現了一個 10WTPS 的系統，根據最后的落地效果。你認為哪里還有提升的空間，比如優化某處的技術選型，可以降低成本等。又比如，如何設計架構，可以有效支撐業務后續的快速發展。

面試中的項目不是最重要的，最重要的是通過項目，展現自身的價值。所以項目不是越大越好，而是越能體現自身價值越好。不要混淆目的和目標。

面試過程中，面試官會通過一些問題，確認項目是否是真實的。

系統的整體架構

面試項目，一定要會畫它的架構圖。現場想，容易犯錯，即便你很熟悉它。

這個部分就是上述自身貢獻的進一步深挖了。簡單來說，就是面試官想了解你設計能力。大廠社招，基本都是 p6 起步。套用大佬的話，編碼是基本要求。

那么從技術上拉開差距的第一塊兒，就是設計能力。

這里先說一些個人的粗淺認識，后續有機會，會展開的。

• 編碼 -> 核心編碼 -> 模塊設計 -> 應用設計 -> 系統設計(多應用復雜系統)
• 模塊設計 -> 應用設計 -> 系統設計，其實都是方案設計，只是處理的復雜度是不同的。

軟件工程的架構設計，本質上是為了處理，軟件工程日益增高的復雜度。從這個角度，架構設計可以分為時空兩個維度。空間上則類似于架構組成派，比如架構圖。而時間上則類似于架構演變的規劃。架構的時空維度是果，而架構決策派則是因。

這塊兒還是比較容易拉開水平差距的。最直接就是項目的復雜程度嘛。不過這個是我們自身難以決定的。所以我從個人解決問題的角度來談談。

最基本要說清楚多個關鍵點的決策理由，如這塊兒的設計重難點是什么、為什么采用策略模式、怎么實現策略模式等。

進一步要對整個方案的設計思路，有全局思考的整體觀念。比如秒殺系統的難點就是讀寫峰值高，還要保證用戶體驗。那么解決的要點是緩存、一致性等等。識別問題核心->解決思路->具體方案。

再進一步就是自身的方案要有方法論支撐。要從方法論中找到實際問題解決，再從實際問題回歸到方法論中。比如大到利用 DDD 解決業務領域劃分、識別核心領域模型等，小到二八原則落地到緩存方案中。

再往后，要么向上，考慮到業務，甚至商業模式等。比如支撐業務的快速擴張，以及商業模式的快速轉變等。要么向下，精細化每塊的設計方案，比如精準估算應用水位等。

準備面試的小伙伴，可以就上面的四條清單，提前準備啦。

主要的業務場景

面試項目中，需要清楚項目最終產品側表達，進而了解業務場景。

這里面試官一方面想要獲取對你項目的感性認知，進而發現興趣點(這個小伙子這個點，和我們團隊 xxx 相近，可以深入探討一下)。另一方面，也是看看你對業務的認識。畢竟產研的開發，都需要對業務有足夠的認識，并且有足夠的敏感度。

這個部分的回答，主要分為三塊兒：

• 如何精煉地描述業務場景。 建議可以參照 5W1H 分析法。這樣有利于在準備階段就理清業務場景。實際面試往往由于臨場發揮等問題，表現還會縮水一些。比如門店效期管理平臺是面向運營同學，用于管理商品效期限 balabala。
• 明確“主要”的由來。 能夠說清楚真正主要的業務場景。并指導為什么它是主要業務場景。比如是歸屬業務價值流的生產鏈路。比如是直接關聯資金的業務等。
• 串聯各個業務場景。 能夠將業務場景串聯起來，使之不再是一個個孤立的點。這需要小伙伴對關聯業務有足夠高的認識，有的還需要小伙伴了解公司相關戰役的始末。

這部分，作為面試項目的業務部分，需要提前準備。

如果有大佬幫忙梳理，就超贊了，比如之前的二級主管花費了不少時間幫我整理業務，真的是十分感激。

技術重構

在面試過程中，適當展現自己的主觀能動性，是有必要的。

在大廠中，大部分主管還是比較喜歡有自我驅動力的同學的，更不會拒絕那些積極主動，熱衷思考并實踐的同學。

但是，如何展現出這一點呢?尤其一些小伙伴平時就有這樣的習慣，但是卻不知道如何展現。

我之前的工作中，每一個項目，我都會有文檔。文檔中包含項目管理、技術方案、總結、關聯內容等部分。并且，作為 PM，我也有足夠的推動力。

當然，這都比不上，自主的技術重構來得直接。畢竟，實現技術重構，需要包括思考、總結、自我驅動、業務等多方面內容。

而且，技術重構也很容易展現自身技術深度，思考深度。

由于在之前的工作中，我有主動推動過作業系統重構，并規劃了決策系統的重構。

所以，我就向面試官闡述了痛點、日常思考、解決方案、團隊溝通、最終落地，以及最終的反思。

一定要有明確的重構原因(提高開發效率，降低開發成本等)，切不可為了重構而重構。

技術上的難點，以及解決方案

即使是偏向業務的開發崗位，也需要一些技術上的硬菜。

如果你的面試項目體現不出技術高段位水準，或者面試官沒有從你的表述中聽出來項目的高技術書準的體現。那么面試官大概率會有兩類問題：

自主系統設計 ：簡單點的，將面試項目中的某個需求改一改，比如并發量從 100，到 100W。難一點的，直接讓你從零考慮某個場景。比如讓你設計一個秒殺系統，或者設計一個火車訂票系統。

自問自答 ：面試官讓被面試者談談項目中遇到的難題，以及解決方案。

前者，需要大家了解架構設計，并對架構設計中的最佳實踐(如秒殺系統、會員系統、搜索系統等)比較熟悉。

后者，則需要大家的面試項目中確實有存在技術難點，并有過思考與解決。就算是虛構，也需要有能夠進行技術嫁接的地方。

我在這個部分，主要討論了異步。

先是簡單討論異步的概念，然后闡述了 Java 的 FutureTask 框架&實現原理，最后就是應用了。

這一切都絲滑度過，結果 P8 大佬覺得沒有壓榨出我的極限，就可以玩花活了。

簡單來說，就是定量分析。在給出上游各個接口的延遲、并發量、以及各個接口間的依賴關系，要求我嘗試計算當前接口的最大并發量、最小延遲等具體數值。

后續還添加了 CPU 核心數、網絡延遲、內部異常等各種條件，還各種修改前提條件。

最后由于兩個白板都寫滿了，條件都有些混淆了。

差不多二三十分鐘的狂轟濫炸，我也開始有些暈暈乎乎了。只好表示有點暈乎，記不住前提條件了，P8 大佬才收手。

末了，我問 P8 大佬，最后問題的最優解是什么?P8 大佬表示他也不知道，他就想看看我的思路。看著他樂呵樂呵的，我也不好說什么...

項目管理

大廠的技術也需要懂項目管理。而且項目管理也是接觸管理的最佳入口。

大廠中，各種需求都是按照項目的方式進行推進的，而技術側是需要有人擔任技術 PM 的。

而且擔任技術 PM 是熟悉業務非常好的方式(個人成長小訣竅)。所以技術開發需要對項目管理有一定的認識，尤其是大廠開發。

如果可以，我推薦大家學習一下 PMP，至少可以買一本 pmbok 看一看。

而在落地過程中，最重要的反而不是什么項目管理的十大知識體系，而是裁剪這個只出現在 pmbok 開篇的概念。

如果每個項目都按照完整項目管理流程走，那么花費在項目管理上的資源，將遠超過花費在項目成果上的資源。

所以這就需要 PM 根據實際情況，對項目管理流程&工具進行適當的裁剪。說白了，追求項目管理落地的 ROI。

比如，我的項目管理文檔，一般分為：

• 項目背景 ：簡單介紹業務背景，以及項目核心干系人(業務、PD、PM)等。
• 項目基線 ：主要就是范圍、資源(多指人力資源)、進度三條基線。其中大廠的進度，并不需要甘特圖，里程碑就可以了。
• 項目風險 ：主要針對可能存在的風險，以及對應解決方案。比如某個項目團隊成員是新人，可能存在工時判斷錯誤。那就需要判斷他負責的項目內容是否在項目關鍵路徑上，項目活動時間是多少，是否需要額外的幫助。比如額外資源投入。并且可以通過每日確定進度，確保其個人偏差在接受范圍內，不會擴大影響面。
• 項目驗收 ：這部分依據具體情況，可以收錄測試、產品、業務的驗收情況。并補充作為 PM，對項目上線的后續追蹤。
• 項目總結 ：對該項目過程中，遇到對問題、思考、總結都收錄在這兒。
• 附錄 ：其中參考，則是整理項目相關的所有資料，如 PRD、技術設計方案等。

面試過程中，面試官往往會提出一些實際可能遇到的問題。

比如項目資源不足、項目進度很趕、PD 頻繁修改需求等。而這就需要各位就自己對項目管理的認識，給出自己的答案。

這其中沒有標準答案。回答的過程，就是展現你對項目管理的認識。

比如項目資源不足(我的面試問題)。你可以有這些選擇：

• 通過對 PD、業務、TL 施壓，或者利用自身的影響力，嘗試獲取更多資源。這個部分可以簡單展開。比如個人影響力怎么來的(平時就有幫助別的團隊)。
• 通過與 PD、業務溝通，獲取更多的開發時長。這個就需要 PM 有較好的溝通能力了。溝通不好，打起來都可能。
• 通過關聯團隊協調，交換項目資源，獲取在該項目更有經驗的開發。這里涉及到項目組合管理。有點超綱了。但確實是解決思路。
• 通過與 PD、業務溝通，縮減項目范圍。這個對 PM 要求比較高。不過就算不成功，也可以為下一條鋪路(原因看《優勢談判》)。
• 通過與 PD、業務溝通，對項目范圍內的需求進行優先級拆分。進而將整個項目拆分為多個階段進行。這個事兒，我在效期項目上就這么做過。

如果大家真的對項目管理不太熟悉，就直接面試官直言，也算是一種解決方案。畢竟不是每個人都有這方面的積累。

團隊管理

大廠的團隊管理占管理者考核的一半。

一般來說，大廠的 P7，以及及 P7+的面試，都會問到團隊管理。如果你只是面試一個 P6，卻被問到這個問題，那么不排除面試官把你看作預備役 P7。

我目前沒有接受團隊管理的專項學習&培訓。所以存在不足，希望大家多多包涵。也歡迎大家對我的想法提出意見。

我認為，管理是整合資源(人、時間、錢等)，提高整體效率的方法論/學科。而團隊管理，則是利用團隊，通過一系列事務，達成特定組織目標。這其中會涉及團隊人員管理、目標拆解、團隊戰斗力提升等一系列模塊。

這里簡單就人員、事務、目標三者進行簡單闡述。

目標 ：無論是政府、企業、團隊，還是個人，都會有目標。這里再次重申，有別于于目的，目標是完成目的的手段。在組織結構中，目標會層層拆解下來，最終落地到執行層面。身為 TL，一定需要明確自己的目標。如果目標整錯了，即使后面做得再好，對于公司而言，這個 TL 也是失敗的。但是，目標是為了目的而服務。如果對上層的目標拆解存在疑問，則需要積極進行溝通。目標確定前積極溝通，目標確定后積極執行。

事務 ：排除團隊戰斗力，為什么團隊間的產出依舊存在較大差距，就是因為目標拆解存在問題。類比而言，就是復雜系統在進行功能域拆解時，可以有多種拆解方式。可以按照組織結構，可以按照價值流、甚至可以按照字母順序(開個玩笑)。但是合理的拆解方式自然是追求高內聚、低耦合，這樣可以使得不同功能域內部更加自治、減少與其他域不必要溝通，進而降低協同成本等。另外，目標拆解還需要考慮到團隊成員成長。比如我在安排事情的時候，并不是完全按照完成事情去進行目標拆解。而是花更多的心思，考慮到團隊每個成員的當前能力、未來成長等。這是為了團隊長遠戰斗力提升。

團隊 ：有別于項目管理，項目管理的核心是事、而團隊管理的核心是人。所謂“兵熊熊一個，將熊熊一窩”，團隊的戰斗力，很大程度上受 TL 的風格影響。團隊成員的成長、定位、忠誠都是需要 TL 去關注的。我之前帶過幾次團隊。核心理念就是真誠待人，懂得換位思考。這直接使得團隊文化就是大家比較真誠，懂得理解彼此，進而更好地進行團隊協作。優秀的團隊協作，意味著團隊的高效產出。

小結一下 ：優秀的團隊可以提高內部溝通效率，優秀的目標拆解可以降低內部溝通的總量，兩者結合就是團隊實現目標的高效。而正確的目標則可以提高團隊價值轉換率，配合前者則可以獲得團隊的高效價值產出(有別于高效產出)。

身為 TL，不要用戰術上的勤奮，去掩飾戰略上的偷懶。

身為 TL，經常由于思想與行動的差距，造成兩種情況：眼高手低與無用努力。

前者多表現為整天談各種高端概念、名詞，但是缺乏落地，多出現在公司中上層管理。

這類 TL，我“有幸”接觸過，只能說挺心累的。真的上面拍個腦袋，下面跑斷腿，末了發現無法落地。

后者多表現為整天吭哧吭哧在忙，年底感覺忙了不少東西。但一擰，發現整年都是散彈槍，沒有聚焦點，或者聚焦點不夠強。這種情況多出現在公司中下層管理。

這類 TL，我也“有幸”遇到過。年底看看自己這一年做的，如果無法凝聚為有限的幾大塊兒，那說明就是這樣的情況。

閑聊人生

閑聊是溝通者三觀的碰撞，也是對面試者個人素質(如潛力等)的重要考量。

說實話，面試聊人生一直是我最放松的環節。一方面是之前的經歷中，經常和公司 Boss、團隊一二級主管溝通，另一方面是自己平日里對自己是有不少反思&總結&規劃的。

更重要的，我可以通過這個環節，去了解&借鑒那些大佬如何溝通、總結、規劃，并得到那些大佬對我思考&規劃的建議。這都是難得的學習機會，只能說很多人沒有充分利用上。

這個環節，我基本都是臨場發揮。唯一需要注意的是說話要過腦子，明確什么話可以說，什么話不可以說，什么話要婉轉說。

簡單就面試而言，你需要表現出以下三點：

• 態度積極&樂觀 ：很多人簡歷上寫著積極、樂觀、開朗，卻沒有任何有力支撐點。你可以在閑聊中表示喜歡和朋友爬山，平日里有在健身、遇到某些人生問題保持樂觀態度等。
• 巨大能力&潛力 ：有些深層次能力，可能某些面試官沒有挖掘到，還有隱性的潛力等。這都需要你來主動展現(展現價值，才可以獲得更好認可)。比如你可以表示自己在解決某個問題時體現了解決問題能力，自己的體系化認識(專業、認知等)、自己的日常思考(業務、技術等)等
• 渴望公司&團隊 ：面試官有千萬個應聘者選擇，你也同樣有千萬個公司選擇。你需要表現出你對該公司&團隊的向往。文化的傾向，意味著你在團隊的穩定性、以及適應性等，并不是無用的。比如你可以主動咨詢目標公司&團隊的愿景、業務等，并進行溝通與認同等。

而這其中，又可以展開很多。不過因為閑聊人生環節而被拒絕的小伙伴比較少，這里就不再贅述。

P9 面

其實面試前，我已經知道了大概的面試方向和問題。是的，有一位大佬真心帶你，就是這么爽。

不過，P9 面由于 HC 問題，一直卡著。我直到最后也沒有真正接觸與這位 P9 進行溝通，挺遺憾的。

這位 P9 大佬算是這些面試中最關心業務的 P9 大佬，所以我還是談談他的面試方向和問題，供大家參考。

當時的面試會有兩個方向，一個是新零售業務(因為當時目標團隊有這個痛點)，另一個是業務穩定性。這里就談談后者。

其實聊到穩定性，大家都或多或少知道一些，比如最基本的高可用三劍客(限流、降級、熔斷)。但是如果強調技術之外呢?或者說只是技術側會不會太狹隘了?

拋開技術，業務本身也有穩定性需求，信息技術在這里只是實現手段。我們可以通過時間線來分析：

事前：核心是預防。業務&產品上的預防手段，可以是在規則發布窗口添加影響面校驗。技術上可以是高可用三劍客(涉及依賴分析，可以深入展開，體現技術造詣)。

事中：核心是監控。業務&產品上的監控手段，可以是現場數據大屏、業務指標監控等。技術上可以是各類基礎監控等。技術設計上可以有冪等&重試，以及超時。甚至可以是冗余(數據庫掛了，通過緩存提供繼續查詢能力)、N 版本程序設計等。

事后：核心是兜底。業務&產品上的兜底手段，可以是人工兜底方案、業務妥協方案等。技術上可以是資源隔離，進而降低影響面。

至于故障發生后的事后復盤，那是必須的，這里不再提及。

最后，業務優先級 = 影響面 x 發生概率