我在部落格園裡乃至其它地方看到有不少對培訓班出身的程式設計師的評價，其實至少在我面試時，培訓班出來的程式設計師沒有原罪。

    我也面試不少程式設計師，從高階開發到初級開發都有，有985和211名校出身的，也有大專學習通過培訓班積累IT經驗的。我見過有候選人正大光明地把培訓經歷寫在簡歷上，也見過候選人千方百計地想把培訓經驗掩飾成專案經驗。對我來說（相信其它大多數技術面試官都一樣），我只需要考量候選人的以往商業專案經驗和實際技能，看下是否匹配本崗位。

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

    在開篇前，我引用兩段俗語，第一，外行看熱鬧，內行看門道。第二，一力降十會。至於為什麼要引用？本人絕非空穴來風，請大家自行體會。 

1 培訓專案如果被看穿，是會被扣去這段時間的專案經驗

    目前大多數培訓學校都會把學習專案包裝成商業專案，因為他們也知道商業專案的含金量更高。如果我在面試時判斷出候選人的專案是從培訓班裡得到的，我會給出如下的判斷。 

    第一，候選人掌握對相應的技術，比如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了。 

8 總結

    在本文裡，我列了些作為面試官甄別商業專案經驗的技巧，在此基礎上也給出了準備面試時商業專案經驗的方式。其實本文對大多數做IT的朋友多少有些幫助，但我自認為，對培訓班出身想從事程式開發的朋友幫助更大。

    本人最近工作比較忙，也在趕新的Python方面的書，儘管如此，我還是利用各種碎片時間寫成本文，所以請大家多多支援，如果感覺本文可以，請儘量通過點選下面的按鈕來推薦文字，如果大家想進一步聽本文中的某個話題，也請通過評論的方式來告訴我。

9 版權說明

    1 如果文章沒額外說明，則屬可轉載，例如本文。我在此已經做了授權，大家在轉載前無需告知。

    2 在轉載時，請用連結的方式，給出原文出處，別簡單地通過文字方式給出，同時寫明原作者是hsm_computer，。

    3 在轉載時，請原文轉載 ，謝絕在轉載時對本文做任何修改，更請勿在轉載時通過修改本文達到有利於轉載者的目的。

    4 有個別公眾號在轉載本人的文章後，會推廣本身的產品或連結，甚至會有個別，會在篡改本文原意的基礎上推廣自己的產品。對此本人起碼的要求是，在原文轉載後，做推廣前，說明本文和所推廣的內容無關，避免本人因同意轉載的善意而陷於不必要的連帶責任。

    本人自認為，有些文章能給轉載者帶來流量，況且上述要求也屬舉手之勞，所以請各位轉載者也相互幫忙。否則本人不得不採用合理的維權手段。