你好呀，我是歪歪。
這期我想簡單的聊一個面試中出現頻率比較高的，但又沒有標準答案的面試題。
你在工作中遇到過印象深刻的困難是什麼，你怎麼克服的？
為什麼我想聊聊這個問題呢？
因為我發現這個問題經常出現在各個技術交流群中，大家聊到這個話題的時候大多都苦不堪言，紛紛表示不知道怎麼去回答這個問題。
或者說之前就沒有想過這樣的問題，突然一下被問起來，由於沒有準備，也是摸不著頭腦的樣子。
匆匆的回顧一下自己的職業生涯，發現天天寫的都是 crud，也沒覺得有什麼困難啊。
一時間，竟然想脫口而出：我覺得吧，也沒有啥特別大的困難，我做的就挺好的。
面試官聽了微微一笑：好了，那我們今天的面試就先到這裡，請回去等通知吧。
考的是什麼
你必須要知道正常情況下面試官在面試的過程中問的每一個問題，都一定是有他的目的。
比如面試官上來就要求候選人做個簡單的自我介紹，很多人說這個目的是為了在候選人自我介紹的時間內看一下他的簡歷。
也許在早幾年，要候選人自己帶著簡歷去面試的情況下，確實是這樣的。
但是現在來說，都是無紙化面試了，你的簡歷的電子版早就到面試官手上了。
正常來說，面試官會在面試之前已經看過你的簡歷了，不需要面試的時候藉著你自我介紹的時間，瀏覽簡歷。
我一般讓候選人自我介紹的時候，我是在認真的聽，我想要從他的自我介紹找挖掘到簡歷上沒有體現的東西，也是在尋找面試的切入點，如果自我介紹中有讓我感興趣的地方，我就會從這個地方開始，圍繞著簡歷往下問。
再比如，問你專案的時候：
說一下你最熟悉的專案。
是問你專案是幹啥的，業務場景有哪些嗎？
不是的。
問這個問題的目的是想知道你所熟悉的專案的架構是怎麼樣的，是單體服務還是拆了微服務，拆了哪些模組，每個服務大概多大的體量，它們之間是怎麼相互的，涉及到的技術棧有哪些。
知道了這些，面試官才能從中找到討論的點，從而展開技術面試。
至於專案是幹啥的，簡單說幾句，鋪墊一個背景就行了。
有的同學介紹專案的時候把領導在業務上給他畫的餅，又給面試官描述一遍。如果不是同一業務線的話，面試官是不會關心你的業務的。
你要知道，如果你要介紹業務場景的話，其目的必然是為了引出背後的一個比較複雜的技術解決方案。否則，面試官不會太感興趣，多說無益，反而佔用了面試的時長。
還不如拿出紙筆，在上面畫一下你們的服務互動，同時描述一下對應地方涉及到的技術棧。
再說這個問題：
你在工作中遇到過印象深刻的困難是什麼，你怎麼克服的？
有的同學說他不會回答，我分析了一下，不會回答的原因其實就是因為不知道面試官考察的是什麼方向。
所以只能給出一些諸如查詢慢了就加索引、熱點資料加快取、出了問題重啟了就好了...這類泛泛地回答，找不到什麼讓面試官眼前一亮的東西。
怎麼能答的閃亮一點呢？
一般來說，我認為這個題有兩個回答的方向。
第一個方向就是往技術的深度，對於技術的追求這個方向答。想看看你有沒有碰到過什麼棘手的技術問題，然後是怎麼定位，怎麼解決的。
第二個方向就是往主人翁意識，體現主觀能動性的方向答。面對一個專案或者領導給到的任務涉及到其他專案組、甚至其他部門的時候，自己是怎麼去推動的。
技術的深度
如果你往這個方法答，就得自己平時工作中多積累，多觀察相關的案例，然後記錄下來。
可以把觀察的目光放的長遠一點，不一定非得是自己所在的專案組遇到的問題，也可以是其他的專案組遇到的問題。
這裡就需要自己有一個情報收集的能力，和對於技術的敏感度。
一聽到這問題就應該要知道：這是一個好素材呀，可以深入瞭解一下。
這個問題都不一定是你解決的，但是你要清楚的知道來龍去脈，就可以包裝成自己的經歷。
面試官是察覺不出來的。
而且我一直認為，適度的包裝，也不算是面試造假。
當然了，這個方向你也可以去背。
但是不能純粹的背誦，得適當的去擴充套件。
比如我之前分享過一篇關於 Dubbo 呼叫超時的文章。
從最開始 Dubbo 呼叫超時的這個表象，分別從資料庫、GC、網路、鏈路追蹤等各個角度去分析了問題，且是一個循序漸進的過程。
你會發現大家對於超時這一類的問題的排查套路都無外乎這樣，層層遞進的排查，抽絲剝繭的尋找問題。
這個案例你就是可以自己拿去用的，套一個自己工作相關的業務場景。
我就不信了，你們介面呼叫沒出現過超時的情況？
網上這樣的文章很多很多，但是作者寫的只專注於面試問題的本身。
如果你想要把這個案例套過來自己用，那麼而這個問題能延伸出來的東西，你也必須得去研究。
比如前面這個文章裡面，為什麼要說“失敗策略是 failFast，快速失敗不會重試”？因為如果是failover，會預設重試，且超時時間是重試時間之和。所以，他告訴我們，這裡沒有重試，超時不是因為請求重試帶來的時間疊加導致的。
文章提到的 ElapsedFilter 過濾器，“超過 300 毫秒的介面耗時都會列印”，是作者公司自己擴充套件的 Filter，基於Dubbo 的 SPI 實現的，並不是 Dubbo 官方的自帶功能。所以，他才額外提了一句“ElapsedFilter是 Dubbo SPI 機制的（自定義）擴充套件點之一”。
作者用的 Druid 連線池，猜測連線長時間不被使用後都回收了，那麼關於 Druid 的配置檔案中的有關時間的配置，你是否知道且清楚其作用？
如果要觀察 GC 日誌，你是否大概知道應該配置什麼引數，是否知道應該關注的資訊是什麼？為什麼他這裡要提到安全點？安全點和 STW 的時間之間的關係又是什麼？
等等後面的一些關於容器的、Arthas工具使用的、網路抓包工具使用的相關技能和知識儲備。
當我們把這些知識單獨拎出來形成面試題的時候，也許你會覺得，為什麼你老是問我 MySQL 的知識、問我網路相關的知識、問我一些用不上的垃圾回收的知識？
問你，把你問的啞口無言不是目的。考察你知識的廣度，讓你學以致用才是目的。
重要的是把你學的一個個孤立的點，通過某種方式，串聯起來。
而“你在工作中遇到過印象深刻的困難是什麼”就是你把這些知識點串聯起來的一種方式。
另外，還有一個人盡皆知的面試小竅門。
回答問題的時候儘量有意識的引導面試官到自己熟悉的領域中來。
怎麼引導呢？
不可能別人問你：你給我說一下執行緒池吧？
你回答說：這多沒意思啊，我給你說一下 HashMap 吧。
面試官一定當時就覺得自己的頭大。
我們可以在這些開放的問題上就可以去引導面試官。
如果你對 kafak、RabbitMQ、RocketMQ 這一類技術瞭解的比較深入，又或者對於 Redis、MySQL 這一類儲存的技術學習的比較多，你準備這類問題的時候就可以多講這方面的原因。
比如如果讓我來講，我可能就會選擇回答一些由於 Dubbo 框帶來的技術問題，讓面試官進入到我熟悉的領域，讓他在這裡面和我展開博弈。
再或者說往 JVM 方向引導，反正大家學這東西，看的都是同一份資料，就看你記得多還是我記得多了。
又或者我們可以 battle 一下多執行緒領域相關的問題，但是現在多執行緒都爛大街了，我可能不太會去在這裡面和麵試官博弈太長時間。因為就算你回答的滴水不漏，面試官大多也會認為這只是需要掌握的基本技能而已，用的熟練，不足為奇，沒有閃光點。
總之一句話吧：如果你嚮往技術的深度這方面去回答，一定要言之有物，最終定位到的問題可以是一個很小的問題，比如配置的原因、網路的原因、框架的 bug，但是重點得體現出排查的過程。而排查問題的過程，有一定的方法論，提煉出來就好了。
對於這個問題，上策是加工一下自己的親身經歷，實實在在的有解決問題的經驗，只是如何把它包裝的高大上而已。
下策是包裝別人的經歷，要包的惟妙惟肖，以假亂真。
如果你真的很無奈要選下策，那麼我只能再送你一句話了：加入一些細節的描述，可以是點選工具的什麼按鈕、翻看了什麼類的原始碼、參照了某個大牛的部落格一類的。
能不能過，就看你的造化了。
主觀能動性
主觀能動性這方面其實我沒有什麼特別想要說的。
核心思想就是前面說的：主人翁意識。
你所負責的任務，是別人分配給你的。但是你就是這個任務的主人翁，你要想著怎麼去積極主動的去完成它。
舉個例子：
你本來只是一個寫著 crud 的快樂的程式設計師，每天等著領導分配任務，然後領任務寫程式碼。
突然有一天，領導給你說：小王啊，這邊有一個專案很著急，但是我這邊有更加緊急的事情要做，所以我把這個任務分配給你，你去全權負責一下吧。
你當時就懵逼了，敲鍵盤的手一下就不快樂了。
這意味著你不再是一個只寫程式碼的程式設計師了，你還是一個專案的負責人。
一個專案的負責人得統籌帷幄，去協調需求、產品、開發、測試、運維等各方面的資源。
而這事兒，你之前從來沒幹過。要命的是，這事還挺著急。
怎麼辦？
這不就是你在工作中遇到的印象深刻的困難嗎？
場景框架都給你了，你就按照你們公司的流程往裡面填內容就行了。
你是怎麼拆分任務的，怎麼組織評審會的，最後專案成功上線自己的收穫是什麼。
可以多講點從程式設計師視野看不到的東西。著重體現自己協調資源和跨部門合作時遇到的困難和自己的解決方案。
什麼，你說你沒有這個方面的經歷？
你就不能假設嗎？
你就不能觀察你們公司的一個專案週期的全過程嗎？
得發揮你的主觀能動性呀。
然後再說一下，如果你往這個方向去回答，大概率會遇到一個追問的問題：
如果讓你再來一次，你會怎麼處理的更好。
這玩意考的又是什麼？
考的就是你的覆盤的能力，考的就是有沒有對於專案進行復盤。
如果你回答說：由於是我第一次負責一個專案，並跟進了它一期需求的全過程，所以對我來說是一次非常寶貴的經歷，於是在專案上線之後我對其進行了一次覆盤，發現了其中還有一二三四點可以優化的地方...
我覺得基本上朝著這個方法回答就十拿九穩了。
你要說你不會覆盤，好的，沒救了，回去等通知吧。
總結
面試的時候對於這類開放性題目，其實並不是想象中的那麼好回答，處處都是暗流湧動。
所以一定要在面試前做好這類題目的準備，臨場發揮肯定是效果很一般的。
就拿我個人作為面試官的經歷來說，特別是三到五年工作經驗的朋友容易遇到這個問題。
校招生我肯定是不問這個問題的。三年以下的經驗還不夠豐富，回答起來也很難有什麼滿意的答案，所以我也不問。問這個還不如多問幾個技術問題，考察他的技術是否紮實。
還有，前面說的兩個方向，都得準備一下。
如果是前兩輪面試問題了，可以往技術的方法回答，因為這個時候一般都是在一線編碼的程式設計師充當技術面試官，他更願意在技術方面和你切磋。
如果是後幾輪面試，可以往主人翁意識的方向去回答，因為到後面的面試大多都是部門負責人一類的管理人員，已經很少在一線編碼了，他們更願意看到你除了技術之外的軟實力。
本文參與了 SegmentFault 思否徵文「如何“反殺”面試官？」，歡迎正在閱讀的你也加入。