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小白都能說得頭頭是道，但有很多候選人偏重於技術自己的說辭，不結合項目準備，甚至不知道要結合項目準備，能夠說這已是候選人在面試中的通病。因爲方法不對，這就致使有部分候選人再怎麼準備也過不了面試，甚至沒有面試機會。別的不說，本人用本文給出的面試問法，確實甄別出了很多隻會說，不會作的候選人。

    對此，本文在介紹「甄別方法」後給出的面試說辭，乃至說辭背後包含的「結合項目準備」的方法，能夠說是面試準備中的「關鍵少數」：不須要用太多的時間和精力準備，但不許備這方面的說辭大機率不過面試。能夠這樣說，這種「四兩撥千斤」的面試技術，是本文價值所在，而若是你們能在面試中「順帶」地按本文給出的套路，結合項目需求敘述技術，必定能大機率地提高你們面試成功的可能性。

 

    請你們關注個人公衆號：一塊兒進步，一塊兒掙錢，在本公衆號裏，會有不少精彩文章。