面試時我不在意候選人的經驗來自培訓班，但會關注商業項目經驗和幹活能力：再說面試時鑑別商業項目的方式

時間 2019-11-20

標籤面試在意候選人經驗來自培訓班關注商業項目幹活能力再說鑑別方式欄目快樂工作简体版

原文原文鏈接

我在博客園裏乃至其它地方看到有很多對培訓班出身的程序員的評價，其實至少在我面試時，培訓班出來的程序員沒有原罪。html

我也面試很多程序員，從高級開發到初級開發都有，有985和211名校出身的，也有大專學習經過培訓班積累IT經驗的。我見過有候選人正大光明地把培訓經歷寫在簡歷上，也見過候選人想方設法地想把培訓經驗掩飾成項目經驗。對我來講（相信其它大多數技術面試官都同樣），我只須要考量候選人的以往商業項目經驗和實際技能，看下是否匹配本崗位。java

至於候選人的技能來來自哪裏？說句笑話，若是候選人面試時不露破綻，把培訓項目說成商業項目，我真沒法鑑別。在本文裏，我第一將從面試角度，糾正當前對培訓班的一些觀點，第二從培訓班的角度，來分享下我如何在面試時甄別商業項目的方法。nginx

在開篇前，我引用兩段俗語，第一，外行看熱鬧，內行看門道。第二，一力降十會。至於爲何要引用？本人絕非空穴來風，請你們自行體會。程序員

1 培訓項目若是被看穿，是會被扣去這段時間的項目經驗面試

目前大多數培訓學校都會把學習項目包裝成商業項目，由於他們也知道商業項目的含金量更高。若是我在面試時判斷出候選人的項目是從培訓班裏獲得的，我會給出以下的判斷。 spring

第一，候選人掌握對相應的技術，好比Spring MVC，也能經過學習項目加深了對此的瞭解，這是不用質疑的。數據庫

第二，這段時間的項目經驗，不能算是商業項目經驗，這對候選人來講是至關不利的。編程

由於很多職位是有硬性的項目年限標準，好比2年，並且最近半年最好是在用相關的技術。若是候選人被發現最近半年的項目是從培訓學校裏學到的，可能有些公司會不在意，但至少我會被要求詳細寫下這一狀況，若是該候選人沒有其它補償優點（通常都不會有），那麼面試就結束了。並且，很多從培訓班裏出來的候選人，有實戰性的項目經驗或許只限於此，那麼再被扣除後，就真的沒有商業項目經驗了。後端

以下是我對培訓班出身的程序員給出的比較客觀的見解，若是你從培訓班裏出來後，也有多年的開發經驗了，這些商業項目經驗達到了職位的客觀標準，那麼一切都好說，至少我瞭解到的面試官不會所以卡候選人，但若是沒實際項目經驗，好比從培訓班出來後第一份工做，那麼若是被卡，絕非是你的培訓班出身，而是缺少商業項目經驗。服務器

2 簡歷中哪些項目看上去像學習項目

第一類，我最近在面試中，發現有很多簡歷上描述的項目很是高大全，好比項目裏用到了Spring Cloud裏的全部組件，什麼Eureka,Ribbon，Zuul等都用了一遍，或者在項目裏，大數據分析的，分佈式組件相關的技術也都用了一遍。而候選人的工做年限就3年。

或者，有候選人會在一個項目裏，把分佈式組件全都用一遍，好比Dubbo, nginx，kafka等，但從項目的需求上來看，無需用那麼多的組件。

第二類，好比xx電商系統，xx財務軟件，xx教學管理軟件，xx圖書館管理軟件。汗顏，其實我當年也這樣寫過。固然，我也列不全，但你們都作過畢業設計項目，凡是看上去像畢業設計的項目，通常真就有多是學習項目。

並且我每每會見到這樣的狀況：在一個時間段裏，從獵頭等途徑獲得一批項目經驗很類似的簡歷，好比都電商項目，需求和描述以及技術用得基本類似，但公司名不一樣，這種狀況每每你們心知肚明。

第三類，候選人在項目裏，幹了很是多的模塊。咱們知道，哪怕是資深開發，在項目裏，能把一兩個模塊作精就夠能夠了，但我就見過很多候選人，在項目裏，用了短短兩三個月，就作了不少模塊，這樣的工做效率和開發狀況很是不符，這通常也會被列入懷疑對象。

遇到這類項目，我不會武斷地當即給出定論，而是會經過下面的盤問方式，來把候選人繞暈，以此來甄別是哪類項目。

4 遇到疑似學習項目，我一般的質疑方式

其實候選人應該比面試官更熟悉項目以及其中用到的技術，因此若是真的是商業項目經驗，應該對各方面能自圓其說，至少不能相互矛盾。

因此遇到疑似學習項目，我通常會有以下的詢問方式。

方式1:，詢問技術是否和項目背景匹配。好比某簡歷中提到用Kafka，我就會問。

第一，你是否瞭解kafka的細節？若是瞭解，先問些基本問題，以此來確認是否用過。

第二，kafka用在項目裏哪一個模塊裏，具體是實現哪一個業務？通常來講，哪怕是學習項目，這也能說清楚。

第三，關鍵點在這裏，詢問使用kafka的必要性。我會問，xx需求點，確實是實現了消息通信的功能，但實際通信量並不高，用通常的Dubbo調用足以應對，那爲何還要大費周章地用kafka?甚至還要用kafka集羣？或者我乾脆提問，kafka是消息中間件，但xx需求裏並無發消息通信的需求，爲何要用？

經過這種提問，通常簡歷中是學習項目，候選人可能會了解kafka技術細節，但因爲沒在項目裏配過，因此很難講清楚爲何要用這個技術，這樣就露餡了。

方式2，通常候選人把學習項目放入簡歷，每每比較難搞清楚一些技術細節，或者沒真實配置過，因此我會問些配置部署方面的問題。

好比某簡歷中有dubbo，我就會問，項目裏是如何配置dubbo，具體來講，你爲了讓遠端能調到dubbo，通常會在哪些配置文件裏作什麼配置？或者，你提供的dubbo服務，若是設置超時等待時間和重試次數。

根據面試結果，通常在學習項目裏，能實現功能便可，候選人通常不會注意這些配置方面的細節，而這些加偏偏是商業項目裏必定會用到的，因此經過這個問，每每一抓一個準。

方式3，詢問項目的商業價值。好比，我見過很多候選人作過xx物流系統，xx電商系統，xx人事管理系統。

遇到這類系統，我就會問：目前市面上這類大型網站夠多了，這些系統若是作成上線後，如何同現有的競爭？候選人每每說不知道。我會進一步問，這個系統有沒有上線？網址是什麼？客戶是誰？開發週期有多少？凡是涉及到這類項目細節了，候選人每每就會漏洞百出，好比業務10我的月便可完成的，會被說成20個，或者乾脆推說不知道。

遇到這種狀況，並且候選人其它問題再回答很差，那麼我真能確信是學習項目了。

方式4：就問一些矛盾的技術細節。好比候選人列出某項目裏用到一些分佈式技術，好比同時用到nginx和spring cloud裏的zuul以及Ribbon。咱們知道，在項目裏，nginx和ribbon都能實現負載均衡，但每每就用一套，但真有候選人會寫兩個都用。相似的，候選人在寫項目時，因爲每每是東拼西湊的，因此未必對技術瞭解很透徹，因此出現矛盾的地方會不少。

因此我每每就說：在你項目裏，xx和xx技術並存了，它們是實現同一套功能，大家爲何會用兩套？每每候選人就沒法自圓其說了。

5 準備商業項目的要點（尤爲經歷過培訓班）

其實我自認爲在上部分的質疑並不苛刻，或者是對簡歷中項目描述裏的矛盾點提出疑問，或者就問些只要作了項目就必定能瞭解的很是基本的點，但就這些比較簡單的質疑，真的排查出絕大多數的學習項目。

你們看了之後必定會很是慌，別怕，這裏我會列出商業項目的準備要點。有人看了就會問了，若是根據這裏的準備方式準備後來找我面試，能不能過？我必定回答是，不能過，由於我面試的技巧是，運用之妙，存乎一心，是沒法用文字形容的。而我給出的準備要點因爲是落了文字，因此終屬下乘。

那麼看了個人技巧有什麼幫助？第一遇到不那麼專業的面試官，或者項目緊眼開眼閉的面試官，就能過，第二，我介紹面試技巧的博文多少也能給出些實用技巧。因此必定能幫助你們提高面試成功率。好了，言歸正傳，下面列些準備商業項目的要點。

1 尤爲是經歷過培訓班的同窗，可能你們對技術把控不怎麼深，因此在簡歷中，應當只列你熟悉的技術。好比你項目裏就列了1個亮點，並且你能說清楚，那麼這是個加分項，但你若是列了3個，只講清楚2個，1個被問倒了，面試官會進一步質疑你在項目裏是否用到這個技術，再進一步會質疑你項目的真實性。

並且，你列好了之後，能夠請你的培訓老師或者比較資深的朋友幫忙把把關，看下技術是否有矛盾點，並且針對每一個技術，你要和實際項目結合起來，能講清楚爲何要用這個技術？遇到須要大費周章的分佈式集羣，你還得能說有什麼需求（每每是性能要求）要值得你配置集羣。

2 從項目的盈利角度再回顧下，目前不少項目不是從頭開始作，好比作個在線購物，這必定虧，若是面試官從這點來質疑你，你很難自圓其說。但若是你作的是維護項目，好比維護一個歷史項目，或者乾脆維護歷史項目裏的一個模塊，而不是什麼都從頭作起，那麼可信度就大大提高了。

3 別說你在項目裏只作開發。通常來講，你在項目裏，除了作開發以外，還會適當作自測或數據庫部署或項目部署等工做，若是你說在項目裏還經過ant或maven等方式打包項目，或或經過jenkins部署過程序，或者再加上經過看日誌排查過問題，那麼你說這個項目是商業項目，這可信度就大大提高。

4 這點其實我本來不想列上的，即所謂「哪怕吹牛也要打草稿」。這裏我倒不是鼓勵你們本身編造項目經驗（事實上我更反對），但我真見過很多候選人在描述項目背景，項目持續時間和在哪一個公司裏作的項目這些關鍵因素時，和簡歷有衝突，並且在我質疑時也說不清楚。仍是這句話，你作的項目你本身都說不清楚，那麼我真有足夠的理由來懷疑這個是學習項目，而不是商業項目。

其實，在我寫的Java Web輕量級開發面試教程和Java核心技術及面試指南這兩本書裏，列了更多準備項目描述的經驗。

6 再論經過描述技術提高項目可信度的方式

上述四點裏，關鍵是第一點，即準備項目裏用到的技術，以此來提高項目的可信度。其實我在最近面試java後端開發的感覺：若是就以平時項目經驗來面試，經過估計很難——再論面試前的準備這篇博文裏已經講過相關技巧，這裏再深刻講解些準備技巧。

1 準備技術使用的必要性，要讓面試官感受確實有必要使用這個技術。

我見過很多候選人對技術準備比較好，但忽視了「實用必要性」的說辭。尤爲在些培訓班裏，項目是老師給的，學生確實也已經理解，並且理解很透徹，但在培訓班的項目裏沒法模擬高併發的場景，因此我用「必要性」真就排查出很多培訓項目。

好比在項目裏用到了分佈式消息通信中間件kafka，但若是你的項目只部署在一臺服務器上，那麼這就屬於不必用，或者模塊間的通信量很少，用單機版的kafka便可，也無需用集羣。但若是你說，應用訪問量足夠大，或者模塊以微服務的形式部署在不一樣機器上，且模塊間通信量大，有必要用消息中間件異步來處理，那麼說用到kafka，這才能說得過去。

2 不只要準備理論知識，更要適當準備實踐類問題。

我本身也知道，若是候選人經過看資料，或者上培訓班，能夠對使用性技術瞭解很深，真就能夠以假亂真。因此我每每會經過一些配置方面的問題來提問。好比我就問，使用nginx時，你在配置文件裏配置過哪些元素？這類問題只要作過，必定能說得上。對此，你在介紹項目時甚至不應等面試官來問，主動說些配置環境，設置數據庫索引，設置Linux裏JVM參數等方式，再不濟你能夠說下項目是如何打成jar包部署到服務器上的，這樣必定能增長項目的可信度。

3 相比前兩點，這點就比較好準備。我在面試的時候，見到大多數的候選人，對於比較值錢的技術，好比Spring Cloud裏的負載均衡組件，只會簡單地使用，而不知道原理。對此，我給出的評價是，瞭解xx技術，但只會簡單使用。相比之下，你能夠看些底層的實現，或者畫出基於分佈式的框架圖，這樣，個人評語就會升級到「在項目裏用過xx技術，並且瞭解底層，對xx技術有必定的瞭解」。

4 這點我在其它博文裏也反覆提到，因爲重要，因此這裏再重複一次，你要講清楚這個技術對項目有什麼幫助，具體來講，在性能上或部署上有什麼幫助，好比你說用到了jenkins，經過它的「一點便可部署」功能能夠實現自動化部署，或者，經過用到了數據庫集羣，能應對高併發的場景，或者用到了JVM監控和優化，能解決項目因OOM而致使的性能降低。若是你能有條理地說，由於我項目裏有xx問題，因此咱們用了xx技術，並且講清楚這個技術是如何解決實際問題的，哪怕就憑這點，我就能相信這個項目是商業項目，而非學習項目。

7 培訓班出來後的第一份工做應當以積累經驗爲主

我身邊有很多朋友就是從培訓班出來的，如今也發展得不錯。不過，若是從培訓班出來後第一份工做就找大廠，好比大的互聯網公司或者大型外企或者知名公司，這類先例不是沒有，但很難，畢竟培訓項目要包裝成商業項目經驗，這老是有破綻的，何況很多同窗在進培訓班以前沒有相關經驗。

因此建議你們從培訓班後，找個通常的公司，積累些實戰經驗，這絕非難事，畢竟通常公司裏的廣泛面試要求是「能幹活便可」，不過話說回來，培訓班經歷外加2到3年的實際項目經驗，這真就和科班出身的程序員沒什麼差異了。說句不應說的話，這時你把兩三年前培訓班的學習經驗改爲項目經驗，這真能矇混過很多面試官了，但別來蒙我。

我見到過發展途徑是，培訓班後第一份工做很苦，尤爲是試用期階段更得996，但堅持過半年後，能立足，這個階段開始刷題外加準備分佈式高併發的技術點，外帶積累項目經驗，過了3年，若是能力通常就能夠經過外派的形式進大廠，若是能力能夠，真就能進BAT了。