前幾天我寫了篇文章,在作技術面試官時,我是這樣甄別大忽悠的——若是面試時你有這樣的表現,估計懸,獲得了你們的普遍關注,一度上了最多評論榜。不過,也收到了4個反對,也有有朋友說:」簡直不給人活路!」,我能夠想象是哪些朋友給的反對。html
因爲項目介紹是面試中的重頭戲,一些技術問題會圍繞你介紹的項目展開,你也能夠在介紹項目時亮出你的優點。因此,在準備面試的時候,你能夠刷題,但首先得準備好你的項目介紹,由於這關係到你面試的成敗,文本就將圍繞這點展開。linux
若是在簡歷中的項目經驗是真實的,那麼本文給出的技巧必定能提高面試官對你的評價,畢竟你不只要能力強,更要讓面試官感受出這點。若是你的項目經歷是虛構的,那麼我也不能阻止你閱讀本文。若是你用虛構的項目經驗外加你的(忽悠)本事外加本文給出的技巧進了某個公司,我想這個公司的面試官也怨不到我頭上,畢竟面試技術是中立的,就看被誰用。nginx
開場白結束,正文開始。web
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------面試
好比某個職位介紹裏,要求候選人有Spring Boot相關經驗,數據庫要會Oracle,並且須要有分佈式組件,好比nginx,dubbo等的相關經驗,那麼你就得回顧下你上個或以前的項目,是否用到過一樣的或相似的技術,若是有,那麼就得加到簡歷上,這些技術無需在簡歷上展開,但得結合項目具體需求寫。redis
通常的寫法,在項目裏,我用到了dubbo,redis等的技術。 spring
比較好的寫法,在項目裏的訂單管理模塊裏,咱們是用dubbo的方式調用了客戶管理系統裏的方法,調用的時候咱們還考慮到了超時等的異常狀況。在頁面展現部分,咱們用redis緩存了商品信息,redis是用主從熱備。sql
對比上述兩種寫法,很明顯,第二種寫法明顯更有說服力,由於其中列出了只有用過才知道的點,這樣就能向面試官證實你確實用過相關技術。數據庫
相似的,在職位介紹裏提到的技術,最好都用一樣的方法寫到簡歷中。不過這裏請注意,過猶不及,好比職位介紹裏提到了5個技術,你用到了其中的3個,那麼你原本也能夠經過面試。但若是你本身在項目裏拼接了一個實際沒用到的技術,那麼你就得本身承擔後果了。 設計模式
在本文開頭提到的這篇文章裏,我已經分享過甄別商業項目的方法。這裏我經過些僞裝商業項目的案例來做爲反面教材,以此來講明商業項目經驗該怎麼描述。
1 小A,3本學校畢業,計算機系,2年相關經驗,以前的公司是一個名不見經傳的公司,也就叫xx科技公司,但描述的項目卻很高大上,是xx ERP項目。疑點分析:若是某大型公司,或國企,要作ERP或之類的大型項目,或者本身開發,或者讓別的大公司開發(由於能出得起這個錢),若是是小公司要用,估計也就拿別人的現成的代碼來改,通常不會出這個錢,因此遇到人經歷少,公司規模小但項目頗有名頭的簡歷,我不能說是一概排除,但我會問很細。
2 小B,2本計算機系,3年經驗,但最近有3個月工做斷檔的記錄。以前的公司是個軟件公司,但並不是是一個互聯網公司,但簡歷上寫的技術很是新潮,好比分佈式緩存,dubbo之類的,並且用到了集羣。仍是這句話,技術是爲成本服務,你上個項目規模不大,也不可能有高併發的流量,那麼爲何要用這些技術?
遇到這類簡歷,我就找些用過就必定能知道的問題來問,好比Redis的基本數據結構,redis如何部署,如何看redis日誌,在上述案例中,我就經過這個方法發現該項目實際上是個學習項目,並且這個項目是在培訓學校裏學的。
3 小C,最近簡歷上寫的是個xx系統(你們能夠理解成金融物流保險等),但時間跨度比較可疑,通常來講,作個系統至少10我的左右,並且得大半年,但他簡歷上寫的參與時間是3個月,這和培訓學校裏的學習時間很是相近。並且,在簡歷中寫的是本身開發了xx系統裏的xx模塊,用到了redis,logstash等技術。這類簡歷的疑點是,第一,用了3個月完成了一個項目,並且該項目裏有高新技術,且作好了之後立刻離職了,這個和實際狀況不符,很像培訓項目。
其實簡歷的疑點不止上述三個,你們也能夠換位思考下,若是你是面試官,看到這份簡歷,會相信嗎?不少疑點其實很明顯。
下面我說下真實項目裏會出現的狀況,寫這些內容的目的不是讓有些同窗把學習項目和培訓項目往商業項目上靠,而是讓你們的簡歷更具有說服力。
1 工做年限比較少的同窗,未必會開發完成一個模塊或參與一個項目的開發,更多場景下是參與一個維護項目,好比公司一個項目已經上線了,這個項目是歷史項目,因此用的技術未必最新,但在維護項目裏,其實也會開發一些功能點,該用的技術一個不會少,針對每一個模塊維護的時間週期也不會太長,好比每月,針對某個模塊上線3個功能點,這樣也是合情合理的。
2 仍是這句話,若是有用到比較新的技術,結合業務場景寫,好比用到了redis,你是緩存了哪類業務數據,這類業務數據的特色若是真的是符合緩存條件的,那麼就加深了你熟悉這個技術的可信度。
3 你站在項目經理的角度想一下,某個功能若是工期很緊,並且數據量和併發量真的不大,那麼爲何要用分佈式組件?換句話說,若是你在簡歷裏寫的項目背景裏,有高併發請求,那麼引入分佈式組件的可信度就高了。並且,項目經理會讓一個工做經驗不足的人獨立使用技術含量高的組件嗎?若是候選人工做經驗很少,那麼比較可信的描述是,由架構師搭建好組件框架,本人用到其中一些API,但用的時候,對該組件的流程和技術坑很是瞭解,那麼以此證實本身對該組件比較熟悉,這樣可信度就很是高了。
換句話說,你寫好簡歷裏的項目描述後,本身先讀一遍,若是有誇張的成分,更得多推敲,除了個別虛假簡歷以外,不少狀況下,其實簡歷是真實的,但沒寫好,有不少漏洞,被面試官一質疑就慌了,致使面試官認爲簡歷不真實。
其實證實相關項目經驗是商業項目,這僅僅是第一步,更多的時候,你得經過簡歷中的項目描述,證實你的技能和職位描述相匹配,再進一步,你也能夠證實你確實用過一些比較值錢的技術。
對於項目開發而言,只要項目是真實的,你就必定會經歷過一些場景,對於技術而言,只要你用到了,那麼必定能說出些「海底針」。因此在寫簡歷時,建議你們列些以下的關鍵點,以證明真實性。
1 項目的背景,多少人作?作了多久?用什麼工具打包部署發佈(好比ant加jenkins)?用到哪些測試工具?用什麼來進行版本管理(好比Maven+JIra)?如何打印日誌(好比logger)?部署環境時,用到哪一個web服務器和數據庫(好比spring boot+oracle)。
這些話在簡歷中一筆帶過也用不了多少文字,但這樣不只能提高項目的真實性,更能展現你的實際技能。
2 項目的開發模式和開發週期,好比用敏捷開發,那麼每個月做爲一個週期,每次發佈個若干功能,在每一個週期發佈前幾天,會凍結開發,在開發過程當中,會有天天的站會,代碼開發完成後,會有code review。
3 在寫技術(尤爲是值錢技術)描述時,最好寫些細節,好比用到了dubbo,那麼能夠寫須要設置dubbo超時時間和重試次數是1,不然可能會出現調用,若是用到了線程池,那麼如何避免線程池中的OOM問題,或者用到了nginx,你就把配置文件裏的關鍵要素寫些出來。
也就是說,你寫技術時,不只得結合項目需求寫(即xx技術實現了xx功能),最好再些一些(不用太多)這個技術的用法細節(也未必太深)。面試官其實就看你用到的技術是否和職位匹配,若是職位介紹裏的技術點你有都招這點要求寫了,至少在篩選簡歷的時候,你過關的可能性就很大了。
4 最好寫些你解決的實際問題,大而言之,實際問題能夠包括配置集羣時的要點(好比必定要設置某個配置),小而言之,你能夠寫如何實現一個功能(好比出統計報表時,你用到了數據庫裏的行轉列的功能)。哪怕是學習項目和培訓項目,你運行通現有代碼的時候,也會遇到各種的坑,這就更不用說商業項目了。在簡歷裏項目描述部分,你就寫上一兩個,這樣證實真實性的力度絕對會很是高。
5 加上單元測試和分析問題和排查問題的描述。
好比,在這個系統裏,我是用SoapUI做爲自測的工具(或者用JUnit),在測試環境上,若是出現問題,我會到linux裏,用less等命令查看日誌,再用JMeter等工具查看JVM的調用狀況,以此來排查問題。
這種話在簡歷中寫下大概的描述,給出關鍵字(好比Jmeter,SOAPUI或職位介紹裏出現的關鍵字)便可,不用展開,但在面試前要準備說辭。
我知道有些候選人會對項目描述作些改動,好比在最近的項目描述裏,加上些以前項目裏用到的技術,或者加上職位描述裏提到的技術。在這種作法是否恰當,你們本身評估,但若是你在這類技術描述裏,加上本部分提到的一些要點,面試官就很難甄別了。
這裏說句題外話,我面試過的候選人,從他們的表現來看,不少人是不許備項目描述的,是想到哪說到哪,這樣的話,若是你準備了,和你的競爭者相比,你就大佔優點了。
在本文的第3部分裏,我給出了5個方面,在簡歷裏,你未必要寫全,但在準備面試說辭時,你必定得都準備。
1 你在項目描述裏列到的全部技術點,尤爲是熱門的以及在職位介紹裏提到的技術點,你必定得準備說辭。也是按「技術如何服務需求」以及「技術實現細節」來講,更進一步,你最好全面瞭解下這個技術的用法。好比nginx如何實現反向代理,該如何設置配置以及lua腳本,若是分佈式系統裏某個結點失效了,我想在反向代理時去掉,那該怎麼在nginx配置裏設。針對這個技術的經常使用問題點,你最好都準備下。
2 介紹項目時,能夠介紹用到哪些技術,但別展開,等面試官來問,所謂放長線釣大魚。這個效果要比你直接說出來要好不少。
3 有些基礎的技能需求,在職位描述裏未必會列,但你必定得掌握。好比經過設計模式優化代碼架構,熟悉多線程併發,熟悉數據庫調優等。關於這些,你能夠準備些說辭,好比在這個項目裏,遇到sql過長的狀況,我會經過執行計劃來調優,若是經過日誌發現JVM性能不高,我也能排查問題,而後坐等面試官來問。
4 開闊你的視野,別讓面試官感受你只會用很是初步的功能點。好比你項目裏用到了dubbo,但在項目裏,你就用到了簡單的調用,那麼你就不妨搜下該技術的深刻技術以及別人遇到的坑,在面試過程當中,你也能夠找機會說出來。
剛纔也提到了,在介紹項目裏,你能夠拋些亮點,但未必要展開,由於介紹項目時,你是介紹總體的項目以及用到的技術,若是你過於偏重介紹一個技術,那麼面試官不只會認爲你表達溝通方面有問題,並且還會認爲這個技術你事先準備過。
以下列些你們能夠拋出的亮點:
1 底層代碼方面,你們能夠說,瞭解Spring IOC或Nginx(或其它任何一個職位介紹裏提到的技術)的底層實現代碼。面試時,你們能夠先經過UML圖的形式畫出該技術的重要模塊和過程流程,再經過講述其中一個模塊的代碼來講明你確實熟悉這個技術的底層實現。
2 數據庫調優方面。好比oracle,你能夠用某個長SQL爲例,講下你經過執行計劃看到有哪些改進點,而後如何改進,這樣的例子不用多,2,3個便可,面試時估計面試官聽到其中一個之後就會認爲你很是熟悉數據調優了。
3 JVM調優和如何經過設計模式改善代碼結構,在Java核心技術及面試指南裏我已經提到了,這裏就不展開了。
4 架構層面的調優方法,好比經過分庫分表,經過數據庫集羣,或者經過緩存。
其實關於亮點的內容,我在Java Web輕量級開發面試教程裏,也有詳細描述。這裏想說的是,你們能夠準備的亮點毫不止上述4個,你們能夠從調優(好比經過分佈式優化併發狀況場景)和技術架構(好比SSM, 分佈式消息隊列)上準備。再囉嗦一句,職位介紹裏提到的技能點,好比Redis,你們還能夠用熟悉底層實現代碼來做爲「亮點」,好比介紹項目時,輕描淡寫地說句,我熟悉Redis底層代碼(固然也能夠寫到簡歷上),而後等面試官來問時,動筆說下。
按照上述的建議,只要你能力能夠(哪怕可上可下),你經過技術面試的可能性就大大增長了。但面試時,若是你表現出以下的軟實力,好比在簡歷上項目描述部分寫上,或介紹項目時說出,那麼面試官甚至會感受你很優秀。
1 該項目的工期比較緊,我會合理安排時間,必要時,我會在項目經理安排下週末加班。(體現你的責任心)
2 這個項目裏,用到了分佈式組件技術,剛開始我對此不熟悉,但我會主動查資料,遇到問題,我會及時問架構師,解決問題後,我會主動在組內分享。(有責任心,學習能力強,有團隊合做意識,有分享精神)
3 遇到技術上或需求上的疑點或是我我的沒法完成問題點,我會主動上報,不會坐等問題擴大。
4 在開發項目的過程當中,經過學習,我慢慢掌握了Git+Ant+Jeninks的打包發佈部署流程,如今,我會負責項目裏的打包工做。或者說,在組內,我會天天觀察長SQL腳本和長Dubbo調用的狀況,若是遇到問題,我會天天上報,而後你們一塊兒解決問題。(不只能完成本職工做,並且還能積極分擔項目組裏的其它工做)
5 若是出現問題,我主動會到linux裏經過xxx命令查看日誌,而後排查問題。(不只積極主動,並且掌握了排查問題的方法)
6 我會和測試人員一塊兒,用xxx工具進行自動化測試,出現問題而後一塊兒解決。(工做積極,並且掌握了測試等的技巧)
7 在項目裏,我會用Sonar等工具掃描代碼,出現質量問題,我會和你們一塊兒協商改掉。(具備代碼質量管理的意識,並且具備提高代碼質量的能力)
本文歡迎轉載,轉載前請和本人說下,請全文轉載並用連接的方式指明原出處。
本文給出的準備項目描述和說辭的經驗,是根據本人以及其它多位資深技術面試官的經驗總結而來。若是你們感受本文多少有幫助,請點擊下方的推薦按鈕,您的推薦是我寫博客的最大動力。若是你們在這方面有問題,能夠經過評論問或私下給我發消息,通常我都會回。