前幾天我寫了篇文章，在做技術面試官時，我是這樣甄別大忽悠的——如果面試時你有這樣的表現，估計懸，得到了大家的廣泛關注，一度上了最多評論榜。不過，也收到了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或Nginx（或其它任何一個職位介紹里提到的技術）的底層實現代碼。面試時，大家可以先通過UML圖的形式畫出該技術的重要模塊和過程流程，再通過講述其中一個模塊的代碼來說明你確實熟悉這個技術的底層實現。
2 數據庫調優方面。比如oracle，你可以用某個長SQL為例，講下你通過執行計划看到有哪些改進點，然后如何改進，這樣的例子不用多，2,3個即可，面試時估計面試官聽到其中一個以后就會認為你非常熟悉數據調優了。
3 JVM調優和如何通過設計模式改善代碼結構，在Java核心技術及面試指南里我已經提到了，這里就不展開了。
4 架構層面的調優方法，比如通過分庫分表，通過數據庫集群，或者通過緩存。
其實關於亮點的內容，我在Java Web輕量級開發面試教程里，也有詳細描述。這里想說的是，大家可以准備的亮點絕不止上述4個，大家可以從調優（比如通過分布式優化並發情況場景）和技術架構（比如SSM， 分布式消息隊列）上准備。再啰嗦一句，職位介紹里提到的技能點，比如Redis，大家還可以用熟悉底層實現代碼來作為“亮點”，比如介紹項目時，輕描淡寫地說句，我熟悉Redis底層代碼（當然也可以寫到簡歷上），然后等面試官來問時，動筆說下。
6 別讓面試官感覺你只會使用技術
按照上述的建議，只要你能力可以（哪怕可上可下），你通過技術面試的可能性就大大增加了。但面試時，如果你表現出如下的軟實力，比如在簡歷上項目描述部分寫上，或介紹項目時說出，那么面試官甚至會感覺你很優秀。
1 該項目的工期比較緊，我會合理安排時間，必要時，我會在項目經理安排下周末加班。（體現你的責任心）
2 這個項目里，用到了分布式組件技術，剛開始我對此不熟悉，但我會主動查資料，遇到問題，我會及時問架構師，解決問題后，我會主動在組內分享。（有責任心，學習能力強，有團隊合作意識，有分享精神）
3 遇到技術上或需求上的疑點或是我個人無法完成問題點，我會主動上報，不會坐等問題擴大。
4 在開發項目的過程中，通過學習，我慢慢掌握了Git+Ant+Jeninks的打包發布部署流程，現在，我會負責項目里的打包工作。或者說，在組內，我會每天觀察長SQL腳本和長Dubbo調用的情況，如果遇到問題，我會每天上報，然后大家一起解決問題。（不僅能完成本職工作，而且還能積極分擔項目組里的其它工作）
5 如果出現問題，我主動會到linux里通過xxx命令查看日志，然后排查問題。（不僅積極主動，而且掌握了排查問題的方法）
6 我會和測試人員一起，用xxx工具進行自動化測試，出現問題然后一起解決。（工作積極，而且掌握了測試等的技巧）
7 在項目里，我會用Sonar等工具掃描代碼，出現質量問題，我會和大家一起協商改掉。（具有代碼質量管理的意識，而且具有提升代碼質量的能力）
7 版權說明，總結，求推薦
本文歡迎轉載，轉載前請和本人說下，請全文轉載並用鏈接的方式指明原出處。
本文給出的准備項目描述和說辭的經驗，是根據本人以及其它多位資深技術面試官的經驗總結而來。如果大家感覺本文多少有幫助，請點擊下方的推薦按鈕，您的推薦是我寫博客的最大動力。如果大家在這方面有問題，可以通過評論問或私下給我發消息，一般我都會回。