看BAT技術面試官如何挑選Java程式設計師

又到一年一度的跳槽求職高峰季，很多人問我，你們公司還需要人麼，你們用的技術棧是哪些，有哪些是你們比較關注技術重點？

沒錯，作為負責技術面試的我，面對數十甚至上百封簡歷，肯定要做一輪篩選。究竟哪些技術點或方向在我篩選或面試時，留下深刻印象呢？

我覺得優秀的，有潛質的程式設計師可以從下面幾點體現。

幾乎每個JAVA後端開發程式設計師，都會在面試時碰到諸如如何效能調優的問題，如何回答好這個問題，不僅僅是對JVM，記憶體模型等的理解，更重要的是碰到效能問題時，排查問題的方法論和思路。

典型的一個場景是：在壓力測試時，發現FullGC頻率很高，如何解決？

此類問題一般從以下幾點入手：

1. 觀察GC日誌，判斷是否有記憶體洩漏，或者存在的內部不合理點。此處要求能熟悉各種linux命令，可以快速檢視和定位。

2. 調整JVM 引數，如新生代，年老代大小，S0和S1大小比例，不同垃圾回收器的採用。並結合業務特點做進一步分析。這裡不但要求紮實的JVM記憶體模型和理論，還要求對JVM的各種引數設定耳熟能詳，並能實踐操作。

3. Dump記憶體，做進一步的物件分析。

4. 壓測指令碼的編寫，效能問題解決前可以發現問題，並能在問題解決後真實的驗證。

此類優化不僅僅是照本宣科式的回答，面試官一定會喜歡問實際中操作的場景，和解決問題的思路。因為效能問題的原因是多種多樣的，但是解決問題的思路和方法論是可以明確的。

網易十幾年的網際網路開發和幾乎囊括了網際網路的各個產品和業務場景，在效能優化和調優這塊積累了豐富和獨到的實踐經驗，很有代表和可參考性。

大家一定都聽過或使用過網路非同步框架Netty，甚至使用netty框架開發過一些應用和功能。

但是大部分人僅限於對Netty的使用，甚至僅僅知道其他一些開源框架使用了Netty，但是在資深面試官眼裡，Netty有很多值得學習和借鑑的地方，使用過Netty並且能對Netty的一些原理有一定的瞭解且能學以致用的Java程式設計師格外受歡迎。

一般來說，要求較高的面試官和技術經理喜歡從Netty的設計模式角度深入的考察技術人員對網路開發和相關理論的理解如：

1. Netty的Reactor模型如何設計，反應在應用裡的模型是如何（見下圖）。

2. Netty的pipeline 責任鏈如何使用，業務場景中是否有類似的實踐經驗。

3. 專案中有無使用Netty，並利用Netty進行私有化協議設計。

同學們不僅要求能使用Netty，通過閱讀其原始碼，理解其中的精髓，並能應用在自己的實踐專案中，這個才是亮點和加分項。

網際網路經過十幾年的發展，早已經從單體應用發展為服務化應用，大廠裡系統和服務尤其如此。

拿經典的dubbo 服務化框架舉例，當前市面上有很多dubbo相關的文章和介紹，這裡撇開不談，從技術負責人的角度來，我會更關心下面有關幾個dubbo相關的問題。

1. 技術選型：為什麼選擇dubbo，而不選擇其他如spring cloud框架?

我認為可以從如下考慮：

技術選型話題雖然寬泛，但是最能體現體現技術人員的綜合能力，尤其結合業務特點後對技術框架深度和廣度的駕馭能力。

2. Dubbo底層走的是什麼協議，如何處理非同步轉同步？

大部分的Java開發都會直接使用dubbo，而不會去關心其底層一些技術細節，但是一些細節，如dubbo如何對物件進行序列化，用了哪些序列化方式，這些在分散式專案中對提高應用的處理速度，減少網路開銷，都很大幫助。

同時RPC框架裡如何將非同步轉同步，也是需要技術人員非常關注的一面，裡面相關的設計模式，多執行緒程高併發場景都是很多業務系統裡真實需要和借鑑的。

3. Dubbo在高併發高可用等實踐場景需要認真考慮的其他問題

使用了dubbo後，很多人覺得萬事大吉，其實並不是這樣，下面幾點還需要關心，並且這些就是體現你價值的地方

同學們可以自行思考，答案不是唯一，網易有很多類似的專案，設計的很好，非常值得思考和借鑑。