俗話說，錢、相處的人和工作內容其中有兩條讓你不滿意，你就可以考慮換工作了（不知道這是誰說的，如果說的不對就讓俗話 說來背鍋）。遵循這個判斷標準，我也就動了換工作的心思。給幾家自己覺得還不錯的公司投了簡歷，目前只有一家給了面試機會，可惜的是面試失敗了。想了想，後面肯定還是會有各種面試失敗的經歷，所以就打算寫個面試失敗的系列小記，權當自己的面試總結。

雖然是在職找工作，但是思想上還是不能懈怠。坦率的講，這次面試我並沒有很認真的對待，更多的是想通過這次面試來試試水，甚至還抱有萬一我就這麼面試上了的僥倖心理（很明顯，現實二話不說給了我一個嘴巴子）。但現在想想還是自己不夠成熟，既然是打算參加的面試，還是應該認真對待，這是對招聘方的尊重，更是對自己的尊重（再怎麼不濟你也要對得起面試的公交地鐵錢）。所以該準備的還是得好好準備一下，面試時的自我介紹還是應該打個草稿，常見的面試題還是不能少刷。

我想面試的經過其實都大同小異，去到面試公司，前臺給了一個基本的資訊單子讓填一下。單子上有幾個地方讓我覺得還是有意思，像什麼“你最大的優點和缺點是什麼”、“你為什麼認為你能勝任這份工作”、“你的職業規劃是怎樣的”。雖然這都是常見的問題，臨時想幾個答案也不算難事，但如果有充分準備過填表的時候想都不用想。臨時想不見得會打擊你信心，但想都不用想，我覺得對我來說會增加我的信心。

關於這幾個小問題，我記得我當時寫的回答分別是：

問題1：最大的優點是樂觀積極，最大的缺點是不善於與陌生人帶有較強目的性的交流；

問題2：掌握所需的技術和經驗；

問題3：從基礎的程式碼編寫到架構搭建與設計，成為架構師；

雖不忍直視，但人還是得面對自己。

參考了一下百度的結果，結合一下自身的實際情況，重寫編寫幾個答案試試：

問題1：優點：樂觀獨立，執行力較強，熱愛學習，對自己有較高要求；缺點：與對工作不負責任或對自己面對問題沒有自己思考過的人無法保持平和心態交流；

問題2：1）熟練掌握崗位所必備的知識和技能；2）有過*年的同崗位工作經驗；3）有過*次完整的同類型的專案開發工作經驗；

問題3：在現有基礎上，通過自身的努力與公司所提供的鍛鍊機會，不斷提高技術業務能力已達到高階工程師的水平，結合自身與企業的發展向專案主管和架構師的方向努力。

嗯，不算完美，但我覺得比較符合自己現有的認知水平。另外填表的時候也有現有薪資欄，我當時填的略微有些虛高，其實現在想想也沒有必要，就算想填得虛高一些是不是可以按薪資結構來虛高填寫，比如基本工資+績效的模式來填寫呢？

這次面試比較讓我意外的是沒有筆試題，試試水的目的完成度也降低了不少。先是專案架構師的面試，結束之後是人事面試。

架構師主要問了三個問題（具體問題記不清了，智慧描述一下大概的意思）：

問題1：除了基礎的增刪查操作，你在專案中還用到了哪些redis的操作？

問題2：給你一個需要執行十幾秒的sql，你會怎麼優化？

問題3：你所經歷的專案中你覺得那個專案你成長更大？

這三個問題當時的回答想著想想也挺粗糙的，關於redis我只是講了一下通過lua指令碼來實現了一下庫存控制的，隨後面試官又追問給你一個雙十一搶購的功能你怎麼完成，我的回答也不太嚴謹（而且我估計我的回答給面試官的感覺是我並沒有實際的專案經驗）。關於sql優化，我回答的也非常簡陋，而且我開頭就提了一句能不能通過業務流程的優化來實現，面試官一臉不高興，說讓不用考慮業務流程了，-_-||，後續的回答也比較空泛。所謂的專案成長當時也是即興發揮了一下，顯得也沒有什麼條理。

整個面試過程，我覺得我有一個很不好的習慣——嘴巴比腦子快，可能是急於表現自己，往往沒想清楚就開始表達，效果只能是適得其反。重新整理一下這幾個面試問題的回答：

問題一：因為專案中會用到redis，所以面試官主要還是考察我對redis的熟練程度，再回答的話我會從一下幾個點來說：1）利用redis來做全域性鎖，利用redis的單執行緒特性，來實現一些全域性鎖的業務需求，比如防重校驗；2）利用redis支援lua指令碼，在指令碼中實現redis原子性的增減，用來控制搶購活動中的庫存；3）利用redis的list資料結構的特性來實現一個訊息佇列的功能；

關於追問的搶購活動實現，我想更多的是考慮實際的專案經驗，關鍵點主要是通過redis來減少對資料庫的操作：

搶購業務是當下網際網路應用的常見業務場景，主要面臨的挑戰就是瞬時的高併發。但搶購業務有一個特點就是庫存有限，也就是說大部分業務請求最終都會失敗。將整個搶購流程做一個拆分，先下單，後支付。因為最終能成交的只會是少數，所以我們要做的主要是對請求進行從前到後的一步步的過濾。比如前端的頁面靜態化、js控制提交的次數減少使用者的請求，當用戶獲得了購買資格後才進入支付頁面支付；網關係統對下單做相應限流，比如根據壓測結果設定一個閾值，超過閾值則直接拒絕請求；後端業務系統處理下單請求時對使用者做相應的防重，通過將使用者id設定為key，保證同一使用者的多次請求只會有一個請求被處理；將產品庫存數量增減交給redis來處理，編寫lua指令碼判斷庫存數與使用者購買數的業務邏輯處理，保證庫存數的操作原子性，當庫存滿足使用者購買數量放回交易成功，前端跳轉至支付頁，使用者進行後續的支付。後續的支付業務也會有相應的業務邏輯，比如在限定時間內未支付或者支付失敗，則歸還相應庫存數量。

問題二：主要還是sql優化的一些問題，只是問題比較開放，沒有具體到像怎麼保證索引的命中：

sql優化也是日常工作中比較難的一部分，首先我會自己檢視一下sql語句，看看sql語句是不是有優化的空間，比如where條件中使用or、is not null、is null、<>、in、not in以及自動錶達式等等導致的全表掃描，儘量去掉不必要的distinct、order by等操作，以及關聯查詢時是否是小表在前大表在後等等基礎的排查；如果沒有明顯的問題我會跑一下執行計劃看看有沒有什麼建議，有時候隨著資料的增加表的索引需要重新整理，我們可以對錶做一下runstats操作；另外如果這個sql頻繁使用，也可考慮將其改為儲存過程，加快資料庫對sql語句的編譯過程；還有就是導致sql慢的主要原因還是資料量太大的原因，是不是考慮將歷史資料做一些遷移或者做一些分表拆表；當然針對查詢操作也可以考慮使用redis，相關的查詢結果可以存放在redis上；最後也許會考慮一下有沒有可能通過修改部分業務邏輯來達到相應目的。

問題三：這個問題如果換成你在專案中遇到過哪些問題會不會更好回答一些呢，畢竟只有經歷過磨難才能成長，遇到的問題多那麼成長就越多了。

其實每個專案都會讓我得到很多的成長，比如不同的專案可能使用不同的技術方案，也就能學習到不同的知識。xx專案使用的是傳統單體架構、xx專案使用的是分散式架構，xx專案使用的是微服務架構，對比架構可以讓我瞭解到分散式架構解決了網站高併發的問題，以及微服務架構對複雜業務的拆分所帶來業務複雜的降低等等。xx專案中遇到了諸如xx問題，讓我學習到了xx；xx專案中需要使用xx語言（中介軟體），迫使我在xx時間內掌握了xx語言（中介軟體）；雖然做專案很累，但是能讓我有更多的收穫和成長，這是讓人非常開心的事。

還好就問了我幾個問題，不然我都堅持不了寫不下去了，功力不夠還是的持續修煉啊！

於我而言這次面試更像是一盆澆醒我僥倖心理的冷水，凡事都應該認真對待，尤其是自己決定要做的事，既然要參加面試，就應該有一個求職者應有的心態和準備。後續也許還會有面試失敗的經歷，只是希望這種經歷少一點。