作者熊燚（四火），曾先后任職于華為，亞馬遜。

現任 Oracle首席軟件工程師，負責研發云基礎設施的分布式工作流引擎。除了帶團隊，也擔任公司招聘環節的 Bartender 角色。

很久以前就想談談這個話題了，但是最近才有了足夠的動機。因為從最近參加的很多 debrief 來看，我認為身邊大多數的軟件工程師面試中，在通過技術問題來考察候選人這方面，很多都做得不夠好。

首先，我要明確的是，這個問題，指的是技術面試中俗稱的 “主要問題”，具體來說，就是面試官會拿出一個問題和候選人討論，并由此開始雙方的互相溝通和問題發散來達到考察的目的，因此，這個 “問題”，從某種角度說，更像一個 “話題”。這個過程通常在每輪面試中會持續幾十分鐘。

其次，作為一個 disclaimer，我想說，以下內容來自于我的認識，并且是針對于技術面試這一個狹窄范圍內的認識，自然帶有主觀的傾向性和認知的局限性，它并不是來自任何公司或組織的標準。

下面我就來嘗試把這個問題講清楚、講透徹。我認為這并不是一件容易的事情，如果你想了解更多，可以閱讀我的專欄《技術面試官識人手冊》。

當然，如果你有不同的看法，也歡迎和我一起討論。

典型案例

先舉個典型的例子，這里面包含了若干個值得商榷的方面，你可以看看是不是似曾相識：

和候選人談完項目和經歷后，面試還有40分鐘…

于是面試官問：你能否實現一個 LRU 隊列？

候選人想了一下，就開始做題了，也就是在白板上大寫特寫。

面試官也就開始忙自己的事兒。40分鐘后，候選人寫了一白板，但是顯然，他在這過程中遇到了一些困難，最后雖然實現了，但代碼寫得有些復雜，也遺漏了兩、三個重要的 corner case。

于是面試后，面試官在評語中寫道，“候選人能力一般，算法題實現起來磕磕絆絆，最后的代碼偏臃腫，而且有明顯的 bug”。

在往下閱讀以前，請你想一想，這樣的面試形式有哪些值得商榷的地方？

技術面試的目的

好，我先賣個關子，先不回答上面的問題，而是先談一談，對于軟件工程師候選人來說，我們為什么要進行這樣的技術面試。

技術能力方面

通常不同輪次的面試，會考察不同的技術點，這對于不同的團隊和職位，是不一樣的。

舉例來說，對于某業務平臺團隊的一個高級工程師職位，五輪面試中，一輪考察項目和經驗，一輪考察系統設計，兩輪考察具體問題的解決，特別包括算法和數據結構，還有一輪考察面向對象設計等其它內容，這其中，后三輪都包括白板編碼的考察。

對于一個有經驗的工程師候選人來說，我認為這就是一個比較立體、綜合，也是一種比較合理的技術考察點的劃分方式。并且，這五輪中有四輪都會花費大量的時間，通過我今天將談到的技術問題，來對候選人進行技術能力方面的評估。

這里，有幾個常見的技術方面的考察項：

1.分析問題，整理需求的能力

問題在一開始可能很模糊，但是優秀的且有經驗的工程師可以識別出核心的訴求來，這個 “識別” 的能力，下文我還會詳述。這里的訴求可能有多個，但是考慮到時間的關系，面試過程中往往只會從某個角度覆蓋其中一兩個。

2.根據需求來設計系統的能力

這里既包括功能性需求，又包括非功能性需求，前者是必須要涉及到的，但是后者也經常也放在一起考量。其實這一點可大可小，它未必一定指系統設計中，功能是否得到實現，并且這個過程中，可能會涉及到系統的擴展性、可用性、一致性等等方面。

3.將核心邏輯實現的能力

如今，考察比重容易被高估的算法和數據結構就大體上屬于這一部分。它也有功能和非功能兩個角度—功能上算法能否實現需求，非功能上算法是否具備足夠的性能，編碼是否遵循最佳實踐，代碼是否具備良好的可擴展性等等。而編碼能力，指的是在思路達成一致以后，核心邏輯能不能落到紙面（代碼）上。畢竟，“空談誤國，實戰興邦”。

4.經驗和其它工程能力

這部分相對更靈活。比如對測試能力的考察，即可以做怎樣的測試來實現對于功能需求和非功能需求正確性的保證。對于特定的團隊和項目來說，有時候會特別專注于特定的技術能力，比如前端的團隊，是需要考察前端的基礎技能的。

考慮到時間和覆蓋面、覆蓋深度的權衡，上面這四點有時候不能在一輪面試中完全覆蓋，往往也會包括三點。比如，系統設計的面試可以著重覆蓋 1、2、4 點，而編碼為主的面試可以著重覆蓋 1、3、4 點。

非技術能力方面

和技術能力考察不同的是，非技術能力考察在不同面試官中的特異性更大，換言之，每個人的角度和標準都可能不相同。但我覺得下面這幾條是特別重要，因而必須要覆蓋到的：

1.溝通合作的能力

如果不計時間成本，最理想的面試是什么？其實就是一起工作。工作中才會有足夠多必要的溝通，無論是正面的品質還是負面的問題都會無所遁形。可是面試的時間有限，我們沒有辦法實現真正的工作氛圍，但依然可以模擬工作中一起考察、分析和解決問題的過程，而這個過程，就是要通過 “溝通” 串起來的。溝通是一個大的話題，具體的考察項有很多，比如，能不能接受建議？能不能討論想法？有些候選人一旦進入自己的思考模式就聽不進別的話了，于是一個點要反復強調幾遍；而有的則是缺少 backbone，稍微追問一下，也不思考，就立馬改變主意。

2.熱情和興趣

熱情和興趣的影響是巨大的，都說興趣是最好的老師，這部分是很難 “教出來” 的。對于初級工程師來說更是如此。熱情和興趣不但會影響到他/她自己的未來發展，也會影響到整個團隊的氛圍。

3.學習能力

學習能力很大程度決定了候選人在新崗位上進步的潛力。同樣的基礎和基本的問題解決能力，有的候選人能 “一點就透”，觸類旁通，這在一定程度上就反映了學習能力。毫無疑問，軟件工程師每天都在面對新問題，入職以后就會發現，不止問題是新的，代碼是新的，類庫是新的，工具是新的，在成熟到能夠有一定產出之前，這一步一定是學習。

技術能力和非技術能力，哪個更占主導？

事實上，這二者都很重要，并且二者各自又具備不同的特點。當然相對來說，非技術能力更加難以提高，因而這方面的問題要更加引起重視。比方說，要讓一個對于軟件領域缺乏熱情和興趣的候選人，在入職以后改頭換面，是幾乎不可能的一件事情。

其它方面

上面說的是技術面試中對于 “能力” 的考察。其實，還有一些考察項，嚴格來說并不能算是 “能力”，因此我就沒有歸類在上面，也不是本文的重點，但這并不是說它們不重要。

比如，候選人是否具備正直的品格。在 OCI，debrief 的結果，通常有 hire 和 no hire 兩種，但是有一種情況，可以歸結到一個特殊的 “never hire” 里面去，這樣的候選人沒有面試冷凍期，不會有職位和級別的討論，就是一個 “永不考慮” 聘用——這就是品格問題。品格問題會導致 never hire 的出現，比如候選人對當前的所在職位說謊了。

再比如，和團隊的契合程度。不同的團隊，接納候選人的程度和要求都是不一樣的。一個典型的例子是，有時候我們發現，有的候選人在投票的邊界線上，即本身是具備相當的潛力的，但是由于相對缺乏領域經驗，且某些方面顯示出方法明顯不得要領。如果團隊中有成熟、有經驗的工程師可以帶著，且團隊有一定的空間允許他花更長的時間學習和成長，那么最后的結論就是 hire，否則就是 no hire。你也可以看出，很多時候這樣的決定都不是非黑即白的，影響的因素是多方面的。

再再比如，性格不兼容導致的風險。我遇到過一例，候選人在面試過程中，在多輪面試中都表現出高傲和自滿的個性來。于是這成為了一個擔心招聘進來以后，風險過高的重要方面。于是最后我們放棄了這個候選人，盡管這個候選人的技術方面是沒有問題的。有人可能會說，聰明人都是有個性的。但其實 “有個性” 和 “難相處” 卻有著微妙的差別，而且再包容的團隊，也有自己的底線。我們當然不希望錯過優秀的人才，但是這并不是不計代價的。

從這幾個方面也能看出，這些 “非能力” 的考察項，往往具備著或 0 或 1 的 “red flag” 的特點。面試官一般不會花心思在這部分的考察上，但如果發現這方面的問題，且經過了明確。那結果往往就會是一個明確的否決票，而這個否決票是和級別、職位無關的。

回看那個案例

講完技術面試的目的，再來回看那個案例。那個案例中，所記敘的面試過程，對于技術面試的技術能力和非技術能力的考察，是否有覆蓋呢？

我們不妨一條一條看吧：

技術能力方面：

1.分析問題，整理需求的能力

這一條考察的程度明顯是不夠的，給出的問題，是一個明確的、具體的算法題，也就是要實現一個 LRU 隊列。也許這其中存在著問題分析和需求整理的空間，但對于具體算法題來說，這個空間顯然并不大，而且候選人悶頭就寫了，這方面無從考察。對于一個初級工程師的面試來說可能還好一些，我通常沒有微詞；可對于一個要去面試一個經驗豐富的工程師，我是很不贊成純算法題面試的，而這就是其中的一個重要原因。

2.根據需求來設計系統的能力

這一點的覆蓋基本為 0。上來就寫代碼了，不清楚思考的過程，也更談不上什么系統設計了。

3.將核心邏輯實現的能力

這條確實是這種面試方式能夠覆蓋的部分，因為整個過程，就是候選人思考并編碼實現的過程，只不過，面試官能得到的只有一個 “結果”，而非整個 “過程”。這樣的數據，能反映出來在核心邏輯實現方面的價值，就要大打折扣了。

4.經驗和其它工程能力

也許能夠從代碼的實現上獲知一部分，但這一條考察的程度也顯然是很不夠的。

?

再來看非技術能力方面：

1.溝通合作的能力

這是最大的問題，因為這方面是遠遠不足的，整個過程沒有溝通，沒有合作，只有默默地做題。

2.熱情和興趣

過程中很難從這個角度獲取候選人在熱情和興趣方面足夠的信息。

3.學習能力

同上。

也就是說，除了 “將核心邏輯實現的能力” 可能還勉強過得去，這樣的面試方式，并無法全面、合理地考察候選人作為軟件工程師的綜合素質。

事實上，如果你聯想實際工作。如果你的團隊中有這樣一個工程師，拿到一句簡單的需求，不確認問題，不溝通設計，不討論方案，直接就開始埋頭苦干，就算能寫出可以工作的代碼來，這是不是依然是一件無比恐怖的事情？

顯然，我們的面試要盡可能避免這樣的事情在真實世界中發生。

我們要找的是軟件工程師，不是只會刷題編碼者。

這也是我把這個案例，放在開頭，作為反面案例的原因之一。

等等，“之一”！難道還有別的原因？

是的，這還沒完，這個案例還有著其它弊端，我想再賣個關子——而現在，你可以想一想，再往下看。

怎樣的問題才是 “好” 問題？

終于要正面回答標題中的問題了，到底怎樣的問題才能真正稱得上 “好” 問題呢？

下面是我認為最重要的幾條衡量標準。

從模糊到清晰

首先，這個問題在一開始要足夠模糊，以便讓候選人可以逐層遞進，逐步細化，尋根究底。這個過程，其實就是將 “具體問題” 經過分析、歸納、思考、抽象并將其映射成為一個 “軟件問題” 的過程。

在問題變得清晰的過程中，理想的情況是，候選人可以表現出主動性，即候選人可以在多數情況下引領討論的思路，而不是面試官。面試官需要順著候選人的思路，逐步框定下問題的討論范疇，并明確到其核心實現是確實可以用軟件的辦法實現的。

在這樣的狀態下，候選人可以以自然的狀態，具備自由度發揮自己的能力。從這個過程中，可以觀察得到太多候選人的不同角度的特質了。通過這種方式，也可以很大程度避免了已經知道 “標準答案” 的面試官，由于思路的局限性，而給面試施加的源自于主觀偏好的影響。

這就好像是開放世界的 RPG 游戲，有多個不同的路徑都可以完成任務，玩家可以決策并決定主角的走向，但這一切始終還要在游戲設計者的掌控之內。這當然是理想狀態，有時候會有偏差，但我們朝著這個方向努力。

這也對面試官駕馭不同的狀況有著很高的要求，畢竟，面試官要對這個問題前前后后足夠的熟悉，以便應對各種不同的細化場景。有一個常見的方式，是可以從一個自己已經足夠熟悉的問題開始，比如自己曾經多年工作涉及的某類系統。

我來舉一個具體例子。比如，有這樣一個問題：

怎樣設計一個流量控制系統？

這就是一個模糊到沒法再模糊的問題了。不知你會不會產生下面這樣的問題：

• 什么系統需要流量控制？
• 現在的流量是多少？
• 需要支持到什么時間精度？
• 流量控制的規則怎么定義？
• 超過流量的請求怎么處理？
• ……

其實，這些都或多或少是需要面試官和候選人一起逐步思考、分析和明確的。在這個過程中，可以考察的內容太多太多了。

事實上，針對不同程度的候選人，上述這個問題給出的最原始的模糊程度是不一樣的，問題越是模糊，這部分對于候選人的要求也就越高。對于一個工作十多年的，有著多年系統設計經驗的工程師來說，上面這些問題大致都應該是他/她能夠主動提問，或是主動引領明確的。

值得一提的是，理想的問題最好還有一些隱藏的 “坑”，能否把這些坑識別出來，也是對于工程能力方面，一個很好的小的考察點。

比方說，優秀的候選人應該想到，流量控制可以基于絕對時間窗口，或是相對時間窗口來進行的，但是要真正保護系統，相對時間窗口才是最理想的。當然在實現難度上，相對時間窗口，往往會更難一些。

而對于一個沒有工作經驗，并即將研究生畢業的候選人來說，問這樣一個模糊的問題，往往帶來了過大的難度，不但不容易推進面試進程，還可能給候選人帶來沮喪的心理。我們不希望看到，候選人拿到問題后就懵了，如果發現候選人推進有困難，面試官需要介入并幫助。

因此根據候選人的程度，這需要面試官主動回答這些問題，或是直接縮小或明確問題的范疇，當這個問題的范疇縮到最小時，這可以是一個直接存在多種解法的算法題。

極端地說，這個問題可以一直縮小到這樣的程度：

假定說有這樣一個 API，名字叫做 isAllowed，這個 API 在系統每次收到請求的時候就調用，傳入的是請求對象，傳出 boolean 值表示是否允許這次調用——如果最近一分鐘內調用次數小于 10000 次就允許，反之則不允許。你能否將這個 API 實現出來？

你看，這只是一個將問題明確、細化和分解的過程，并沒有涉及到實際實現代碼該用的算法。但是，上面提的那些問題，要么都通過這個例子明確了，要么都給出具體數字了，這本身，就將一個模糊的問題，降低難度明確為一個具體的算法問題了。

不止一個解

前面一步已經談到了有不同的方式可將模糊的 “實際問題” 映射到了一個可解的 “軟件問題”，那么現在，這個 “軟件問題” 依然沒有標準答案。可能有幾個參考答案，它們互相比較起來各有優劣。大多數情況下，候選人的思路，都在這幾個參考答案的思路之中，但有時也能看到特立獨行的新奇思路。

如同前一步所說的那樣，對于不同級別的軟件工程師職位來說，需求分析、系統設計等等這些方面的要求可能有著很大的差別；但是在這一步，對于數據結構和算法這樣的基礎能力，卻是接近的。

對于這里談到的流量控的算法來說，實現方式是有很多種的，代碼復雜程度，控制精度，時間復雜度和空間復雜度等等都有著非常大的區別。當然此時涉及到的，已經基本只是算法層面的話題了。

無論是從實際問題細化到軟件問題，還是求解這個軟件問題，都存在著多條通往羅馬的道路，看起來很美好，但這樣的問題設計和面試把控并不容易。

但既然大家都是軟件工程師，是未來有可能一起工作的工程師，面試官的能力可能就和候選人接近，于是，為了保證面試的效果，就一定要精心準備這樣的問題，而不能指望隨機和臨場想出來一個 “好” 的問題提問。

圍繞問題的解決要完整

這個問題的分析、討論和解答過程要完整。對，其實這一點說的已經不是問題本身了，而是攻克這個問題的過程了。

這指的是整個過程要努力讓候選人能夠抵達 “踮踮腳能夠到” 的難度，并且能夠完成從確認、分析、討論、編碼、驗證和改進等一個過程。這讓整個面試顯得完整，同時帶來了這樣兩大好處：

對于面試官來講，這樣一個完整的過程，可以更全面地考察候選人，避免陷入視角過窄和一葉障目的情境。同時，“踮踮腳能夠到” 的難度，又可以給整個考察的進程具備較為合理的預期。

對于候選人來講，心態可以得到一定程度的平復，不沮喪，能夠 “完整地” 面試完一輪，能夠收獲信心。別忘了，面試是雙向的，給候選人一個良好的印象是很重要的。

在候選人能夠經過思考而快速推進問題解決進展的時候，要讓出主動權，以被動回答和鼓勵為主；但在候選人卡殼的時候，要奪回主動權，及時給出提示和引導。

在落到數據結構和算法上面的時候，極少有候選人能夠在敘述思路的時候直接給出最優解的。這時候，如果時間充裕，特別是在候選人進展非常順利的時候，可以不斷提示、追問以要求 “代碼前優化”，一步一步優化到他/她的問題解決的能力邊界，這就是其中的一個探尋其 “踮踮腳能夠到” 的這個問題解決能力之邊界的一個辦法。

但這個過程的前提是，一定要給編碼留足時間。當然，如果候選人不能在限定時間內給出清晰的優化后思路，那不妨就退一步到原先那個算法角度不那么 “好”，但是思路清晰的解法上，并落實到代碼。

有些時候，由于前面的過程磕磕絆絆，時間剩下不多了，依然只有時間復雜度較高的 brute force 的解法，那么將這個解法實現了，其實也是一個不錯的選擇。有時候時間實在比較緊張，可以要求實現一部分核心代碼，這些都比由于時間太短而代碼寫了一半匆匆收尾要好得多。我的經驗是，在討論充分，思路清晰的情況下，代碼完成的時間，一般只需要 5 到 15 分鐘，這樣的代碼量對于面試來說是比較合理的。

當然，相較而言，一種更為糟糕的結果是，一直到最后，討論的深度依然離編碼尚遠，甚至依然停留在一個很高的泛泛而談的層面。

如果在編碼完成之后，尚有時間，優秀的候選人會拿實際的例子去驗證代碼的正確性。而面試官也可以和候選人討論 “代碼后優化”，比如以下的問題：

• 你能否進一步優化算法以提高時間/空間復雜度？
• 如果是工業級別的代碼，你覺得代碼還有哪些問題？
• 你該怎樣去設計測試，來保證這段代碼的正確性 ？

對考察項的覆蓋兼有深度和廣度

這個問題要能夠考察前文所述的技術能力和非技術能力。

這里說的覆蓋，不一定要全部覆蓋，但是要覆蓋其中的大部分，并且對于每一個考察項要具備一定的考察深度。我見到過不少其它的面試風格，但我認為這樣就著一個模糊的主要問題（話題）逐步展開的方式是最好的。因為它可以兼具廣度和深度的平衡。具體來說：

面試很容易走向的一個極端就是考慮廣度，但缺乏深度。比如一種風格是絕大部分的面試時間用來詢問候選人的項目和經驗，讓候選人自己介紹，而面試官跟進追問。這原本是一種很好的方式，但是由于候選人對自己的項目通常遠比面試官熟悉得多，除非明確的同一領域，否則面試官較難對于其中的內容挖掘到足夠的深度，從而識別出候選人是真正做事的人，還是夸夸其談的人。這也是這種方式理論可行，但實際開展難度較大的原因之一。

另一個極端，自然就是考慮深度，但缺乏廣度。比如給出一個過于具體的問題，缺乏發揮和迂回的空間，對這個問題所涉及的很小一部分深度挖掘，甚至糾纏于某個特殊而單一的 case 很長時間，但是卻只能覆蓋很少的考察角度。

由于深度和廣度都是可控的，那么這樣可以拿來問不同經驗和不同技術背景的工程師候選人。這樣對于面試官來說，可以獲得足夠的數據，便于在遇到新的候選人的時候，能夠進行橫向比較，做出更準確的評估。

比方說，過去某級別的候選人能夠在面對這個問題的時候，能夠達到什么樣的級別，而如今這個候選人有著類似表現，這就可以以過去的那個例子來作為參考比較了。

再次回看那個案例

現在，讓我們再次回到文章開頭那個例子問題，除了已經提到的考察項的覆蓋不夠，它還有哪些問題呢？參考上文已經提到了 “好” 問題的標準，我覺得其中的這樣兩條是違背的：

從模糊到清晰。顯然，問題給出的時候就已經相對比較清晰了，這樣的方式并不能模擬軟件工程師日常面對的許多模糊而困難的實際問題。我已經提到，對于經驗豐富的候選人來說，這樣的問題無法重現將實際問題映射到軟件問題這樣的一個重要思考過程。

另一個是，圍繞問題的解決要完整。示例問題的考察過程中，只有缺乏互動的編碼環節，沒有其它過程，沒有編碼前的分析、思考和優化，也沒有編碼后的測試、改進和優化。考慮到 LRU 完整算法是一個實現代碼量偏大的問題，拿來放到面試中做一個完整實現，由于會消耗過多的時間，擠壓其它時間，因此顯得有些過了。

其它 “不好” 的問題

前面說了過于清晰的純算法題的 “不好” 之處，也說了 “好” 問題的例子，最后我想再來說幾類其它的且典型的 “不好” 的例子。

被使用過太多遍的問題

很多公司（如 Google 和 Facebook）都有參考題庫，題庫會不斷更新，其中一個重要原因，就是要盡量避免候選人做過被問到的題目。而且，問題越明確和具體，一旦候選人做過，考察的效果就越不客觀。比方說，下面這個問題本來是個很不錯的問題，但由于是被過于廣泛地使用了，因此我還是不建議拿它來用作面試題的：

怎樣設計一個短網址系統？

依賴于特定語言或框架

而這里說的依賴不好，是因為考慮到候選人不同的技術背景，如果沒有特殊的需要，避免這樣的依賴，以避免產生不應有的錯誤的衡量數據。

比方說，問一個關于 JVM 的問題，這個問題可以問，特別是在候選人強調其具備一定 Java 背景的前提下。但是這樣的問題不能成為 “主菜”，尤其是候選人不一定具備很強的 Java 背景，這樣的方式會導致考察的偏頗。

過于復雜的規則或背景知識

這主要是基于面試的有限時間考慮的，過于復雜的規則或背景知識，容易把時間消耗到澄清它們上面；另外，有些背景知識并非是所有人都熟知的，這就會引起考察標準的非預期。我給一個經典的反面例子：

設計一個算法，把一個小于一百萬的正整數，使用羅馬數字來表示。

這個問題描述簡潔，但是拿來做技術面試中的主要問題，其中一個不妥之處就是，不是所有人都很清楚一百萬內的羅馬數字表示法的。對于不清楚的人來說，要搞清楚這個表示法的規則，就已經是一件有些復雜和耗時的事情了。顯然，這個羅馬數字表示法的知識點，不應該成為考察和衡量的標準。

當然，有時候有些問題的背景知識是冷門的，但是表述簡潔，那么這樣的話只要 面試官能夠主動、迅速地說清楚，拿來使用是沒問題的。

知識性問題

我想特別談一談，對于知識性問題的提問。在討論問題的過程中，如果涉及到關聯的具體知識，那么提問一些基礎知識是一個不錯的選擇，這是考察候選人 CS 基礎是否牢靠的方式。比如候選人提到使用 HashMap，而他/她最熟悉的編程語言是 C++，那么詢問在 C++中 HashMap 是怎樣實現的就是一個可行的問題。而且，由于這樣的問題是嵌套在前述的這個大流量控制問題的解決過程中的，更顯得自然而不突兀。

反之，如果這樣的知識性問題較冷門或淺表，和當前討論中的問題無關，或是不在候選人的知識體系內，這樣的問題就值得商榷了。比如，僅僅因為自己的項目組使用 Spring，面試官就詢問候選人 Spring 的 bean 的單例和多例分別是怎樣配置的，而恰巧候選人又是 C++背景，對于這部分并不熟悉，這樣的問題除了給候選人造成困擾以外，意義就不太大了。

如果把知識性問題作為主要問題來提問，我認為是不適合的。因為一方面它不具備普適性，另一方面它又具備太強的隨機性。

這里不具備普適性這一條，指的是不同技術背景的軟件工程師候選人都要能夠適合參與這個問題的解答。舉例來說，如果問 “Tomcat 的線程池的配置策略？”，這就是一個不具備普適性的問題，這是一個偏重 “知識性” 的問題，如果候選人沒有使用過 Tomcat，或是只是略有了解，很可能就栽了。

而具備太強的隨機性這一條，指的是一旦待考察的問題具體以后，這個問題就容易從對 “能力” 的考察變成了對 “知識” 的考察，而這個知識，又恰恰是比較容易隨機的。

也就是說，我們不希望候選人 “恰巧” 知道或不知道某一個細小的知識點，來決定他/她是否通過這項考察。

無論如何，知識性的問題作為考察的輔助方式可以，但不應成為主角。我還是覺得我們應當能把更多的時間，留給主要問題的解決過程本身。

關于 “技術面試中，什么樣的問題才是好問題？”，我就說這么多吧，希望對你有所幫助。

在極客時間的專欄中，我也梳理了一套完整的技術面試方法論：

?

主要包括以下三個方面：

面試前：如何安排輪次和人選，面試要覆蓋哪些角度，怎么設計面試問題。

面試中：怎樣把控節奏，如何考察算法和數據結構，系統設計等等。

面試后：如何收集事實，提煉數據，從而客觀中肯的進行評估，并做出最正確的決策。

課程中也設置了足夠多的案例，帶你“進入”面試現場，深入剖析每個案例背后的本質問題，并給出應對方案。希望能帶給你富有啟發性的面試設計思路，幫你招到真正滿意的人選。

點擊試讀，也歡迎你分享你的看法，我們一起討論。

總結

以上是生活随笔為你收集整理的技术面试中，什么样的问题才是好问题？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。