1. 程式人生 > >面試中更多會考核相關技能的專案經驗——再論程式設計師該如何準備面試

面試中更多會考核相關技能的專案經驗——再論程式設計師該如何準備面試

    在如何準備Java面試?如何把面試官的提問引導到自己準備好的範圍內?這篇博文後,提到了不少引導的說辭和技巧,如果能把面試官的提問引導到事先準備好的亮點上,一方面確實可以更有效地耗費面試時間,另一方面也能最大程度地挖掘和展示自己的亮點。

    上述博文是站在戰術角度講述方法論,而本文會從“技術面試官憑什麼讓候選人過”這個本源性問題入手,從戰略角度再講些“面試準備”的方面和技巧,讀完本文後,大家其實會豁然開朗地發現,其實提升技能和準備面試並不衝突,也就是說,只要平時多挖掘現有專案,多深入細節和亮點,準備面試也就是“隨手”的事情。

1 面試問題都是圍繞“相關專案經驗”展開

    換位思考下,如果你是面試官,候選人達到什麼程度能讓過?能達到職位介紹的要求,能幹活。那怎麼能證明能幹活呢?只能是看候選人在之前專案裡是否用過對應技術,比如要招個資深開發,那麼要確認java框架,資料庫技術,分散式元件等jd裡提到的技術之前專案裡是否用過,如果要招架構師,那麼還得確認分散式元件方面的調優部署等技能是否有專案經驗。

    為什麼一定要有商業專案經驗呢?因為其它的培訓班專案經驗,或者自己除錯通過的學習專案,或者再是課程設計的專案,裡面也就是隻要功能事先即可,頂多加些微不足道的測試和打包部署的練習,而實現功能的程式碼可能也就是增刪改查,很少涉及到調優和分散式。

    相反在用以掙錢的商業專案裡,除了寫程式碼外,還需要哪些技能呢?單元測試,jenkins部署上線,除錯sql等效能,敏捷式管理等等,相信有過商業專案經驗的人一定還能再列出很多,更為關鍵的時,在商業專案裡,一定需要程式設計師具備通過看日誌debug分析問題和解決問題的能力,而且大多數商業專案都是分散式部署的,框架元件方面的技能絕非是簡單呼叫API。通過上述對比,大家能發現,大多數培訓班專案、課程設計專案還有其它學習專案,甚至還包括編造的專案,這些含金量都沒法和商業專案比。所以只要合格的面試官,面試問題一定會圍繞“技術在專案裡怎麼用”這個點。

    說到這裡,不少同學可能會舉出很多反例,確實在不少面試裡,用自編的專案也能過關,面試官也只會淺嘗輒止地問些理論問題。除卻面試官本身的能力外,不少初級開發崗其實公司很低,所以要求並不高,而且如果有些專案比較缺人,或者有些小公司乾脆沒人願去,所以在面試過程中降低了要求,對此候選人絕對不該因此沾沾自喜,而應當清楚認清自己的能力和公司的狀況。而對於高階開發以上的開發崗,如果無法證明相關技術有足夠的商業專案經驗,或者年限不夠,一般情況下是過不了面試的。

    那怎麼考察相關技能的專案經驗呢?後文會展開講,這裡先用大家都做過的資料庫,給出提問方式。

    1 基礎層面,用過哪些資料庫,多少經驗?Jdbc裡preparedstatment的用法,以及索引的概念等,這部分通過背題,或許可以通過。

    2 調優層面,索引,執行計劃的技巧,比如哪些sql用不到索引,並問在專案裡建過哪些索引,執行計劃要看哪些要素。

    3 排查問題層面,請結合例項,給出監控慢sql的做法,並講下用執行計劃等分析和解決慢sql的方法,這裡就涉及到看日誌監控和實際解決問題。

    4 如果是資深開發和架構師崗,再問mycat, redis叢集方面的問題,比如如何部署,分庫規則,快取時間等,也要求講述分析排查和解決實際問題的經驗。

    也就是說,如果候選人僅僅準備業務功能點,或者只背面試題,理論不結合實際,很難通過面試,更何況不少候選人乾脆是沒做準備。

2 很多面試相關的問題就迎刃而解

    正是因為“相關專案經驗”是考核候選人的重要標準(不敢說唯一,但確實很重要),所以很多面試相關的問題一想就明白。

    1 培訓班學生該不該隱瞞經歷?

    如果看到候選人最近參加過java培訓班,那麼面試官或許會想,為什麼要參加?之前的專案經驗是不是非java?然後問下來,會發現候選人相關經驗年限很短,甚至不足半年,如果一些公司和崗位對經驗的年限沒要求就算,如果有要求,可能候選人哪怕面試變現再出色,過面試的可能性也不大。

    2 為什麼有些面試官對培訓班學員有偏見?

    站在客觀公正的立場上,至少我個人對培訓班學員沒有主觀上的偏見,但由於培訓班專案經驗無法算作商業專案經驗,而且候選人在培訓班之前的經驗可能是非開發甚至非it的,而面試要求上有相關經驗的年限要求,那麼面試官可能不得不遵從。

    3 如果候選人從網上找個專案跑通,然後吃透裡面的流程和技術,能否把此當成專案經驗?

   這對候選人提升技術一定有幫助,但不能算作商業專案經驗,如果有些初級崗,或者是校招,有此類專案總比沒有強,如過已經工作過,那麼抱歉,此類專案對候選人幫助不大。

    4 網上的面試題,以及基於分散式等高大上值錢的專案有用嗎?

   面試題是理論方面的,而面試著重考核技術的應用,而一些包含值錢技術的專案,頂了天也是學習專案。可以是通過理論和值錢的學習專案瞭解技術,然後一定要想辦法把這些技術嵌入到你當前專案裡,比如你看會了redis,同時你專案裡,也做過,並排查過此類問題,兩者結合準備面試說辭,這才能讓值錢技術幫到你。

    5 面試時,博文出書等加分項有多少幫助?

    還是這句話,優先看專案經驗,並且優先看大廠的專案經驗。如果博文和你的書,和當前職位的相關性不大,哪怕在技術過關的前提下,最多幫你掙得一個“比較上進,學習能力強”的評價,如果技術不過關,這些幫不到你,甚至有些比較苛責的面試官還會認為你不務正業。如果博文和書確實能證明你技術的深度,那或許幫助會大些,但前提還是“能結合開發和解決過的問題,講清楚相關技術的用法和細節”。不過這裡說句大家可能不愛聽的話,一些公司或專案比較著急要人,或者面試下來的候選人能力都半斤八兩,那麼如果有候選人有加分項,確實有幫助,但候選人更應該結合當前專案,在技術上下功夫。    

    和麵試相關的問題還有很多,不過如果大家想明白“相關專案經驗”的重要性,很多問題其實都會迎刃而解。

3 再回顧看下,為什麼你都簡歷沒面試機會

    這裡先不說過面試,先說如何得到面試機會,因為一方面收到的簡歷中,很多沒面試價值,另一方面,不少候選人投再多的簡歷,也會石沉大海。

    為什麼簡歷沒面試機會?原因說白了很簡單:職位介紹上要求的技術,在簡歷上看不到有相關專案經驗,或者相關經驗年限不足。

    比如有些簡歷上,大書特書專案業務,而看不出專案用到的技術,或者列出的技術和職位要求不匹配,或者篩選的人要費很大功夫才能總結出該位候選人的技術以及使用年限。

    你簡歷投出去以後,如果讓對方一眼就看出你技術專案經驗第一很匹配,第二年限足夠,至少你有面試機會。所以簡歷無需花哨,可以遵循如下的原則。

    1 通讀每份職位介紹,定製化簡歷,開篇總綱性給出所要求技術的使用年限,最大可能匹配。

    2 介紹專案時,無需過多寫業務功能,多寫相關技術的使用技巧,比如分庫分表怎麼用的,redis用在業務裡怎麼用的。對於初級開發,儘可能寫上調優等亮點。

    3 如果可以,多寫開發程式碼以外的技能,比如部署,測試,監控,壓測方面的實踐技能。

    上述第2和第3點需要嵌入專案,如下給出段範例,在xx系統裡,我用到了mycat,redis等技術,其中mycat是針對xx業務的xx表進行分庫分表,分庫欄位是xxx,redis是快取xx模組發來的資料,超時時間是xx,而且針對xx業務的長sql,我們用到了執行計劃來調優。此外,在這個專案裡,我參與了部署和壓測等工作,在壓測中,根據xx模組發來的請求,我們第一優化了jvm效能,第二用redis快取了結果,從而實現了tps xx的效果。

    從中大家感受下“技術結合業務”的寫法,然後可以展開,這樣一寫,能清晰地讓面試官感覺你在專案裡用過,姑且不論實際面試效果,你至少有機會面試。

4 再論如何甄別非商業專案經驗,你如何寫商業專案經驗

    其實很多候選人也知道商業專案年限的重要性,所以會把一些學習專案改編成商業專案,甚至還會無中生有,而一些培訓班輔導就業的老師還會幫助學員“增加”專案經驗。

    有些專案編造得比較離譜,比如候選人在比較短的時間內,以比較少的人手完成了一個電商、財務或xx管理系統的專案,而且其中包含的技術都很值錢,分散式的,雲的都有。

    這類專案比較好甄別,畢竟現在很多是有現成產品的,你再開發違背了商業價值,或者裡面提到的技術或者和候選人年限不匹配,或者過於高大上,或者大多是沒上線。此類專案的甄別方式,我在從面試官甄別專案經驗的角度,說說如何在簡歷中寫專案經驗(java後端方向)這篇博文裡有詳細介紹。

    比較難甄別的是真中有假的專案,比如某初級開發最近1年的專案經驗只有增刪改查,但培訓班老師讓他把學到的分散式元件技術嵌入到這個專案裡。說真的吧,公司專案都有,還真是商業專案,說假的吧,畢竟你沒用過,你實際簡歷上專案經驗是由學習專案和商業專案嫁接而成。這種情況下,候選人如果面試時說得很好,真能過關,但論理這種做法畢竟不能算“誠信”。

    其實如果候選人寫簡歷不上心,真的商業專案還真會被當成學習專案或編造的專案。如下給出些描述商業專案的技巧。

    1 如果從名字上看,會讓人誤解,比如xx管理系統,xx電商,那麼就寫上客戶方是誰,做了多久,現在上線後的網址是什麼。

    2 寫點商業專案裡獨有的要素,比如junit單元測試,程式碼質量管理方式,用到maven,sonar等,這些學習專案大多不會寫。

    3 寫上部署,壓測之類的經驗,一方面這是亮點,另一方面學習專案一定不會有。

    簡歷上體現這三點,一般就不會被誤認為是學習專案,面試時,你再舉例說出專案裡你解決過的實際問題,比如通過日誌或監控發現問題,再說下如何解決的,這樣能進一步讓面試官感覺這個是商業專案。 

5 商業專案裡,再簡單的技術也能挖掘出亮點

    我在面試初級和高階開發時,很多候選人沒有主動展示技術亮點的意願,當我主動問及專案亮點時,不少人只是說些業務方面的。換句話說,我需要很吃力,才能挖掘到候選人的技術亮點,而這本該是候選人的義務。可能會有候選人認為面試官不能慧眼識珠,或者感嘆給到的工資很低,但如果你一方面在面試中只展示增刪改查,另一方面大談特談非技術方面的亮點,或者給出的亮點非常不值錢,那麼這就怨不得面試官了。其實,只要是個商業專案,一定能挖掘出很多亮點。

    1 專案管理方面,Maven, jira, Jenkins部署,Junit單元化測試,甚至docker, k8s,這些點其實面試時沒法深入問,你只要說明了,就能證實一定的專案管理和部署能力,而且這和工作年限無關,哪怕才2年經驗的人同樣可以展示。

    2 專案監控或業務埋點,比如CAT,Zabbix,再不濟可以是監控log裡exception,error關鍵字,以此引申出通過檢查日誌分析並排查問題的能力,面試中,藉此還能引導到JVM調優,資料庫效能優化和分散式元件方面的問題。

    3 Java核心這塊就不說了,稍微看些資料,就能挖掘出異常處理規範,快速失效,執行緒併發,HashMap等問題,而且這塊還可以結合底層程式碼講。

    4 資料庫效能優化方面,可以結合索引和執行計劃,如果可以再帶出MyCAT。

    對於初級開發而言,如果能充分展示上述方面的能力,一般的公司應該沒問題,小公司就更不說了,如果再能展示分散式元件方面的能力,估計挑戰下大廠也沒問題。但本文的主題是結合專案展示技能,下面再給出些“技術結合專案業務”的說辭。

    1 集合方面,我們專案在遍歷Arraylist等物件時,需要考慮快速失效的問題,因為在測試過程中發現過此類問題,然後展開。

    2 資料庫方面,我們專案會對慢sql進行監控,發現後會結合索引和執行計劃調優,比如在訂單模組裡,一個sql過慢,發現是因為表關聯太多,經過調整表結構後,此類問題就解決了。

    3 我們專案上線後,用zabbix監控記憶體,一旦發現過量,則會用dump觀察映象,並根據日誌排查問題,發現過的記憶體問題有,在訂單模組裡,過量使用ThreadLocal沒釋放,或者是用了大量的ArrayList沒clear。

    4 我們專案裡,由於需要從網路介面多次獲得資料,所以用redis快取資料,在實踐過程中,會適當地設定超時時間,而且會用xx策略設定快取主鍵,以防快取被擊穿。

    從中能看到,這些說辭結合了業務,比起單純地講理論要好很多,你這樣一說,就能讓面試官確信你確實有過實戰經驗,如果你說得好,甚至還能讓面試感覺你還有實際的排查問題解決問題的能力。而且,上述說辭都是很基本的,成本也不高,大多數專案都會用到。相比很多候選人無視這些亮點,只展示增刪改查的能力,你結合專案再多挖掘些,面試官一定會認為你比別人強。

6 以一組提問方面為例,分析如何在面試中準備值錢技術

    這裡就以之前提到的資料庫方面的問題,分析如何結合專案準備值錢技術。 

    1 基礎層面,用過哪些資料庫,多少經驗?Jdbc裡preparedstatment的用法,以及索引的概念等。

    這部分通過背題可以通過,問題不大。

    2 調優層面,索引,執行計劃的技巧,比如哪些sql用不到索引,並問在專案裡建過哪些索引,執行計劃要看哪些要素。

    先全面瞭解索引,執行計劃等概念,瞭解的時候需要涉及底層。然後觀察當前專案的的慢sql,看解決這些慢sql時,是怎麼用到索引的,在看執行計劃時,是根據哪些要素分析痛點,比如是因為沒走索引還是走全表掃描,據此準備若干個例子。面試時一旦被問到,先說索引資料結構,複合索引,執行計劃觀察要點等理論知識,再結合你準備好的實際問題,說下如何在專案裡用的。

    3 排查問題層面,請結合例項,給出監控慢sql的做法,並講下用執行計劃等分析和解決慢sql的方法。

    準備下觀察日誌,觀察監控的說辭,比如講,在專案裡,是用linux的xx工具監控慢sql,或者cat監控如何配置,如何報警。再結合若干線上案例,講下引發慢sql的原因,以及你是如何通過觀察日誌分析問題,最後通過什麼方法解決的,解決的方法無非也是建索引,引入redis等。

    4 如果是資深開發和架構師崗,再問mycat, redis叢集方面的問題,比如如何部署,分庫規則,快取時間等,也要求講述分析排查和解決實際問題的經驗。

    這塊首先需要講配置,比如分庫規則如何配,redis超時時間怎麼配,叢集如何用zk管理的,講的時候結合專案。同時也可以根據常見的問題,比如kafka訊息重複消費,或者mycat遇到沒分庫規則的sql,說下你是怎麼解決的。

   或許面試官未必會照著上述思路來提問,但面試官一定會核實你的技術是否有專案經驗,所以大家同樣可以圍繞“基礎知識”、“結合專案的調優技能”、“如何監控和發現問題”以及“解決線上問題用到的技能”這些方面準備面試說辭,面試時一一展開,剛才也說了,再簡單的專案也能挖掘不少值錢點,你就照著這個思路準備,一定能挖掘到不少亮點。至於該準備哪些方面的亮點?在最近面了不少java開發,據此來說下我的感受:哪怕事先只准備1小時,成功概率也能大大提升和已經提到過的如何準備Java面試?如何把面試官的提問引導到自己準備好的範圍內?博文裡,已經有了足量的說明。

7 以“專案經驗”外帶“實際解決過的問題”來容納技術亮點

    剛才已經反覆提到,你在面試中給出的亮點技能需要結合專案經驗,但很多同學在之前開發的模組裡,用到的技能其實是非常有限的,說白了就是增刪改查外帶一些調優,這也是普遍現象,相反如果一個初級開發,在面試中說,之前開發的模組又有jvm調優,又有分散式元件,再外帶資料庫效能優化,似乎可信度不高。

    對此,你可以把很多技術的實踐經驗歸納到“解決過的問題”上,比如你平時確實只做增刪改查,這哪怕對高階開發也不丟臉,但你平時工作很上進,遇到線上問題會主動參與,比如有oom問題,或者redis快取被擊穿,或者其它因分散式元件等方面而導致的問題,你參與排查並解決,那麼這些自然可以歸結成相關技術的專案經驗,而且你還能以此為例,展示自己分析日誌解決問題的技能。

    這樣的話,在專案裡你就有足夠多的專案,來容納網上提到的各種分散式元件以及其它值錢技能,甚至如果你有能力,還可以說參與過專案的部署上線以及壓測。總之還是這句話,理論技能本身不值錢,面試官一定只關心你,如何在開發、壓測、分析線上問題以及上線時,如何使用技術的。

8 總結:如果從戰略上藐視問題,會發現提升技能不算個事

    本文給出的觀點是,在面試時,程式設計師該結合專案講述各種技能,看上去這是個正確的廢話,但根據本人的面試結果,在面試前能結合專案準備亮點的,而且在面試中能結合專案充分展示技能的候選人並不多,這也是本文的價值。

    其實,從戰略上講,初級開發升級到高階開發需要提升的點非常有限,而高階開發提升到架構師所涉及到的技能也是能舉例說明的,更何況,在面試中能證明自己達到高階職位要比在工作中證明要容易很多,所以架構師等高階崗位也就這回事,並不是可望不可及的。

   但從戰術上講,由於技能只有結合專案實際才能發揮價值,所以程式設計師在平時工作中,絕不能只限於自己開發的業務,更要多參與解決線上問題,更要多看些值錢的技術,如果不知道哪些技術值錢,就看下比你工資高一倍人,他們精通哪些技術,你就學什麼。

   而且本文雖然是講程式設計師如何準備面試,其實給出的方法同樣適用於“程式設計師該如何升級”。再看我們身邊,會發現一些原本基礎不好,學校也一般的程式設計師朋友經過1,2年努力,能成功地拿到大廠的offer,也就是說,第一隻要努力方向不差,第二隻要肯持續上進,提升個技能其實不算個事,在這基礎上再經過面試試錯,進大廠然後在大廠裡收入飛速提升,其實也就是個時間問題。但相反,如果只是滿足於完成現有手頭的工作,那麼30歲以後依然在小公司間輾轉,這也是在情理之中了。

 

    最後感謝大家看完長文,本文寫了有4個小時,如果大家感覺可以,請多多點贊,有問題也可以多寫評論。

 

版權說明:

    如果要轉載本文,請先徵得本人同