我做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方面的說辭，至於其它技術，也請用類似的方式來組織。

準備些解決實際問題的說辭。

1 在測試環境裡，透過cat元件會發現，我們的訂單模組經常會發現記憶體使用量過高，而且透過一些oom時的dump檔案，會發現記憶體溢位時，Redis相關的記憶體用量過高，經過分析，發現Redis在快取資料時，沒有設定超時時間，後面再說下解決的方法。

2 在我們專案的測試環境裡，經常會看到慢SQL的監控，經過看日誌，發現是Redis並沒有快取住空或者不存在的資料，所以導致把請求全走到資料庫，然後說下如何更改快取規則。

如下再列些可能會出現問題的點：執行緒池設定不當會導致OOM，Dubbo呼叫超時時間設定過大會導致下游模組返回過慢，從而導致整條鏈路卡死，Kafka重發機制沒設定好，從而導致不冪等的現象，再不濟，可以說Java裡事務隔離級別設定過高從而導致資料庫連線打滿，或者是集合等物件用好沒關，導致OOM問題。任何一個點，都可以圍繞“透過監控發現問題”，“透過看linux日誌定位問題”和“給出解決方案解決問題”來說，同時結合專案案例說明。

5 總結，技術案例說辭+結合專案經歷說明 = 面試成功

當前網上相關分散式技術和麵試等課程很多，所以一些值錢的技術說辭，比如MySQL叢集，Redis快取，秒殺系統整合等方面的技術說辭不難準備，甚至Java小白都能說得頭頭是道，但有不少候選人偏重於技術本身的說辭，不結合專案準備，甚至不知道要結合專案準備，可以說這已經是候選人在面試中的通病。由於方法不對，這就導致有部分候選人再怎麼準備也過不了面試，甚至沒有面試機會。別的不說，本人用本文給出的面試問法，確實甄別出了不少只會說，不會做的候選人。

對此，本文在介紹“甄別方法”後給出的面試說辭，乃至說辭背後包含的“結合專案準備”的方法，可以說是面試準備中的“關鍵少數”：不需要用太多的時間和精力準備，但不準備這方面的說辭大機率不過面試。可以這樣說，這種“四兩撥千斤”的面試技術，是本文價值所在，而如果大家能在面試中“順帶”地按本文給出的套路，結合專案需求敘述技術，一定能大機率地提升大家面試成功的可能性。