Java中筆試和麵試---P9 級面試官是如何 360° 無死角考察候選人的

給大家分享一個同學面試阿里某個部門時的經歷。

簡單說一下這個同學面試的背景，本身技術底子還不錯，在幾個有一定知名度的中型網際網路公司工作過，然後之前打算嘗試一下阿里的職位，就去面試了。

第一輪和第二輪面試，全部都通過了，面試官評價也是基本技術素養還可以，基礎也不錯，定級都是P6+的職級。

但是第三面是那個部門老大P9出來面試他，結果就掛在這裡了，所以把這個第三面的一些問題分享出來，給大家參考。

 

業務背景介紹

 

這個同學上來先闡述了一下自己的一些專案經歷，當前他在公司裡主要是負責一個資料類的系統，業務邏輯並不複雜，但是有一點技術難度。

主要是每天都會有人呼叫他的介面，然後有資料會落入資料庫表中。

簡化一下來說，大概是這個背景，如下圖：

這個系統每天介面呼叫大概會落入資料庫中有20萬左右的資料量，那麼每個月大概是600萬左右的資料量，每年大概是近億級的資料量會落入資料庫中。

但是這是針對整個資料庫來說的，平攤到裡面核心的每個表，大概每個表每年新增個千萬級別的資料量。

 

架構演進考察 

面試官：

現在系統壓力其實不大，每天20萬新增資料量也不大，每年哪怕單表新增千萬級資料其實也還算可以接受。

第一個問題：如果假設你的系統承載的業務量翻了10倍，每天新增200萬資料，你的系統架構要如何演進？

如果系統承載的業務量翻了100倍，每天新增2000萬資料，你的系統架構要如何演進？

候選人：

我們還沒這種需求，所以我暫時還沒想過這個問題。

建議：

實際上這類問題在BAT、美團、京東等大公司裡面試，都是常問的，為什麼呢？

因為大公司裡的系統面對的就是業務經常翻倍的增長，系統壓力越來越大，所以每年都要做幾次技術升級，一直要進行架構演進。

所以在網際網路公司裡，架構設計能力中非常關鍵的一環，就是針對業務增長，架構演進的能力是非常核心的。

你要有一個意識說如果你的業務量10倍增長，100倍增長，你的系統架構要如何演進？這幾乎是資深工程師必須要有的一個意識和能力。

其實大家可以思考一下，如果10倍增長，單表每年新增近億資料，還能用單庫單表的方式來承載嗎？

肯定不行了，所以必然針對10倍增長的場景，需要引入分庫分表的技術，保證每個庫每個表分散一定的資料量，避免單表單庫資料量過大。

那麼大家再思考一下，如果100倍增長呢，每年單表新增近10億資料，你分庫分表也不一定夠了。因為此時可能會有高併發訪問的問題，資料庫抗起來很吃力。

此時，你要不要考慮資料異構、冷熱分離等資料儲存的架構設計？

比如採用MySQL分庫分表 + 分散式NoSQL資料庫 + Elasticsearch分散式搜尋 + Redis快取的架構，來整體設計這個資料儲存架構。

先做冷熱分離的架構，比如最熱的資料放入分散式NoSQL資料庫，專門承載當日資料的高併發寫入，以及高效能的讀寫。

然後每過一段時間，做資料歸檔，把NoSQL裡不再頻繁使用的冷資料遷移到MySQL裡去歸檔。

最後就是應對海量資料的檢索，可以把索引構建在Elasticsearch裡來應對，但是從NoSQL+MySQL的異構儲存來提取明細資料即可。

而且針對一些特別熱查詢的資料，可以依託Redis做一個快取。

其實那個P9面試官的面試評價裡，期望的也是候選人把這一套架構說出來。雖然P6+的職級不一定說有能力完全hold住這個架構，但是起碼要有這個意識。

結果候選人完全什麼都說不出來，那當然會讓人很失望了。

 

對公司底層技術的原理考察

 

這位同學他們的系統有一部分的資料是放在特殊儲存服務裡的，用的是雲平臺上的儲存服務，而且存放在儲存服務裡的資料還是很核心的資料。

所以面試官就開始問第二個問題了。

面試官：

你能說說你對這種特殊儲存服務的理解嗎，原理是什麼？

你們用的雲平臺上的服務儲存他的架構是什麼樣的，你們的儲存是如何規劃的？

候選人：

我一般是呼叫API往裡面寫資料，詳細的還沒太多關注過。

建議：

這是該同學犯的第二個錯誤，不說資深工程師，就說作為一個高階工程師，應該對自己負責的系統使用到的方方面面都有一定的瞭解。

比如你要是用了語音轉換API，或者是快遞公司的查詢API，那你起碼知道人家背後大致在幹什麼，或者問清楚人家API的QPS極限，以及訪問量是多少。

你們用了特殊的儲存服務，起碼知道那種儲存服務的實現原理是什麼，儲存的容量規劃等等問題，這是一個高階工程師hold住自己工作的起碼工作素養。

 

系統難點的考察 

 

面試氣氛尷尬，不過仍然繼續。

面試官：

那你覺得這個系統最大的技術難點是什麼？

候選人：

我想想（思索10秒後），好像沒什麼難的，主要就是一些介面，然後資料就落入資料庫了。

建議：

大公司面試一定會問你係統的難點是什麼，這代表你的專案經驗有多少含金量。

哪怕你們專案很Low，平時也得想辦法弄點新技術進去，沒難點也要湊點兒難點出來，否則去面試必然給人鄙視。

舉個例子，比如上面的這個系統，實際上他有一個步驟是要做資料遷移，也就是說把資料庫裡可能幾百萬資料量，一次性遷移到另外一套儲存裡去

那麼這個資料遷移的步驟，其實涉及到千萬級的資料量遷移。

你如何保證資料遷移的效率？如何保證遷移後的資料準確性？在遷移的過程中如何避免影響資料庫的效能？

像這些問題，其實你平時都應該考慮一下，作為一個技術難點好好闡述一下吧。

 

擅長技術的考察 

面試官：

那你說說你認為自己最擅長最有深度的技術吧？

候選人：

我好像平時自己用MQ技術比較多一些。

面試官：

那你說說Kafka、RabbitMQ、RocketMQ幾種MQ的對比，還有他們各自的原理。

附上參考：https://blog.csdn.net/MasonCen/article/details/84990339

它們分別如何實現分散式訊息佇列架構的，底層的機制都聊一下，對比一下特點以及優缺點。

建議：

大公司一定會考察你的技術深度，一般就是對你平時用的最多，或者最熟悉的技術深入挖掘和考察，看你的技術深度有多深。

結果這個同學自己說了MQ，但是對MQ的瞭解實際上非常的淺薄，深入的東西都說不出來，那麼最後一定就是讓面試官很無語了。

 

總結 

 

其實這個同學技術底子還是不錯的，包括一些技術的基礎，所以前兩輪面試都是過了的。但是第三輪面試考察的角度都是完全不同的，一下子暴露出來了他的能力缺陷。

對自己負責系統的架構演進完全無意識，負責系統的難點從沒思考過，系統涉及的一些技術的細節不瞭解，沒有技術深度的積累，都導致他在三面表現很不好，最後就是直接掛掉。

所以希望大家通過這篇文章，吸取這位同學的經驗教訓，平時多思考自己負責系統的技術難點，以及業務量成倍增長時架構如何演進，系統涉及到的各種技術的細節，以及積累相關技術的技術深度。