这篇文章的作者为hsm_computer，擁有10年大企業工作經驗，有 IBM、花旗，平安等一線外企和互聯網工作經驗，8年 Java 面試官經驗，瞭解面試 java 初級開發高階開發和架構師的背後一面，5年線下 Java 職業培訓經驗，幫助過上千人拿到心儀的 Offer，5年架構師經驗，大量高併發分散式元件的開發經驗。著有《Java 核心技術及面試指南》。

看了這篇文章之後，發現了很多以前求職時沒有關注的問題，非常受益。無論是作為求職方，還是徵才方，都可以從這篇文章裡看到有用的而資訊，分享給大家，也希望引起大家的討論吧~以下是文章內容。

我做Java方面的面試官也有些年頭了，從校園徵才到初級開發到架構師我都面試過。從技術上來講，候選人通過面試的標準可能千差萬別，但歸結成一句話，就是候選人達到了職位介紹的要求，且相關專案經驗達到足量的年限。
同樣作為程式設計師，我自然希望所有的候選人都能成功通過面試，但作為面試官總是要忠於職責，儘量甄別出候選人的真實能力。面試時，拿到手的候選人簡歷是通過篩選的，也就是說，如果候選人真的能像簡歷上所描述的那樣，那麼一定能過面試，但事實上不少候選人僅僅是簡歷拿得出手而已。在本文裡，將站在資深面試官的角度，講述如何在面試中甄別候選人能力的若干考察要點，從中候選人朋友能進一步瞭解面試的準備方式。你們可以對照地看下本文裡給出的檢查點，看下你們當前的準備說辭能否經得起面試官的推敲。

倖存者偏差，不少簡歷無法到達面試官的手上

面試前我拿到手的簡歷，一般看上去都行，其實有不少簡歷已經被過濾掉了，我本人也做過篩選簡歷的工作，在我之前的博文裡也分析過哪些簡歷可以幫你爭取到面試機會，這裡就再囉嗦下，講下哪些面試得不到面試機會。

1. **無法證明自己在相關技術上有足量的工作或專案年限。**比如某崗位需要3年 Java 開發經驗，你簡歷上雖然給了一大堆專案描述，但無法總結性地寫明你有3年 Java 開發經驗，那估計面試機會就沒了。
2. 雖然年限夠，但簡歷上看不出本崗位需要的技術，比如本崗位需要 spring cloud 外帶 netty 和 dubbo，你簡歷上專案描述很花哨，前端有 vuejs 後端用 ssm，還有 jvm 調優經驗，但關鍵技術沒，那估計也沒面試機會。
3. 簡歷上有明顯的缺陷或矛盾點，比如最近半年沒工作，學歷不夠，或非計算機相關專業且技能描述過於簡單，或專案時間和之前工作過的公司時間對不上。

其實我個人感覺，那麼能力再一般，至少能用簡歷得到小公司的面試機會，只要你的簡歷符合如下的條件。

1. 對於有工作經驗的候選人而言，學校，專業，學歷其實重要性並不大，一些小企業或者外派崗位甚至更關注專案經驗，但你要寫清楚有足量的相關技術專案經驗（比如 java），且要進一步用公司和專案經歷證明這點。
2. 寫清楚你熟悉的職位介紹上的技術，這同樣是態度問題，你就仔細閱讀每份職位介紹，然後針對性地完善專案介紹。
3. 對於一些負面因素，一定要加上說明，比如你最近半年沒工作，或最近跳槽太頻繁，你可以給出客觀理由，不是你主觀上不穩定或能力差，是有其它客觀因素，比如換城市發展，或者深造學習。
   

甄別專案經歷的要點和發問方式

作為面試官，拿到簡歷後會通讀其中的公司經歷和專案介紹，以此來甄別真實的商業專案經驗，哪些點比較可疑呢？

• 比如要徵 Java 開發人才，如果候選人有培訓班經歷，需要確認之前的經驗是否和 Java 相關，一般情況下，候選人之前是沒做 Java，這樣候選人的相關工作經歷年限就達不到面試要求了。
• 小公司但做大專案，比如公司規模也就幾十人，但用半年做了一個電商系統，而且裡面分散式技術都用全了，那麼這種專案需要重點甄別。
• 簡歷上最近的專案描述，候選人一般比較上心，此外還要看一年前或兩年前的專案描述，看其中的技術是否有矛盾，比如有候選人兩年前用的技術和最近專案用的技術都一樣，估計是複製貼上的，這就露餡了。

上述甄別的目的是，確認相關技術或經歷的年限，檢查自編或學習的專案經歷年限，比如公司給的工資是針對3年專案經驗的，如果你用虛假經歷來頂替，那麼一方面不利於專案組，另一方面就不利於其它候選人。
這些疑點是需要在技術提問前確認好的，也就是說，如果疑點被確認屬實，就說明候選人相關技術年限不達標，就沒有繼續面試的必要了，那麼怎麼確認？
如果本專案組或其它專案組需要初級開發，而候選人簡歷上確實有疑點，一般我會明說，你xx專案看上去像學習性質的專案，你和我說實話，如果你告訴我這些專案是真實專案，那就我按高階開發的真實專案面了，如果你告訴我是學習專案，那麼我就用初級開發的標準面（或讓其它專案組的面試官面），可能初級開發的工資會少，但問題相對簡單。這樣大多數候選人會說實話，這樣兩者方便。

如果沒有初級開發崗，對於這些疑點專案，我會圍繞如下的點來發問。

• 確認專案人數，專案週期和客戶方，以及專案現在是否已經上線。對於編造或學習專案，一般專案都不會上線。
• 詢問專案打包編譯和部署的方式，一般的專案都用 maven 或 gradle 打包，或者用 ant 也算了，一般部署在 linux 上，出於可用性方面的考慮，會同時會部署在多臺機器上。如果專案真實做過，候選人多少也能說出些，但如果不是真的，那麼回答就五花八門了，我甚至聽說過部署在 windows 機器上的。
• 詢問專案的管理方式，比如用什麼工具來管理版本（比如 git 或 svn 等），程式碼 review 是怎麼做的？用什麼工具來管理 bug（比如 jira 等），用什麼工具畫 uml 圖，怎麼做單元測試？（比如 junit）開發程式碼時需要注意哪些規範。這些也是真實做過專案才能知道。
• 問你專案裡怎麼輸出日誌，你怎麼通過日誌來排查問題。一般上線後，日誌都打在 linux 上，但如果是學習專案，則只能在 windows 上看日誌了。
• 一般真實專案至少會配兩套環境，一套測試用，一套上線用，而學習專案（甚至培訓班專案）只會用一套。所以我也會對應地問，你專案是怎麼搭建這兩套環境，這兩套環境裡配置檔案是怎麼區分的？

通過上述方式我還真甄別出不少學習或虛假專案。其實我知道，上述甄別方式的作用有限，比如有候選人最近一個專案是真實的，但之前專案是自編的或學習專案，他完全可以用最近一個專案的說辭套在前一個專案裡，這就需要用如下的甄別說辭的發問方式了。寫到這裡，我不敢慶幸，更不敢幸災樂禍，只有嘆息，職責使然，不敢拿公司的信任賣人情。

值錢技術「嫁接」到真實專案上的甄別之道

半真半假的專案經歷最難甄別，這話怎麼講呢？
候選人的公司是真實的，專案也是真實的，但候選人用了這個真實的“殼”加入了虛假的技術。比如候選人在最近的專案裡明明只做了最基本的增刪改查，但結合專案背景和業務應用添加了從影片課裡掌握的分散式元件、效能調優以及 JVM 調優的說辭。甚至可以這樣說，有一部分程式設計師就在本身專案經驗不足的情況下，靠這種技巧升級到資深開發或架構師。
作為面試官，當看到候選人在簡歷上有分散式之類的值錢經驗時，就需要考核這些經驗是真的從專案裡積累的，還是隻掌握了理論經驗。如果候選人在簡歷中還有“培訓班”、“小公司”和“轉行”之類的要素，更要重點考核，如下給出具體的甄別之道。
第一問技術的使用背景，比如分散式用在高併發，分庫分表和資料庫調優用在大批量資料，就請候選人告訴我，你的業務裡，哪些點需要用到這些值錢技術。有些候選人值錢技術只是從網路教學影片上學的，沒專案實踐經驗，這個一問就能問出來。
第二問技術的最基本的用法，比如 Redis 快取，就問如何以 Hash 表方式讀取資料，對於 Dubbo，怎麼設定超時時間，Kafka 裡怎麼設定訊息重發，這些問題不求難，只要是用過就一定能知道，但不少候選人如果連這個都說不上，後面我就不會再問了。
如果能回答好第二層問題，那麼至少說明候選人用過，接下來會是第三層的問題，問專案裡解決過哪些實際問題，再具體些，用到分散式等技術總是要解決高併發等問題，我就問「你專案的併發量是多少？為了應對這個併發量，你專案裡用到哪些元件，這些元件是如何構成叢集，如何部署在 linux 上的？」
以 Redis 舉例，根據上述三層提問的方式，我一般會問如下的問題。

• 你專案業務的併發量是多少？結合一個業務場景，告訴我，你們專案用到了哪些 Redis 資料結構？
• 你們專案裡，Redis 物件的快取時間一般設多少？（一般專案都會設，否則物件會堆積在記憶體裡，從而導致 OOM）
• 你們 Redis 叢集一般是怎麼搭建的？（專案裡，出於重用性考慮，一般都用叢集，不會用單機版）
• Redis 持久化怎麼做？訊息通訊機制怎麼做？如何壓測？這些場景在專案裡大概率能用到。
  上述 2 到 4 點是問技術的用法，一般如果在專案裡用過，多少會用到其中幾個點，如果都說不上，那麼可以說只會理論不會技術。
• 結合專案裡遇到過的一個問題，你說下如何在專案裡排查 Redis 方面的問題？具體來說，如何發現問題的？（無非是通過監控，通過日誌，或者是使用者投訴）如何分析問題的？（一般是看日誌），然後如何定位和解決問題的？
  對於其它元件，比如 dubbo,mycat,netty,kafka 等，也是採用類似的問法，第一問如何在專案裡用，第二問細節，第三問如何排查解決問題。請注意在這階段我不問底層程式碼，因為當前還是處於確認候選人技術的階段，如果候選人過不了這關，只能說具備理論經驗，這樣通過看影片看資料準備的值錢技能基本就白費了。只有當能自證有專案經驗，才有資格通過底層程式碼調優技能等細節來錦上添花。
  

候選人說出哪些點，才能證明值錢技術有專案經驗

教你準備值錢技術的方法

根據我的體會，如果真的達到資深開發或者架構師級別，面試時大多能靠實力過關，只要結合做過的專案和排查過的問題，稍微準備些技術細節即可，因為他們在面試中能展示自己的亮點太多了。而對於一些只會增刪改查的初級開發，或者沒分散式元件實踐機會的程式設計師，由於缺乏專案經驗以及亮點說辭，這些人在挑戰高一級的崗位以及大公司時，難度很大，有不少人就因此長時間停留在低階崗位或小公司，直到30歲和35歲來臨。
所謂難者不會，會者不難，在這部分裡，將給出一些通用性的技術整合專案經驗的說辭，大家如何據此準備面試，大概率能讓面試官認為，你有實踐經驗，畢竟面試頂多了才1小時。
技術結合專案需求的說辭，講清楚xx技術用到xx場景裡。

1. 在這個專案的xx模組裡，我用到了 Redis（或其它分散式元件），原因是這個模組的併發量達到了xx，單純把請求壓到資料庫不行，所以得用 Redis 快取，或者給出其它必須用分散式的原因。
2. 在這個專案的訂單處理模組裡，由於某些流水錶資料量太大，所以用到 Mycat 分庫分表，具體的做法是，把百萬級別的xx表拆分成 10 個表，按xx欄位的最後一位，把資料插入到不同的分表裡。

準備些技術的細節，並結合專案需求說出來，如下給出 netty 方面的說辭，至於其它技術，也請用類似的方式來組織。
在我們的線下商城專案裡的收單和優惠券模組間，需要用 netty 轉發收單模組的訊息，在使用過程中，我們用到了 protobuf 作為 netty 的序列化協議，並在 encode 和 decode 方法裡定義了序列化方面的程式碼，而且採用了 netty 整合執行緒池的做法。
準備些解決實際問題的說辭。
在測試環境裡，通過 cat 元件會發現，我們的訂單模組經常會發現記憶體使用量過高，而且通過一些 oom 時的 dump 檔案，會發現記憶體溢位時，Redis 相關的記憶體用量過高，經過分析，發現 Redis 在快取資料時，沒有設定超時時間，後面再說下解決的方法。
在我們專案的測試環境裡，經常會看到慢 SQL 的監控，經過看日誌，發現是 Redis 並沒有快取住空或者不存在的資料，所以導致把請求全走到資料庫，然後說下如何更改快取規則。
如下再列些可能會出現問題的點：執行緒池設定不當會導致 OOM，Dubbo 呼叫超時時間設定過大會導致下游模組返回過慢，從而導致整條鏈路卡死，Kafka 重發機制沒設定好，從而導致不冪等的現象，再不濟，可以說 Java 裡事務隔離級別設定過高從而導致資料庫連線打滿，或者是集合等物件用好沒關，導致 OOM 問題。任何一個點，都可以圍繞“通過監控發現問題”，“通過看 linux 日誌定位問題”和“給出解決方案解決問題”來說，同時結合專案案例說明。

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

當前網上相關分散式技術和麵試等課程很多，所以一些值錢的技術說辭，比如 MySQL 叢集，Redis 快取，秒殺系統整合等方面的技術說辭不難準備，甚至 Java 小白都能說得頭頭是道，但有不少候選人偏重於技術本身的說辭，不結合專案準備，甚至不知道要結合專案準備，可以說這已經是候選人在面試中的通病。由於方法不對，這就導致有部分候選人再怎麼準備也過不了面試，甚至沒有面試機會。別的不說，本人用本文給出的面試問法，確實甄別出了不少只會說，不會做的候選人。
對此，本文在介紹“甄別方法”後給出的面試說辭，乃至說辭背後包含的“結合專案準備”的方法，可以說是面試準備中的“關鍵少數”：不需要用太多的時間和精力準備，但不準備這方面的說辭大概率不過面試。可以這樣說，這種“四兩撥千斤”的面試技術，是本文價值所在，而如果大家能在面試中“順帶”地按本文給出的套路，結合專案需求敘述技術，一定能大概率地提升大家面試成功的可能性。

原文 | 面试官透露：候选人该这样展示值钱技能！
本文经 程序人生（微信公眾號ID: coder_life）授权转载，转载请联繫出处原文刊載於。