程序員如何提問面試官？針對工程師、技術經理及CTO的提問指南

面試的時候，面試官通常最後會問：「你有什麼問題嗎？」，面試者往往回答說：「沒有」。 如果這種情況總是發生在你身上，那麼很有可能你對面試有一個非常片面的理解。

作為候選人，你通常只是專註於面試結果：是否獲得工作機會。 但不要忘了，工作面試不是單向的。 您應該在面試的時候專註於面試公司，因為他們同時也專註於面試您。那你應該問公司什麼問題呢？

很多求職者都問我這個問題。 在過去的15年中，我曾在7家公司工作，並且面試過更多家公司。 我決定寫出面試中，我提出的所有問題，希望能夠幫助其他人。我希望保持本文持續更新。 如果您有建議，請通過Twitter通知我，我會將你的問題納入其中，讓大家受益。

在面試中，您通常會遇到三種角色。根據公司的規模，可能是一個人或多個人：

• 軟體工程師

• 技術經理（技術負責人，中層管理人員）

• 公司領導（副總裁，CTO，首席執行官，部門經理）

我將在下面列出針對這些不同角色的不同問題。我有時會對多個角色重複相同的問題，以了解和比較他們的答案。

這是一篇很長的文章，它的意義更多是作為參考，而不是為了你照本宣科。如果我今天正在面試，我會看看本文，並在面試中（謹慎地）參考本文內容。

大多數問題沒有「正確」或「錯誤」的答案。它們旨在幫助您了解公司，了解其文化，流程和組織。當您的大腦卡殼時，他們也可以作為對話開頭，在面試中可能會非常有幫助。

我通常在面試開始時告訴面試官，我想有一些時間提問。這將有助於他們指定相應的面試計劃。通常情況下，在面試結束時面試官會讓我提出問題。每個問題後，暫停以詢問您是否可以繼續提問題，以及面試官還有多少時間。

這個問題的目的是確定是否有協作上的問題。我想從 2 - 3 名工程師那裡得到答案。如果公司領導說他們遵循一定的過程，但工程師不會談論這個過程，那就是協作問題的徵兆。如果您從不同的工程師那裡得到不同的答案，這是另一個工作協作問題的徵兆。

在高質量的團隊中，我會得到一致的答案。每個開發者都知道這個過程，並且可以很好的支持工程師的工作。

有一個好答案的例子（還有很多其他的）：「我們做 N 周的衝刺，其中每個工程師承諾提供一組功能和修復錯誤。我們每天都會報告我們對彼此的進展情況。我們有一個產品經理，幫助我們處理優先順序較高的功能和錯誤修復。「

也有一個壞的答案的例子（還有很多其他的）：「我進了辦公室，看看是什麼出問題了。大多數時候，我會被緊急事務打斷。「

注意我沒有提到「Scrum」或任何其他具體方法。我對工程師實際的日常「如何做的事情」更有興趣，而非工作過程的使用的標籤。

使用良好的工具是好團隊的特徵。如果一個團隊正在使用一個古老的版本控制系統，那麼他們可能會使用一些其他過時的工具。此外，他們可能不重視投資良好的工具以實現工作效率增長。

詢問工作流程是非常好的進一步的問題。你使用分支版本嗎？你喜歡 rebase 還是 merge（git術語）？這些問題會告訴你，他們所選擇的工具有多麼的專業，同時將會告訴你很多他們熟練程度的信息，反過來也告訴你如果你接受這項工作，你會有什麼期待。例如，你會成為「本地 git 專家」，還是跟隨一個名副其實的 Linus Torvalds 學習？

從這個問題可以開始關於一般工具的討論，這通常會給你一些很好的見解。

正面的答案：我從我所做的工作中獲得了滿足。

正面的答案：我們在工作中有很多樂趣。

正面的答案：我喜歡與真正聰明，友好的同事合作。

正面的答案：尊重工程技術。

這樣的答案越多越好。我不一定因為上面的答案給公司高分。請記住，有些人不會透露真實想法，所以你可能不會在這裡得到同樣的反應，這也是正常的。

但是如果我聽到以下幾種答案，我就會感到緊張：

負面的答案：幫助我支付賬單。

負面的答案：我不用努力工作。

負面的答案：沒有很大的交付壓力。

負面的答案：如果我犯了很大的錯誤也沒什麼。

負面的答案（沉默）

這不是我編的答案。我真的在面試中聽到過這樣的答案。

如果我偶爾聽到這些負面答案，我不會自動認為它是一個糟糕的公司，但如果這是唯一的答案，我通常會在其他地方看看。

（面試官：咳咳（尷尬），旁白由高可用小編貢獻）

根據單位測試實踐對工程團隊作出結論時要小心。當我詢問單元測試時，如果一個團隊興奮不已，這通常是一個好兆頭。另一方面，如果他們不能解釋為什麼需要單元測試，或單元測試的缺點，這可能是盲目的教條主義。如果他們無法給出不寫測試的理由（特別是像我們沒有時間這一借口），那對我來說是一個糟糕的跡象。

如果工程師告訴我他們編寫單元測試，他們就能夠告訴我們有關指標。例如測試運行多長時間，有多少測試以及代碼覆蓋率，這對我來說非常有吸引力。這表明他們有好工具，並且知道如何使用它們。另一方面，如果他們認為 100％ 的代碼覆蓋確保了一個無錯誤的代碼庫，那麼我很有興趣加入。

通過本問題，我可以知道是否會在一個大的，舊的，未經測試的代碼上工作。這將幫助我管理自己的期望，並決定這是否是我想做的事情。

後續問題：

• 你喜歡單元測試還是集成測試？

• 你有驗收測試嗎？

• 你使用什麼測試框架？你喜歡它嗎？

• 您的單元測試要運行多長時間？

5、你有持續集成嗎？

好的軟體開發團隊使用 Jenkins，Travis 和 Buildbot 等工具。如果團隊沒有持續集成，我會嘗試衡量他們是否熟悉這個概念。如果不是不熟悉，在我的經驗中這是一個壞跡象。持續集成系統意味著團隊可能相信自動化，這在我經驗中通常是好跡象。

對於一些團隊，這自然而然導致了關於持續交付的討論，這是與持續集成相關但不同的概念。如果這是網站開發人員的職位，我希望團隊至少聽說過持續交付，而強一點的團隊則至少在一定程度上使其成為現實。

後續問題：

• 當 CI 報告失敗時，您的團隊需要多長時間才能解決問題？

• 你喜歡/不喜歡你的 CI 系統？

• 您的 CI 運行一次需要多長時間？你會讓他們更快嗎？

6、你會觀測你系統中哪些東西？

這是一個開放式問題，旨在了解該團隊是否努力觀測其軟體。對於 Web 開發團隊，答案往往側重於性能指標，如伺服器響應時間，請求吞吐量，用戶數量，客戶端響應等。但是討論可以涉及到像不同語言的用戶數量，瀏覽器崩潰，緩存命中/錯失率以及無數其他主題。

如果團隊沒有花時間來觀測，那可能是他們沒有使用真實數據作為決策的指標。這可能是過早的優化。我重視一個根據真實的測量數據做出決策的團隊（特別是關於績效），這也適用於許多其他事情。

如果面試官知道這些問題的答案，這是一個很好的跡象，說明該團隊是高質量的。如果他們不知道為什麼需要關心這些指標，那可能是一個負面信號。

關於教條的規則在這裡仍然適用。如果團隊已經鎖定了一個未必能產生價值的，可操作強的指標，並且他們無法解釋這一點，這可能是一個負面信號。

後續問題：

• 您最重要的產品指標是什麼？

• 你使用什麼觀測系統？ （例如，MixPanel，statsd 等）

7、如何查找和修復 bug？

一個強大的團隊通常有專門的測試人員，與此同時團隊的開發人員也專註於質量。一個真正強大的團隊有令人印象深刻的自動化測試。有些團隊太小而無法擁有專門測試人員，但這並不意味著他們是一個糟糕的團隊。當我問這個問題時，我試著去感受他們的測試過程。他們是否總是火燒眉毛？他們是否有一個理智發現和優先考慮錯誤的過程？他們是否依賴用戶查找 bug？

後續問題：

• 如何優先處理錯誤？

• 使用什麼錯誤跟蹤器？ （和你討厭什麼）

• 使用Excel來跟蹤錯誤嗎？ （nooo！）

• bug跟蹤器有多少個bug？

• 錯誤需要多長時間修復（最小/最大/典型）？

8、你使用什麼協作工具？

根據我的經驗，好團隊使用大量的協作工具。他們經常使用聊天服務（Slack，IRC，HipChat，Jabber），代碼審查服務（Gerrit，GitHub，GitLab，Review Board），當然還有電子郵件。我正在尋找每個人如何知道其他開發人員在做什麼的方式。我並非在尋找細節，更多的是為了通識。此外，我希望看到同協作工具集成。最簡單的例子是可以發送自動構建失敗消息的電子郵件。 web-dev團隊的另一個例子是自動化錯誤記錄服務，當嚴重錯誤發生時或當關鍵指標跨越某個閾值時通知團隊。

我個人對框架的態度：

1. 我喜歡現代的東西

2. 我喜歡令我感到新奇的東西

所以如果一個團隊在 Motif 中構建一個 AIX 桌面應用程序，我可能不感興趣。但對你來說這可能是一個有趣的主題，你應該對自己的喜好有一個很好的了解。

不管您的框架偏好，了解為什麼團隊選擇了該框架很重要。他們是炒作驅動的嗎？他們改變框架像換內衣一樣頻繁嗎？他們被困在古老的版本上嗎？

關於為什麼問該問題，我是想了解開發商在選擇技術方面有多大的自由度。管理層是否決定技術選型？管理層是否依賴於開發人員？要解決這些問題，我通常會問：「你是如何在項目中使用框架 X 的？」。如果開發人員不知道答案，這可能是一個壞跡象，也可能他們是新人。

我喜歡看到團隊為他們使用的開源項目做出貢獻。這告訴我，他們不僅可以使用開源代碼，而且還能熟練掌握它。這才是我願意與之共事的開發人員。如果公司願意為他們這樣做付出就更好了。這告訴我公司了解成為開放源碼社區一分子的意義。

如果團隊正在重造輪子，而不是使用隨時可用的工具來幫助他們建立自己的產品，那麼我就會緊張。這個規則也有例外。例如，當 Facebook 這種體量的工資正在自己的框架上工作時，我就不會緊張（或者我會的）。

如果您想要清楚地了解與該團隊合作的內容，那麼請嘗試與他們一起工作。我從來沒有做過這件事，但我有一個朋友做過（有可能是故事）。我認為這是一個好主意。如果你想了解有關團隊的任何事情，請和他們一起工作半天。當然這可能需要您簽署 NDA。如果團隊願意考慮這個想法，我認為這是一個非常好的跡象。

如果要這樣做，您可能必須與管理人員進行溝通，所以這個問題更多地是為了得到開發人員的反應。他們可能對這樣的想法感到震驚，認為不值得。

這個問題旨在讓您更了解公司實際遵循的開發過程。這個問題本身並不能帶來豐富的信息，但是當你提出這些問題時，事情會更加有趣：

• 誰設定這個期限？

• 你在最後的截止日期前完成工作了嗎？如果沒有，為什麼不？

高質量的團隊一致同意截止日期並設定該日期。任意修改的截止日期可能是工作協同出現問題的徵兆，或者至少說明在確定時間表時工程師沒有話語權。

這個問題有助於衡量公司在開發者體驗方面付出的努力。新的開發人員需要幾個小時，幾天或幾周的時間來設置計算機並準備開始編碼？是自動還是手動？這將告訴您，團隊在「支持活動」中的熟練程度（與編寫軟體無關，但有助於支持該目標）。團隊是否認真對待這一問題？

有些公司為新開發人員有配套的配置流程感到自豪，因為新的開發人員可以在第 1 天將代碼投入生產。這表明該公司為開發人員提供了無縫的體驗。

（面試官：咳咳（尷尬），旁白由高可用小編貢獻）

我喜歡擁有強大技術背景的經理人。無意冒犯我的 MBA 朋友，但我真的喜歡那些和我有類似經歷的經理。

我認為好的經理是發自內心的喜歡而非被迫成為經理。我喜歡管理人員專註於為他們的團隊服務。我最喜歡的經理是那些專註於自己的團隊改善而不是「管理」的人。他們認為自己是團隊的幫手和保護者。他們有一種服務態度，他們會認為最重要的工作是讓團隊成員工作的更好。

既然我問了工程師同樣的問題，我就會和經理的答案進行比較，看看他們是否匹配。如果不匹配，可能意味著有一些協作上的矛盾。工作中最可怕的問題是無法辨識的問題。我認為這是經理的工作，確定工作中的問題並解決它。

他們通常回答說是工作人員短缺。因為這是一個顯而易見的答案（他們畢竟是招聘），所以我想問第二大挑戰是什麼。我正在尋找像延遲時間表，產品質量問題和人際關係的問題。每個團隊都有問題，所以你得到的答案取決於幾個因素：

• 經理對問題的意識

• 經理是否誠實地對待你

• 隊伍中的問題的嚴重性

5、你如何衡量員工的個人表現？

熟練的經理將有很好的技術手段來做到這一點。當評估個別團隊成員的表現時，最好的經理將會仔細收集整個團隊的反饋意見。不好的經理將會根據自己的觀察點作出評價，而不諮詢小組。

我喜歡為那些重視反饋意見並幫助團隊成員改進的經理工作。績效評估可能是痛苦，也可能是積極的過程。根據我自己的觀察，我認為大多數人認為這一過程是痛苦的。一個真正偉大的經理將會明白這一點，並且將採取措施，以某種方式使績效評估變得非常好，讓您印象深刻，並希望為他們工作。

後續問題：

• 你能告訴我一段時間你幫助某人提高他們的表現嗎？

• 在這些考核中你如何教導人？

7、你每年都會給下屬調薪嗎？

我想知道我的薪酬是否會根據我對公司的貢獻進行調整，我們每年至少會對其進行一次官方的評估。對於這樣的公司，我喜歡詢問有關股權的問題。你會給我股票期權嗎？你能每年給我更多的股票期權嗎？

有些工程師對問這樣的財務問題會感到不舒服。工程師通常花費很小一部分時間來思考這些問題，但管理人員總是會被問這些問題。這些問題不應該讓經理感到不舒服：

• 你如何進行加薪預算？

• 去年的中位數上漲是多少（百分比）？

• 我可以期待一年以後多少工資？最好的情況，最壞的情況？

我不會將這些問題寫入合同，這些問題也不會保證未來的加薪。相反，我想了解公司如何運作。我是需要用我的方式來要求加薪呢，還是有一個已經就位的標準過程？

我認為大多數人已經知道要問這個問題，但為了完整起見，值得一提。大多數公司都準備給你一堆紙或一個描述公司福利的網站。重要的是要知道，因為它通常是您很大一部分補償。這可能只適用於美國。我不知道公司提供的醫療保險獎勵在其他國家如何工作。

一些公司將排名和獎金相關，通過排列每個員工，從最壞到最壞，使一定比例的員工進入「好」，「平均」和「壞「子列表。

我從來沒有見過一個喜歡排名的工程師。這在大公司中尤其常見。它可以影響你與同齡人的互動，因為你知道有一天你必須與他們爭奪錢。

當我遇到這種情況，並不意味著公司是一個可怕的工作場所。在這樣的公司里，通常會有一些明面之下的操作空間。詢問面試官他們喜歡該系統。一些管理人員對於系統的不滿情緒會很坦率，有的甚至會告訴你他為團隊爭取利益的「遊戲」系統策略。如果你找到這種經理，你也可以忽視排名系統。

請記住，並不是每個人都討厭這個系統。只因為我沒有遇到喜歡該系統的人並不意味著他們不存在。

跟進問題：

• 你真的認為X％的員工「壞」嗎？這對你的招聘過程有什麼看法？ （這是一個大膽的問題 - 小心謹慎）

• 你應用某種曲線來確定表現最好的人嗎？

• 您使用什麼指標來對員工進行排名？

• 您如何知道這些指標是否準確收集？

• 您如何知道這些指標實際上是最佳表現？

針對公司領導層的問題

面試並不總是能碰到公司的高層領導（特別是對大公司來說），但是當有這樣機會時候，我把它作為評估公司財務可行性的機會。我可能沒有資格這樣做，但有一些明顯的問題，我有時可以通過面試發現它們。此外，我也想知道自上而下的文化是什麼，因為這些信息可以告訴我公司如何重視工程師價值。

我正在努力了解公司背後的資金。我想知道他們是否由風險投資，私募股權，公共股票或通過收入自籌資金。通常我可以在面試前弄清楚這一點，但公司的領導層常常會給出一些通過 Google 或 CrunchBase 找不到的見解。

如果盈利了，太棒了！如果沒有盈利，你們的盈利計劃是什麼？一些創業公司有盈利計劃，而其他創業公司則通過收購或 IPO 尋找出路。

後續議題：

• 過去幾個季度/年的歷史收入。它向上趨勢嗎？

• 競爭風險，如競爭，意外費用和收入不足。

• 跑道：在籌集更多資金前，公司可以運營多長時間。

3、你對外包有什麼看法？

我申請的工作是否可能會在未來被外包，或者這項工作是否可以變成管理外包的工程師。

這裡不只是問離岸外包，包括各種合同方式的外包。

這是另一個問題，我用來對應工程師與領導層的觀點。我正在尋找裡面不同的地方。如果領導和工程師觀點接近，這表明了良好的從上到下的溝通。我想知道高層領導是否與海內外員工脫節。我也想看看領導層是否有遠見，是否溝通良好。我喜歡的公司需要有一個強大的，共同的願景。

一些公司非常重視文化，這可能是件好事。至少你會清楚公司的價值觀。對於其他公司，你必須通過隱含的，有時候是不言而喻的細微差別來確定。公司文化是非常重要的。有政治鬥爭嗎？有專業價值嗎？誠實是否被看重？有加班費嗎？

隨著這個問題，我也會尋求真實的證據，而不僅僅是營銷炒作的信息。如果高層領導給我實際的數字，如收入，市場規模和資本化，這是一個好兆頭。此外，如果我可以從其他來源驗證這些信息，那就更好了。另一方面，某些數字可能表示非常糟糕，公司的資金只夠再燒一個月了。

（面試官：這個面試者好霸氣！旁白由高可用小編貢獻）

對我來說，這個問題的最佳答案是一個簡單的答案。如果該人可以畫出一個解釋彙報關係結構的簡單組織結構圖，我很滿意。我個人的喜好是為小型，敏捷的公司工作，而組織和通信開銷最小。您的偏好可能會有所不同。不管你喜歡什麼，這個問題都是為了給你所需要的信息，以便對該公司做出明智的決定。

面試是雙向的。 如果您有幸獲得 offer，請確保您的經驗做出明智的決定。 祝你好運！