我在之前的面試過程中，一直會遇到這樣的問題：比如我要面試架構師，但我當時工作時，只有機會實踐高階開發的技能，架構師方面的技能，只能看理論，最多隻能在自己電腦上搭建個腳手架專案。

    這樣就進入了一個兩難的迴圈等待：為了應聘成功高階崗位，必須要在面試過程裡證明有相關實踐經驗，而相關經驗在面試成功前是沒機會實踐的。很多想通過面試換工作升級的同學都會遇到這樣的問題，在本文裡，就將講述相關的破局方法。

1 大公司裡的面試官如何分辨實踐經驗和理論經驗

    在跨越的過程中，戰略上一定要有信心，但戰術上一定不能有任何走捷徑的想法，因為技術面試官絕對能通過面試衡量出候選人的能力。

    有時候確實會睜隻眼閉隻眼，但絕對不是沒看清候選人的能力，而是專案緊招不到人，所以就招個態度好而能力尚有欠缺的人進來。但在大多數情況下，如果候選人被甄別出關鍵技術沒實踐經驗，或者說容納必備技術的專案是學習專案，那很難通過面試。下面我就綜合諸多面試官，給出些甄別候選人專案的方法。

    第一問容納技術的專案，比如問專案週期，專案參與人數，專案釋出情況和上線情況，如果真的做過，這個應該不會前後矛盾，這時能分辨出專案是商業專案還是學習專案。

    第二問技術在專案裡的使用情況，比如考察Mybatis，就會問些如何處理原子操作，如何配置資料來源，如何同Spring整合等問題，這類問題只要做過專案，那一定知道。

    第三問技術的上下文，所謂全棧提問，比如Mybatis在處理高併發會用Mycat，如何配置，又如如何處理Mybatis丟擲的異常，總之問些和該技術相關的問題點，有些培訓學校可能光關注技術，未必關注技術間的聯絡。

    第四問專案的部署，尤其是在linux上的部署。如果候選人簡歷上的專案沒真實實踐過，這塊絕對是有欠缺的，而有些培訓學校雖然講了Linux，但可能也就講到檢視日誌，執行安裝程式等水平，未必會做jenkins等整合化部署，而如果候選人自己的學習專案更不會涉及到這點。

    所以說，如果沒準備，單純就想靠裸面就實現跨越，基本上是不可能的，除非運氣爆棚，或者面試的是一家不怎麼講究的小公司。不過話說回來，程式設計師在沒任何實踐經驗的前提下實現跨越，這種例子比比皆是，大家如果靠自己摸索，也能做到這點，但在跨越時也得講究效率。

2 以培訓班的課程為學習方向，以培訓班的進度管理學習時間，同時實踐培訓班的專案 

    這裡並不是給任何培訓班做廣告，是否上培訓班大家自己斟酌。但培訓班（尤其時是知名培訓班）制定的培訓內容和進度是經過時間檢驗的，如果大家報名培訓班，這自然沒話說，用錢換時間換經驗，按著進度即可，但如果想不上培訓班，同時實現高效跨越，可以採用如下的步驟。

    第一，找份課程大綱，比如java，一般會從基礎語法一直講到架構，同時會給出案例，如果大家多找幾份大綱，會發現大同小異。

    第二，可以買書買視訊買收費專欄，總之想辦法獲取些系統講述知識的資料，比如買若干本Java SSM框架的書，看明白後自然就知道這方面的內容了，而且每個方面至少買2本書。這時不推薦自己看網頁而推薦買，因為這時如果自己看網頁學，往往忽視重點，或者在一些無關緊要的點上空費時間，而買來的資料往往具有系統性，能幫助大家降低試錯的成本。

     第三，之前時找大綱買書買資料，這時知識還沒進自己的大腦，這時就得用空閒時間邊執行程式碼邊看資料了。在看得時候，先注意廣度，先別挖掘太深。剛開始學的時候是要解決從零到有的問題。這裡執行的要點是時間管理，而資料則是到處可以得到。

    最後得除錯通若干個案例，比如java層面的，SSM，或Spring Cloud，或基於資料庫的專案，可以除錯幾個。這裡請注意，選擇專案的時候，業務可以非常簡單，甚至就一個頁面然後加增刪改查，但一定得包含全棧要素，比如從前端一直到後端框架然後到資料庫，最好再帶些打包部署步驟。

    其實如果大家上心的話，諸多培訓專案不是不可得，而且哪怕付費，也能得到不少專案。在實踐的時候，一般得遵循“三個月原則”，即不管學什麼，給自己制定的時間表是3個月，比如學java高階開發的知識點，從入門到架構到專案，一般用3個月即可。3個月如果學不好，那麼可能就是態度或方法上的問題了。

3 學會技術了還不夠，還得能證明自己在專案裡用過

    通過之前的方法，大家能在比較短的時間內，系統掌握更高階的技能，但這還不夠，這僅僅是學習經驗。之前也講過，面試的時候得證明技術在專案裡實踐過，那麼怎麼彌補專案經驗呢？我就以分散式元件Dubbo舉例來說明。

    1 通過之前的學習，好歹能知道dubbo的基本用法，比如如何遠端呼叫，如何編寫配置檔案，然後就到公司找個dubbo的專案，爭取看下他們的程式碼，看下真實專案裡是怎麼用dubbo的，有時甚至不用找，自己專案裡就有，但可能之前沒費心關注。

    2 真實專案裡，除了實現程式碼功能外，更需要考慮“異常”和“釋出時”的情況，比如dubbo呼叫超時了怎麼處理，結點失效了又該怎麼辦？尤其地，在釋出時，更新了遠端呼叫的介面，那如何切流量保證平穩釋出。 這裡我僅僅是給出了若干問題，但如果大家留心了，會發現一大堆“實現功能”之外的問題，把這些問題搞明白了，能在面試中講清楚了，就能證明自己的實踐經驗。

    3 在真實專案裡，一定會出現相關產線問題，比如哪天因dubbo超時時間沒設定好導致服務長時間沒返回，大家可以留意相關問題的排查方法（比如通過看什麼日誌）和解決方法，如果是大家經歷過的，可以寫到簡歷中，這樣也能證明自己的實際專案經驗。

    以上僅是以dubbo為例，事實上，在自己或者附近的專案裡，包含了值錢技術遠不止一個，可能之前因為自己的級別，專案經理不會安排相關的活，從而導致沒實踐經驗，但這不是能阻止大家接觸更高階的知識點。並且，“在簡歷和麵試中證明自己相關技能的實踐經驗”要比“熟練地在專案裡應用相關技能”簡單很多。

    一方面，面試時你可以引導面試官的提問，在以我的親身經歷為例，告訴大家寫簡歷和麵試的技巧（面向高階開發和架構師）這篇博文裡，我就講述瞭如何引導面試官提問之前技能的方式，另一方面，甚至你都不用引導，其實面試時，面試官也就用“如何處理異常情況”和“如何釋出”等問題點來考察實踐經歷。 

4 可以用部落格，出書和出視訊等方式來證明自己

    通過上述方法，大家不僅能掌握比當前級別高的技能，更能證明自己在專案裡用過。

    不過在面試中，正是因為面試官只能用過簡歷瞭解候選人，所以得用問題來考察，但話說回來，如何候選人有能證明自己的東西呢？第一這些至少是加分項，第二萬一有問題沒回答好，好歹還能用博文或書來證明自己的相關經驗。哪些能作為證明點？

    第一是部落格，別就一兩篇，最好是數量比較多，而且若干篇博文裡有幾篇質量比較高的。

    第二是出書。出書並不像想象中那樣難，而且哪怕剛畢業，只要肯上心即可，比如案例書，真不需要太多的實踐經驗積累。

    第三是有專欄或公眾號，最好是原創性文字多些。

    大家可以想象下，如果你有系列博文或書，那麼說自己學習能強有上進心能承受大壓力，這就不是空話了。而且在應聘比自己當前級別高的崗位時，面試結果大多估計是可上可下，這時如果能有看得見摸得著的東西來證明自己，這樣成功的可能性就大很多了。

5 一定得在面試前準備高階技能實踐經驗的表達方式

    這一定得在面試前準備好說辭，儘量少在面試時現場發揮。其實在上文裡已經給出相關重點，這裡來總結下準備的方式。

   1 大家可以想下，有哪些細節，只有做過才知道，面試前就可以準備這些。比如部署Dubbo，配置檔案裡超時時間怎麼設定。

   2 在第1點的基礎上，儘量準備些多元件整合使用的關鍵細節，比如Dubbo和Zookeeper整合，nginx和限流元件hystrix整合的實現細節，往往在專案裡經常用到多個元件，這樣組合起來講，可信度更高。

   3 如果可以，再準備些排查解決問題的介紹。假設候選人能詳細說明在專案中排查Kafka OOM異常的方法，比如如何看日誌定位問題，如果通過修改配置來解決，這樣一定能證明自己在實踐中用過。

   4 最好是能結合業務場景來說，比如某支付場景，需要每秒2000的併發，那麼是怎麼通過配置怎麼通過整合元件實現的。 

   其實大家可以照此方式，自己想些準備點，比如相關細節，相關底層程式碼，相關排查問題的方式都行。有些同學或許會說，由於自己沒實踐機會，所以沒法理直氣壯地說自己做過這裡不提倡弄虛作假，在前文裡也提到過，相關實踐經驗是靠自己在專案組內或其它專案組裡爭取來的，不能靠坐等得到。 

    看到這裡大家也能發現，上述能證明自己實踐經驗的說辭，在面試中現場想，一定沒法說好。而且在跨越階段，平時工作中大多數用到的還是本階段的技術，只有少數部分才是高階技術，這就更需要用上述方法準備了。 

6 總結，求推薦：可以邊學邊面試，別用“準備不充分"作為懈怠的理由

    本文主要從從準備技術和準備實踐經驗這兩方面講述了實現跨越的方法，更在此基礎上講述了應聘更高階崗位的面試準備技巧。

    我就見過不少人，為了求穩定，往往會以“沒準備好”作為理由，不去挑戰更高階的崗位，同時平時也不看更高階的技術，就每天得過且過。這樣看似每天很舒服，而且在一個公司裡熟悉業務熟悉人際關係後，日子還會過得很滋潤，但長久一來，競爭力就喪失了。 

    其實實現跨越不簡單，畢竟如果平時就只關注自己的活，確實沒機會接觸更高階的技術。不過也不難，因為更高階技術的資料網上到處有，而實踐機會，如果平時多觀察多動手，也不能說少，所以大家不要以各種理由來阻礙自己的進步。

   如果大家感覺本文有幫助，請推薦本文，也歡迎大家通過評論來交流。

版權說明：

    有不少網友轉載和想要轉載我的博文，本人感到十分榮幸，這也是本人不斷寫博文的動力。關於本文的版權有如下統一的說明，抱歉就不逐一回復了。

    1 本文可轉載，無需告知，轉載時請用連結的方式，給出原文出處，別簡單地通過文字方式給出，同時寫明原作者是hsm_computer。

    2 在轉載時，請原文轉載 ，謝絕洗稿。否則本人保留追究法律責任的權利。

   &n