面試準備的時候，你是否總覺得花費的時間過長？又或者有些面試題你明明瞭解過，但是面試的時候，給出的答案總是不那麼令人滿意。甚至，每次刷完面試題，你覺得答得很好，但是總也沒得到 Offer。
其實說白了，出現這些問題，很可能是因為你面試準備的時候，踩了一些坑卻不自知。
現在，作為一名資深面試官，我今天就和大家說說面試準備中 5 個最常見的坑。
坑1. 不看崗位職責和崗位要求
“崗位職責”和“崗位要求”是我們在看招聘職位的時候，經常見到的兩個資訊。不同的招聘平臺叫法不一樣，有的叫“工作內容”、“任職要求”等等。
在準備面試的時候，很多朋友從來不去仔細分析招聘 APP 和網站上想應聘崗位的崗位職責和崗位要求的內容 。
但是，崗位職責和崗位要求對我們們的面試準備是非常重要的。
崗位職責告訴了我們面試準備需要的知識維度，崗位要求則告知了我們面試準備的知識主線。這種維度與線條的結合，就形成了我們面試準備內容需要的大綱。
如果不去看崗位職責和崗位要求的內容，沒有形成精準的面試綱要，很可能會造成面試準備茫無目的，白白耗費很多時間成本。
比如，你想要面試高階 Java 開發。它的崗位職責：
1、負責xx系統的設計與開發工作。
2、解決大資料量不斷激增，海量服務呼叫面臨的壓力，助力業務飛速發展。
3、對系統高可用性、高併發能力、高擴充套件性解決方案的制定、跟蹤、落地。
它的崗位要求：
1、具備紮實的Java基礎，熟悉常用資料結構、JVM基本原理、併發程式設計等；
2、熟悉常用的中介軟體，如Dubbo、訊息佇列、流程引擎、規則引擎；
3、熟悉常用設計模式，掌握Spring、SpringBoot、MyBatis、SpirngMVC、Dubbo、VUE等技術；
4、熟悉Mysql，對事務，分庫分表，效能優化等資料庫的基本技能；
5、熟悉Tomcat、Jetty、Nginx等伺服器配置使用；
6、熟悉多種遠端通訊協議，熟悉訊息中介軟體、快取等技術；
7、做事積極主動，具有高度的責任感與團隊合作精神，有良好的溝通能力；
那麼我們就可以藉此形成一個自己的大綱：
你看，這樣是不是一下子就得到了我們需要準備的內容大綱了？
如果沒有這個大綱，你可能什麼都要關心，什麼都要考慮學習。比如，跑去學這個崗位沒必要的 ElasticSearch，跑去學沒必要的 Mysql MyISAM 原理等，都是很難很耗費精力的東西。
因此，只有構造出我們需要準備的面試大綱，我們才能有的放矢的準備面試。
坑2. 把面試準備當成了技術學習
前面我們們說了，可以根據崗位職責和要求去制定面試準備大綱。可是，在準備了大綱之後呢，又會有人不小心踏進一個新的陷阱——把面試準備當成了技術學習。
什麼意思呢？假設，我們們現在有個知識主線是需要學習訊息佇列的高可用的。好，有了這個知識主線後，我們就需要選擇一個訊息佇列去針對性學習，比如選的是 Kafka。
關於 Kafka 的高可用知識點非常多。其中，在 Kafka 的 Consumer 的性質中，有一個 Rebalance 特性是最容易被考到的。那麼，為了應對面試，我們們自然是要查詢資料，去了解和學習這個 Rebalance 特性。
問題來了，對這個 Rebalance 特性要學到什麼程度呢？
當然是根據應聘的職位而定。
如果你應聘的是高階開發，我們們只需要瞭解到 Rebalance 是在什麼情況下會發生，Rebalance 的發生會引發一些什麼問題即可。
如果你是應聘的架構師，那麼就需要更深入的學習 Rebalance 特性相關細節，比如 Consumer Coordinator 具體的分配機制等問題。
所以，面試準備和技術學習不一樣，一定要根據我們們應聘的職位目標來準備。目標不一樣，學習的深入程度不一樣。不能像技術學習那樣，不管不顧的去挖機制、摳細節，平白無故浪費我們們寶貴的時間和精力。
坑3. 學習時不考慮場景
面試準備裡，最常見的一個錯誤就是：在看面試題時，直接就是背答案。
這招在前幾年還可以，但是在最近幾年，網際網路行業內卷如此嚴重的時代，已經不保險了。因為問的方法已經變化了，要求的答案也變化了。
比如，以前經常有人會問：Redis 的優缺點各是什麼？
現在已經變成：你們會在專案中什麼地方用到 Redis ，為什麼？
大家可以看到了，本質上，其實都是在問你 Redis 的優缺點。但是，一個只是需要找一些資料，把優缺點背下來回答就行；另一個就要結合到實際場景、實際專案，才能很好的回答出問題。
像上面問的，為什麼會在專案中用到 Redis，你在面試準備的時候，就一定要把 Redis 適合快取的優點和實際專案結合起來形成自己的答案。
比如結合電商系統裡的購物車場景來回答一下。
購物車有什麼特點？其最大的特點就是操作頻繁。因為使用者購物的時候，購物車往往會隨意新增刪除商品，也會經常瀏覽購物車中的商品。
其次，購物車還需要持久化，因為很多人拿購物車當一個臨時存放處，存放他們想買又暫時不會購買的商品。
所以，購物車在技術上，就表現為兩個特點：
- 讀寫頻繁
- 需要持久化不丟資料
如果用資料庫做持久化呢？往往支撐不了購物車這個量級的讀寫請求，如果用臨時快取呢，又沒法保證不丟資料。
所以，我們此時就引入了 Redis 。Redis 的優點是什麼？我們們看看傳統的答案：
- 讀寫效能優異， Redis 能讀的速度是 110000次/S，寫的速度是 81000次/S。
- 支援資料持久化，支援 AOF 和 RDB 兩種持久化方式。
- 資料結構豐富，除了支援 string 型別的 value 外還支援 hash、set、zset、list 等資料結構。
- 支援主從複製，主機會自動將資料同步到從機，可以進行讀寫分離。
- 支援事務，Redis 的所有操作都是原子性的，同時 Redis 還支援對幾個操作合併後的原子性執行。
這其中，1 到 4 的特點正是我們在購物車需要的技術特點，所以，用 Redis 是物盡其用，正當其時。
好，回到我們問的“你們為什麼會在專案中用到 Redis”這個問題上，我們可以這樣回答：
我們做了一套電商系統，其中有個購物車業務，既需要高併發的讀寫，又需要持久化資料。而 Redis 的特點是 balabala……（列舉出上面講的特點）
這樣的回答，我想任何面試官，應該也挑不出毛病來。
但是，如果你在面試準備的時候沒有結合實際場景，你就不太可能回答出這種能把業務特點和 Redis 相關優點結合的答案來。
所以，如今的面試學習，大家一定要用答案去結合場景，形成自己的回答，只有這樣才能捲過別人。
坑4. 不回顧和總結自己在專案中的職責和貢獻
有些朋友在面試準備時，往往忘記回顧和總結自己在專案中的職責和貢獻。這種疏忽，可能會讓你在和麵試官討論自己的真實專案經歷時，溝通的不那麼順暢與準確，從而影響面試的結果。
這種負面的影響，完全可以通過提前的小小準備，就能被我們排除掉的。為此，我們又何樂而不為呢？
在回顧總結自己的職責貢獻時，我們需要照顧到以下幾點：
1. 自己對專案業務的深刻理解
需要知道，大部分公司是很重視程式設計師對業務的理解程度的。因為在業務驅動的專案裡，經驗所示，往往一個程式設計師對業務理解的越深刻全面，那麼他在技術落地時就越穩定可靠。
所以，我們們一定要給面試官展現出我們對業務的深刻理解。
2. 自己對專案的技術特點的總結
無論是面試還是在實際工作裡，一位主觀能動性強的同事，是極其受歡迎的。
比如在面試的時候，雖然你只負責 XX 系統其中的某些功能，但是你卻能說出：
我做過的 XX 系統技術特點是：安全性要求極高，事務關聯緊密，可擴充套件性被放在極為重要的地位……
這種回答，妥妥的表現出了你在全面且主動地去學習和了解你參與的專案，並且對專案的技術特點有過自己的理解和總結。
3. 自己對專案中技術問題的反思
在面試中，有一類問題是常常會被問到的：
你在專案中遇到過哪些技術問題？你是怎麼解決的？
像這類問題，面試官目的是想看看你對做過的專案裡，曾經用到的技術是否理解到位了。同時，還能判斷出來你專案經歷的真實性。
比如，你在支付專案，轉賬的高吞吐量是如何解決的？熱點賬戶如何解決？
像這些問題，如果回答不好，很影響面試官對你的真實水平的評估，要是認為你的簡歷有些造假的成分，那就非常麻煩了。
所以，我們們面試準備時，要考慮到在我們負責的專案裡，一定會有一些技術難題，業務難題曾經困擾過我們，我們需要把他們挖掘出來，找到解決方案，然後放到我們的面試準備內容裡，以便後面和麵試官交流探討。
坑5. 不提前找一些公司面試作為練手目標
我們面試，總是有些心儀的公司想要去的。但是，不少人會在準備完面試之後，直接就投簡歷到了他心儀的公司，然後就去這家公司進行面試了。卻從沒有想過先找幾家不那麼心儀的公司面試練一下手。
剛面試準備完就去心儀公司面試，經常會涼涼。
涼的主要原因就是：好久沒面試了，情緒緊張導致會的答不出來；一些隨便應變的技巧還沒掌握好；面試實戰少，回答問題囉裡囉嗦描述不清……
解決這些問題也沒什麼好辦法，就是要練。
所以建議不要上來就去心儀公司直接面試，先去找非大廠、面試沒那麼難的公司練練手。
這些公司的面試實戰，既可以讓我們逐漸適應面試的氛圍和節奏，也能通過實戰檢驗我們的面試準備是否充分，還能通過實戰掌握好那些溝通和應變技巧。
等練的差不多了，甚至是能拿到幾個 Offer 了，再去心儀公司去面試，這樣成功率就能高很多。
以上，就是面試準備中大家最容易踏入的五個坑。
很多時候，並不是我們們水平不夠，也不是我們們沒去好好準備，只是還沒找到一套方法。如果是因為這些而沒有拿到滿意的 Offer，那就太可惜了。
所以，我總結了以上經驗分享給大家，希望對大家有點幫助。
你好，我是四猿外。
一家上市公司的技術總監，管理的技術團隊一百餘人。
我從一名非計算機專業的畢業生，轉行到程式設計師，一路打拼，一路成長。
我會把自己的成長故事寫成文章，把枯燥的技術文章寫成故事。
歡迎關注我的公眾號，關注後可以領取高併發、演算法學習資料。
