Java面試官經驗談：如何甄別候選人真實的能力，候選人如何展示值錢技能
我做Java方面的面試官也有些年頭了，從校招學生到初級開發到架構師我都面試過。從技術上來講，候選人通過面試的標準可能千差萬別，但歸結成一句話，就是候選人達到了職位介紹的要求，且相關項目經驗達到足量的年限。
同樣作為程式設計師，我自然希望所有的候選人都能成功通過面試，但作為面試官總是要忠於職責，盡量甄別出候選人的真實能力。面試時，拿到手的候選人簡歷是通過篩選的，也就是說，如果候選人真的能像簡歷上所描述的那樣，那麼一定能過面試，但事實上不少候選人僅僅是「簡歷拿得出手」而已。在本文里，將站在資深面試官的角度，講述如何在面試中甄別候選人能力的若干考察要點，從中廣大候選人朋友能進一步了解面試的準備方式。特別地，對於一些看了若干課程的同學，你們可以對照地看下本文里給出的檢查點，看下你們當前的準備說辭能否經得起面試官的推敲。
1 倖存者偏差，其實有不少簡歷甚至無法到達面試官的手上
面試前我拿到手的簡歷，一般看上去都行，其實有不少簡歷已經被過濾掉了，我本人也做過篩選簡歷的工作，在我之前的博文里也分析過哪些簡歷可以幫你爭取到面試機會，這裡就再啰嗦下，講下哪些面試得不到面試機會。
1 無法證明自己在相關技術上有足量的工作或項目年限。比如某崗位需要3年Java開發經驗，你簡歷上雖然給了一大堆項目描述，但無法總結性地寫明你有3年Java開發經驗，那估計面試機會。
2 雖然年限夠，但簡歷上看不出本崗位需要的技術，比如本崗位需要spring cloud外帶netty和dubbo，你簡歷上項目描述很花哨，前端有vuejs後端用ssm，還有jvm調優經驗，但關鍵技術沒，那估計也沒面試機會。
3 簡歷上有明顯的缺陷或矛盾點，比如最近半年沒工作，學歷不夠，或非電腦相關專業且技能描述過於簡單，或項目時間和之前工作過的公司時間對不上。
其實我個人感覺，那麼能力再一般，至少能用簡歷得到小公司的面試機會，只要你的簡歷符合如下的條件。
1 對於社招而言，學校，專業，學歷其實重要性並大，一些小廠或者外派崗位甚至更關注項目經驗，但你要寫清楚有足量的相關技術項目經驗（比如java），且要進一步用公司和項目經歷證明這點。
2 寫清楚你熟悉職位介紹上的技術，這同樣是態度問題，你就仔細閱讀每份職位介紹，然後針對性地完善項目介紹。
3 對於一些負面因素，一定要加上說明，比如你最近半年沒工作，或最近跳槽太頻繁，你可以給出客觀理由，不是你主觀上不穩定或能力差，是有其它客觀因素，比如換城市發展，或者考研。
2 甄別項目經歷的要點和發問方式
作為面試官，拿到簡歷後會通讀其中的公司經歷和項目介紹，以此來甄別真實的商業項目經驗，哪些點比較可疑呢？
1 比如要招個Java開發，如果候選人有培訓班經歷，需要確認之前的經驗是否和Java相關，一般情況下，候選人之前是沒做Java，這樣候選人的相關工作經歷年限就達不到面試要求了。
2 小公司但做大項目，比如公司規模也就幾十號人，但用半年做了一個電商系統，而且裡面分散式技術都用全了，那麼這種項目需要重點甄別。
3 簡歷上最近的項目描述，候選人一般比較上心，此外還要看一年前或兩年前的項目描述，看其中的技術是否有矛盾，比如有候選人兩年前用的技術和最近項目用的技術都一樣，估計是複製粘貼的，這就露餡了。
上述甄別的目的是，確認相關技術或經歷的年限，排查自編或學習的項目經歷年限，比如公司給的工資是針對3年項目經驗的，如果你用虛假經歷來頂替，那麼一方面不利於項目組，另一方面就不利於其它候選人。
這些疑點是需要在技術提問前確認好的，也就是說，如果疑點被確認屬實，就說明候選人相關技術年限不達標，就沒有繼續面試的必要了，那麼怎麼確認？
如果本項目組或其它項目組需要初級開發，而候選人簡歷上確實有疑點，一般我會明說，你xx項目看上去像學習項目，你和我說實話，如果你告訴我這些項目是真實項目，那就我按高級開發的真實項目面了，如果你告訴我是學習項目，那麼我就用初級開發的標準面（或讓其它項目組的面試官面），可能初級開發的工資會少，但問題相對簡單。這樣大多數候選人會說實話，這樣兩廂方便。
如果沒有初級開發崗，對於這些疑點項目，我會圍繞如下的點來發問。
1 確認項目人數，項目周期和客戶方，以及項目現在是否已經上線。對於編造或學習項目，一般項目都不會上線。
2 詢問項目打包編譯和部署的方式，一般的項目都用maven或gradle打包，或者用ant也算了，一般部署在linux上，出於可用性方面的考慮，會同時會部署在多台機器上。如果項目真實做過，候選人多少也能說出些，但如果是學習項目，那麼回答就五花八門了，我甚至聽說過部署在windows機器上的。
3 詢問項目的管理方式，比如用什麼工具來管理版本（比如git或svn等），程式碼review是怎麼做的？用什麼工具來管理bug（比如jira等），用什麼工具畫uml圖，怎麼做單元測試？（比如junit）開發程式碼時需要注意哪些規範。這些也是真實做過項目才能知道。
4 問你項目里怎麼輸出日誌，你怎麼通過日誌來排查問題。一般上線後，日誌都打在linux上，但如果是學習項目，則只能在windows上看日誌了。
5 一般真實項目至少會配兩套環境，一套測試用，一套上線用，而學習項目（甚至培訓班項目）只會用一套。所以我也會對應地問，你項目是怎麼搭建這兩套環境，這兩套環境里配置文件是怎麼區分的？
通過上述方式我還真甄別出不少學習或虛假項目。其實我知道，上述甄別方式的作用有限，比如有候選人最近一個項目是真實的，但之前項目是自編的或學習項目，他完全可以用最近一個項目的說辭套在前一個項目里，這就需要用如下的甄別說辭的發問方式了。寫到這裡，我不敢慶幸，更不敢幸災樂禍，只有嘆息，職責使然，不敢拿公司的信任做人情。
3 值錢技術「嫁接」到真實項目上的甄別之道
其實在我之前的博文聊聊我當年在培訓學校做開發的經歷里已經提到，「半真半假」的項目經歷最難甄別，這話怎麼講呢？
候選人的公司是真實的，項目也是真實的，但候選人用了這個真實的「殼」加入了虛假的技術。比如候選人在最近的項目里明明只做了最基本的增刪改查，但結合項目背景和業務應用添加了從影片課里掌握的分散式組件、性能調優以及JVM調優的說辭。甚至可以這樣說，有一部分程式設計師就在本身項目經驗不足的情況下，靠這種技巧升級到資深開發或架構師。
作為面試官，當看到候選人在簡歷上有分散式之類的值錢經驗時，就需要考核這些經驗是真的從項目里積累的，還是只掌握了理論經驗。如果候選人在簡歷中還有有「培訓班」、「小公司」和「轉行」之類的要素，更要重點考核，如下給出具體的甄別之道。
第一問技術的使用背景，比如分散式用在高並發，分庫分表和資料庫調優用在大批量數據，就請候選人告訴我，你的業務里，哪些點需要用到這些值錢技術。有些候選人值錢技術只是從網路教學影片上學的，沒項目實踐經驗，這個一問就能問出來。
第二問技術的最基本的用法，比如Redis快取，就問如何以Hash表方式讀取數據，對於Dubbo，怎麼設置超時時間，Kafka里怎麼設置消息重發，這些問題不求難，只要是用過就一定能知道，但不少候選人如果連這個都說不上，後面我就不會再問了。
如果能回答好第二層問題，那麼至少說明候選人用過，接下來會是第三層的問題，問項目里解決過哪些實際問題，再具體些，用到分散式等技術總是要解決高並發等問題，我就問，你項目的並發量是多少？為了應對這個並發量，你項目里用到哪些組件，這些組件是如何構成集群，如何部署在linux上的？
以Redis舉例，根據上述三層提問的方式，我一般會問如下的問題。
1 你項目業務的並發量是多少？結合一個業務場景，告訴我，你們項目用到了哪些Redis數據結構？這是問技術的使用畢竟
2 你們項目里，Redis對象的快取時間一般設多少？（一般項目都會設，否則對象會堆積在記憶體里，從而導致OOM）
3 你們Redis集群一般是怎麼搭建的？（項目里，出於重用性考慮，一般都用集群，不會用單機版）
4 Redis持久化怎麼做？消息通訊機制怎麼做？如何壓測？這些場景在項目里大概率能用到。
上述2到4點是問技術的用法，一般如果在項目里用過，多少會用到其中幾個點，如果都說不上，那麼可以說只會理論不會技術。
5 結合項目里遇到過的一個問題，你說下如何在項目里排查Redis方面的問題？具體來說，如何發現問題的？（無非是通過監控，通過日誌，或者是用戶投訴）如何分析問題的？（一般是看日誌），然後如何定位和解決問題的。
對於其它組件，比如dubbo,mycat,netty,kafka等，也是採用類似的問法，第一問如何在項目里用，第二問細節，第三問如何排查解決問題。請注意在這階段我不問底層程式碼，因為當前還是處於確認候選人技術的階段，如果候選人過不了這關，只能說具備理論經驗，這樣通過看影片看資料準備的值錢技能基本就白費了。只有當能自證有項目經驗，才有資格通過底層程式碼調優技能等細節來錦上添花。
4 候選人說出哪些點，才能證明值錢技術有項目經驗（教你準備值錢技術的方法）
根據我的體會，如果真的達到資深開發或者架構師級別，面試時大多能靠實力過關，只要結合做過的項目和排查過的問題，稍微準備些技術細節即可，因為他們在面試中能展示自己的亮點太多了。而對於一些只會增刪改查的初級開發，或者沒分散式組件實踐機會的程式設計師， 由於缺乏項目經驗以及亮點說辭，這些人在挑戰高一級的崗位以及大公司時，難度很大，有不少人就因此長時間停留在低級崗位或小公司，直到30歲和35歲來臨。
所謂難者不會，會者不難，在這部分里，將給出一些通用性的技術整合項目經驗的說辭，大家如何據此準備面試，大概率能讓面試官認為，你有實踐經驗，畢竟面試頂多了才1小時。
技術結合項目需求的說辭，講清楚xx技術用到xx場景里。
1 在這個項目的xx模組里，我用到了Redis（或其它分散式組件），原因是這個模組的並發量達到了xx，單純把請求壓到資料庫不行，所以得用Redis快取，或者給出其它必須用分散式的原因。
2 在這個項目的訂單處理模組里，由於某些流水表數據量太大，所以用到Mycat分庫分表，具體的做法是，把百萬級別的xx表拆分成10個表，按xx欄位的最後一位，把數據插入到不同的分表裡。
準備些技術的細節，並結合項目需求說出來，如下給出netty方面的說辭，至於其它技術，也請用類似的方式來組織。
在我們的線下商城項目里的收單和優惠券模組間，需要用netty轉發收單模組的消息，在使用過程中，我們用到了protobuf作為netty的序列化協議，並在encode和decode方法里定義了序列化方面的程式碼，而且採用了netty整合執行緒池的做法。
準備些解決實際問題的說辭。
1 在測試環境里，通過cat組件會發現，我們的訂單模組經常會發現記憶體使用量過高，而且通過一些oom時的dump文件，會發現記憶體溢出時，Redis相關的記憶體用量過高，經過分析，發現Redis在快取數據時，沒有設置超時時間，後面再說下解決的方法。
2 在我們項目的測試環境里，經常會看到慢SQL的監控，經過看日誌，發現是Redis並沒有快取住空或者不存在的數據，所以導致把請求全走到資料庫，然後說下如何更改快取規則。
如下再列些可能會出現問題的點：執行緒池設置不當會導致OOM，Dubbo調用超時時間設置過大會導致下游模組返回過慢，從而導致整條鏈路卡死，Kafka重發機制沒設置好，從而導致不冪等的現象，再不濟，可以說Java里事務隔離級別設置過高從而導致資料庫連接打滿，或者是集合等對象用好沒關，導致OOM問題。任何一個點，都可以圍繞「通過監控發現問題」，「通過看linux日誌定位問題」和「給出解決方案解決問題」來說，同時結合項目案例說明。
5 總結，技術案例說辭+結合項目經歷說明 = 面試成功
當前網上相關分散式技術和面試等課程很多，所以一些值錢的技術說辭，比如MySQL集群，Redis快取，秒殺系統整合等方面的技術說辭不難準備，甚至Java小白都能說得頭頭是道，但有不少候選人偏重於技術本身的說辭，不結合項目準備，甚至不知道要結合項目準備，可以說這已經是候選人在面試中的通病。由於方法不對，這就導致有部分候選人再怎麼準備也過不了面試，甚至沒有面試機會。別的不說，本人用本文給出的面試問法，確實甄別出了不少只會說，不會做的候選人。
對此，本文在介紹「甄別方法」後給出的面試說辭，乃至說辭背後包含的「結合項目準備」的方法，可以說是面試準備中的「關鍵少數」：不需要用太多的時間和精力準備，但不準備這方面的說辭大概率不過面試。可以這樣說，這種「四兩撥千斤」的面試技術，是本文價值所在，而如果大家能在面試中「順帶」地按本文給出的套路，結合項目需求敘述技術，一定能大概率地提升大家面試成功的可能性。
請大家關注我的公眾號：一起進步，一起掙錢，在本公眾號里，會有很多精彩文章。
