再論面試前準備簡歷上的專案描述和麵試時介紹專案的要點
前幾天我寫了篇文章，JavaArchitect/p/9704011.html" rel="nofollow,noindex" target="_blank">在做技術面試官時，我是這樣甄別大忽悠的——如果面試時你有這樣的表現，估計懸 ，得到了大家的廣泛關注，一度上了最多評論榜。不過，也收到了4個反對，也有有朋友說：”簡直不給人活路！”，我可以想象是哪些朋友給的反對。
由於專案介紹是面試中的重頭戲，一些技術問題會圍繞你介紹的專案展開，你也可以在介紹專案時亮出你的優勢。所以，在準備面試的時候，你可以刷題，但首先得準備好你的專案介紹，因為這關係到你面試的成敗，文字就將圍繞這點展開。
如果在簡歷中的專案經驗是真實的，那麼本文給出的技巧一定能提升面試官對你的評價，畢竟你不僅要能力強，更要讓面試官感覺出這點。如果你的專案經歷是虛構的，那麼我也不能阻止你閱讀本文。如果你用虛構的專案經驗外加你的（忽悠）本事外加本文給出的技巧進了某個公司，我想這個公司的面試官也怨不到我頭上，畢竟面試技術是中立的，就看被誰用。
開場白結束，正文開始。
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1 面試前，回顧下你最近的專案經驗，在對比下職位介紹，在簡歷中多列些契合點
比如某個職位介紹裡，要求候選人有Spring Boot相關經驗，資料庫要會Oracle，而且需要有分散式元件，比如nginx，dubbo等的相關經驗，那麼你就得回顧下你上個或之前的專案，是否用到過同樣的或類似的技術，如果有，那麼就得加到簡歷上，這些技術無需在簡歷上展開，但得結合專案具體需求寫。
一般的寫法，在專案裡，我用到了dubbo，redis等的技術。
比較好的寫法，在專案裡的訂單管理模組裡，我們是用dubbo的方式呼叫了客戶管理系統裡的方法，呼叫的時候我們還考慮到了超時等的異常情況。在頁面展示部分，我們用redis快取了商品資訊，redis是用主從熱備。
對比上述兩種寫法，很明顯，第二種寫法明顯更有說服力，因為其中列出了只有用過才知道的點，這樣就能向面試官證明你確實用過相關技術。
類似的，在職位介紹裡提到的技術，最好都用同樣的方法寫到簡歷中。不過這裡請注意，過猶不及，比如職位介紹裡提到了5個技術，你用到了其中的3個，那麼你本來也可以通過面試。但如果你自己在專案裡拼接了一個實際沒用到的技術，那麼你就得自己承擔後果了。
2 能幫到你的其實是和職位相關的商業專案經驗（含簡歷疑點和如何避免）
在本文開頭提到的這篇文章裡，我已經分享過甄別商業專案的方法。這裡我通過些假裝商業專案的案例來作為反面教材，以此來說明商業專案經驗該怎麼描述。
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，但用的時候，對該元件的流程和技術坑非常瞭解，那麼以此證明自己對該元件比較熟悉，這樣可信度就非常高了。
換句話說，你寫好簡歷裡的專案描述後，自己先讀一遍，如果有誇張的成分，更得多推敲，除了個別虛假簡歷之外，很多情況下，其實簡歷是真實的，但沒寫好，有很多漏洞，被面試官一質疑就慌了，導致面試官認為簡歷不真實。
3 沉浸入專案角色，多列些專案管理工具和技術使用細節（就是坑）
其實證明相關專案經驗是商業專案，這僅僅是第一步，更多的時候，你得通過簡歷中的專案描述，證明你的技能和職位描述相匹配，再進一步，你也可以證明你確實用過一些比較值錢的技術。
對於專案開發而言，只要專案是真實的，你就一定會經歷過一些場景，對於技術而言，只要你用到了，那麼一定能說出些“海底針”。所以在寫簡歷時，建議大家列些如下的關鍵點，以證實真實性。
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或職位介紹裡出現的關鍵字）即可，不用展開，但在面試前要準備說辭。
我知道有些候選人會對專案描述做些改動，比如在最近的專案描述裡，加上些之前專案裡用到的技術，或者加上職位描述裡提到的技術。在這種做法是否恰當，大家自己評估，但如果你在這類技術描述裡，加上本部分提到的一些要點，面試官就很難甄別了。
4 事先得排練介紹專案的說辭，講解時，一定得圍繞職位需求要點
這裡說句題外話，我面試過的候選人，從他們的表現來看，很多人是不準備專案描述的，是想到哪說到哪，這樣的話，如果你準備了，和你的競爭者相比，你就大佔優勢了。
在本文的第3部分裡，我給出了5個方面，在簡歷裡，你未必要寫全，但在準備面試說辭時，你一定得都準備。
1 你在專案描述裡列到的所有技術點，尤其是熱門的以及在職位介紹裡提到的技術點，你一定得準備說辭。也是按“技術如何服務需求”以及“技術實現細節”來說，更進一步，你最好全面瞭解下這個技術的用法。比如nginx如何實現反向代理，該如何設定配置以及lua指令碼，如果分散式系統裡某個結點失效了，我想在反向代理時去掉，那該怎麼在nginx配置裡設。針對這個技術的常用問題點，你最好都準備下。
2 介紹專案時，可以介紹用到哪些技術，但別展開，等面試官來問，所謂放長線釣大魚。這個效果要比你直接說出來要好很多。
3 有些基礎的技能需求，在職位描述裡未必會列，但你一定得掌握。比如通過設計模式優化程式碼架構，熟悉多執行緒併發，熟悉資料庫調優等。關於這些，你可以準備些說辭，比如在這個專案裡，遇到sql過長的情況，我會通過執行計劃來調優，如果通過日誌發現JVM效能不高，我也能排查問題，然後坐等面試官來問。
4 開闊你的視野，別讓面試官感覺你只會用非常初步的功能點。比如你專案裡用到了dubbo，但在專案裡，你就用到了簡單的呼叫，那麼你就不妨搜下該技術的深入技術以及別人遇到的坑，在面試過程中，你也可以找機會說出來。
5 在專案介紹時多準備些“包袱”
剛才也提到了，在介紹專案裡，你可以拋些亮點，但未必要展開，因為介紹專案時，你是介紹整體的專案以及用到的技術，如果你過於偏重介紹一個技術，那麼面試官不僅會認為你表達溝通方面有問題，而且還會認為這個技術你事先準備過。
如下列些大家可以丟擲的亮點：
1 底層程式碼方面，大家可以說，瞭解Spring IOC/">IOC或Nginx（或其它任何一個職位介紹裡提到的技術）的底層實現程式碼。面試時，大家可以先通過UML圖的形式畫出該技術的重要模組和過程流程，再通過講述其中一個模組的程式碼來說明你確實熟悉這個技術的底層實現。
2 資料庫調優方面。比如oracle，你可以用某個長SQL為例，講下你通過執行計劃看到有哪些改進點，然後如何改進，這樣的例子不用多，2,3個即可，面試時估計面試官聽到其中一個以後就會認為你非常熟悉資料調優了。
3 JVM調優和如何通過設計模式改善程式碼結構，在Java核心技術及面試指南 裡我已經提到了，這裡就不展開了。
4 架構層面的調優方法，比如通過分庫分表，通過資料庫叢集，或者通過快取。
其實關於亮點的內容，我在36095.html" target="_blank" rel="nofollow,noindex"> Java Web輕量級開發面試教程 裡，也有詳細描述。這裡想說的是，大家可以準備的亮點絕不止上述4個，大家可以從調優（比如通過分散式優化併發情況場景）和技術架構（比如SSM， 分散式訊息佇列）上準備。再囉嗦一句，職位介紹裡提到的技能點，比如Redis，大家還可以用熟悉底層實現程式碼來作為“亮點”，比如介紹專案時，輕描淡寫地說句，我熟悉Redis底層程式碼（當然也可以寫到簡歷上），然後等面試官來問時，動筆說下。
6 別讓面試官感覺你只會使用技術
按照上述的建議，只要你能力可以（哪怕可上可下），你通過技術面試的可能性就大大增加了。但面試時，如果你表現出如下的軟實力，比如在簡歷上專案描述部分寫上，或介紹專案時說出，那麼面試官甚至會感覺你很優秀。
1 該專案的工期比較緊，我會合理安排時間，必要時，我會在專案經理安排下週末加班。（體現你的責任心）
2 這個專案裡，用到了分散式元件技術，剛開始我對此不熟悉，但我會主動查資料，遇到問題，我會及時問架構師，解決問題後，我會主動在組內分享。（有責任心，學習能力強，有團隊合作意識，有分享精神）
3 遇到技術上或需求上的疑點或是我個人無法完成問題點，我會主動上報，不會坐等問題擴大。
4 在開發專案的過程中，通過學習，我慢慢掌握了Git+Ant+Jeninks的打包釋出部署流程，現在，我會負責專案裡的打包工作。或者說，在組內，我會每天觀察長SQL指令碼和長Dubbo呼叫的情況，如果遇到問題，我會每天上報，然後大家一起解決問題。（不僅能完成本職工作，而且還能積極分擔專案組裡的其它工作）
5 如果出現問題，我主動會到linux裡通過xxx命令檢視日誌，然後排查問題。（不僅積極主動，而且掌握了排查問題的方法）
6 我會和測試人員一起，用xxx工具進行自動化測試，出現問題然後一起解決。（工作積極，而且掌握了測試等的技巧）
7 在專案裡，我會用Sonar等工具掃描程式碼，出現質量問題，我會和大家一起協商改掉。（具有程式碼質量管理的意識，而且具有提升程式碼質量的能力）
7 版權說明，總結，求推薦
本文歡迎轉載，轉載前請和本人說下，請全文轉載並用連結的方式指明原出處。
本文給出的準備專案描述和說辭的經驗，是根據本人以及其它多位資深技術面試官的經驗總結而來。如果大家感覺本文多少有幫助，請點選下方的推薦按鈕，您的推薦是我寫部落格的最大動力。如果大家在這方面有問題，可以通過評論問或私下給我發訊息，一般我都會回。