副標題：如何面試一家公司

你有沒有經歷過這樣的工作面試，面試官看著桌子對面的你，說：“你還有什麼問題嗎？”你也看著面試官說：“嗯……我覺得沒有了”。如果這發生在你身上，那麼對於面試經驗，很有可能你有一個非常片面的看法。

作為面試候選人，可以理解只關注一個結果：獲得工作機會。但不要忘了，工作面試不是單向的。你也應該關注如何面試該公司，因為他們也在專注於如何面試你。

但是你該問他們什麼呢？

很多求職者都問過我這個問題。在過去的 15 年裡，我曾在 7 家公司工作（包含 2 個實習崗位，6 個月在一家創業公司兼職），我曾被十幾個人面試過。現在我終於決定寫下這些在面試中提出的所有問題，希望其他人能夠從中獲得些許幫助。

旁註：我們在每週的開發者建議播客 Soft Skills Engineering 中涵蓋了這個主題和許多其他的內容。歡迎訂閱！

我的目標是使它成為一個一直活躍的文檔。如果您有建議，請通過 Twitter 聯繫我，我會將其納入其中，供大家參考。

你會和誰交談呢？

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

• 軟件工程師
• 工程經理（技術負責人，中層管理者，主管）
• 公司領導（副總裁，首席技術官，首席執行官，部門經理）

我對這些角色的每個人都有不同的問題，下面將會列出。請注意，我有時會對多個角色問重複的相同的問題，以瞭解他們的答案是否一致。

這是一篇很長的文章，它的意義更多是作為參考，而不是通讀片段。如果我今天正在面試，我會在帶上這個，並在面試中（謹慎地）參考。

大多數問題沒有 “正確” 或 “錯誤” 的答案。它們旨在幫助你瞭解該公司，它的文化、流程和組織架構。你也可把它們作為對話的開始，當你的大腦 “宕機” 時，這在面試中可能會非常有幫助。

作為禮貌，我通常會在面試開始時告訴面試官，我想有一些提問的時間。這有助於他們對此做出相應的規劃。通常情況下，他們在面試結束時讓我提出問題，因此要留意麵試進程，並讓他們在這過程中早點察覺到你的想法。每個問題提問後，暫停下並詢問你是否可以繼續問問題，以及面試官還有多少時間。

對軟件工程師的問題

1. 您是如何知道每天的工作安排的？

這個問題的目的是確定是否存在溝通障礙。我想從 2 到 3 名工程師那裡得到答案。如果公司領導說他們遵循一定的流程，但工程師沒有談論到這個流程，那就是溝通障礙的徵兆。如果從不同的工程師那裡得到不同的答案，這是溝通障礙的另一個徵兆。

在高質量的團隊中，我得到了一致的答案。每個開發者都知道這個流程，而且這個流程是足夠輕量級的，它會獲得工程師的支持，而不是反對。

其中一個很好的回答的例子（還有很多其他的例子）是：“我們做 N 周的衝刺，其中每個工程師承諾提交一組功能和錯誤修復。每天我們都會報告彼此提交的進展情況。我們有一個了不起的產品經理，他與客戶接觸，幫助我們安排功能和錯誤修復的優先級。“

其中一個壞的回答的例子（還有很多其他的例子）是：“我進了辦公室，看看有哪些迫在眉睫的事情。大多數時候，我會被突發事件所打斷。”

注意我沒提及 “Scrum” 或其他任何具體的方法論。相比於僱員每天實際上是如何工作的，我對公司用於工程流程管理的標籤並不太感興趣。

2. 您使用什麼版本控制工具？

良好的工具是良好團隊的強大指標。如果一個團隊正在使用一個古老的版本控制系統，他們可能會使用一些其他過時的工具。此外，他們可能不重視投資良好工具所帶來的效率提升。

一個很好的後續問題是詢問關於工作流的問題。你們使用分支嗎？你們喜歡 rebase 或 merge（git 術語）嗎？這些問題會告訴你，他們對於所選擇的工具有多瞭解，也會告訴你很多關於他們熟練程度的信息，反過來這會告訴你如果你接受這項工作會怎樣呢？例如，你會成為 “本地 git 專家”，還是要向名副其實的 Linus Torvalds 學習？

這個問題也可以開啟針對一般的工具的討論，這通常會給你一些良好的洞察。

3. 這份工作的哪些東西是你喜歡的？

好的回答：我從工作中收穫了滿足。好的回答：在工作中有很多有趣的東西。好的回答：我喜歡與真正聰明，友好的同事工作。好的回答：管理人員尊重工程師。

越多好的回答更好。我不需要得到上面所有的回答才給一家公司打高分。記住有些人不會自然地 “流露出感情”，所以你可能不會得到主要的回答，但公司可能會很好。

但是如果我聽到以下幾種回答，並且很少聽到好的回答列表中的回答，我會感到很忐忑：

差的回答：支付賬單。差的回答：我不用努力工作。差的回答：沒有很大的交付壓力。差的回答：我是否犯了很大的錯誤並不重要。差的回答：（沉默）

不要以為這些回答是我編造的。在真正的面試中我確實聽到過這些回答。

如果我聽到這些差的回答，也不會就此在心裡默認它是一間差的公司，但如果這些是僅有的答案，我通常會去其他地方看。

4. 你們寫單元測試嗎？

當你基於一個工程團隊的單元測試習慣對他們做出判斷時，要小心了。如果一個團隊當我問其關於單元測試時變得興奮，這通常來說是個好信號。但是另一方面，如果他們不能解釋問什麼他們要單元測試，或者單元測試的缺點，這是一個盲羊般教條主義的跡象。如果他們對

如果工程師告訴我他們寫單元測試，並且他們也能告訴我他們測試的度量標準。比如他們需要運行多長時間，他們有多少測試，覆蓋多少代碼，這對於我來說很有吸引力，這表明了他們有好的工具，並且知道怎麼去使用，另一方面，如果他們相信100%代碼覆蓋率能基本上保證無錯誤代碼，我持懷疑態度。

我想要事先知道的是，我是否會在這家公司工作中需要面對一個龐大、過時，而且未經測試的代碼庫。這些將有助於我設定自己的期望，並決定這些是否是我想做的事情。

後續問題:

• 你們更喜歡單元測試還是集成測試？
• 你們會驗收測試嗎？
• 你們使用什麼測試框架，喜歡它嗎？
• 你們的單元測試需要運行多長時間？

5. 你們有持續集成嗎？

據我所知最好的軟件開發團隊會使用 Jenkins, Travis 和 Buildbot 等工具。我會通過他們是否熟悉這個概念來衡量此團隊是否有持續集成。如果沒有，以我的經驗來說是一個不好的信號。如果有持續集成系統意味著此團隊應該也相信自動化，按我的經驗這通常是一個非常好的信號。對於一些團隊，這很自然的產生了一個關於 持續交付 的討論，這與持續集成是一個相關但不同的概念。如果以一個 Web 開發人員的角度來說，我希望團隊至少會聽過 CD，而有實力的團隊更傾向於將 CD 落實到位，至少在某部分如此。後續問題：

• 當 CI 報告了一個錯誤，你的團隊花費多長時間來修復？
• 你喜歡/不喜歡你的 CI 系統嗎？
• 你的 CI 運行需要多久？你有讓它們更快嗎？

6. 你們如何衡量(軟件)？

這是一個開放式問題，旨在瞭解該團隊是否有付出努力衡量其軟件。對於 Web 開發團隊，回答往往側重於性能指標，如服務器響應時間、請求吞吐量、用戶數量、客戶端響應等。但是討論可以涉及到像使用不同語言的用戶數量、瀏覽器崩潰 、緩存命中/錯失率以及無數的其他主題等。如果團隊沒有花時間來衡量，那可能表明了他們沒有使用真實的數據來支撐他們的決策。它們可能是過早地進行了性能優化。我看重一個使用實際的可測量數據來支持決策的團隊，特別是關於性能方面的，不過它也適用於許多其他事情。

如果面試官知道許多這些問題的答案，那麼這是高質量團隊的一個好的信號。如果他們不知道自己為什麼需要關心這些測試，那麼這可能是一個消極的暗示。此外，教條般的規則在這裡同樣適用。如果團隊看起來好像已經鎖定了一個並不一定能產生有價值的、可操作的信息的指標，並且他們對於這一點的解釋無法讓你滿意，這可能是一個警告信號。後續問題:你認為最重要的產品指標是什麼？

你使用什麼測量系統？ （例如 MixPanel, statsd 等）

7. 如何查找和修復 bug？

一個強大的團隊通常有專門的測試人員，團隊的開發人員專注於代碼的質量。一個真正強大的團隊具有讓人印象深刻的自動化測試。也有一些團隊太小，並不具備專門的測試人員或實現測試自動化，但這並不一定意味著他們是一個糟糕的團隊。當我提出這個問題的時候，我在試圖瞭解他們工作的流程。他們總是火燒眉毛麼？他們是否有一個合理的過程來查找和排列錯誤的優先級？他們是否是依靠用戶來查找錯誤？

後續問題：

• 你們如何處理 bug 的優先級？
• 你們使用什麼 bug 跟蹤器？ （以及你們討厭它們的什麼）
• 你們使用 Excel 來跟蹤錯誤嗎？ （從未有過!）
• 在你們的 bug 跟蹤器發現了多少個 bug？
• 你們需要多長時間來修復 bug（最小/最大/一般）？

8. 你們使用什麼協作工具？

根據我的經驗，高效率的團隊使用大量的協作工具。他們經常使用聊天服務（Slack，IRC，HipChat，Jabber），代碼審查服務（Gerrit，GitHub，GitLab，Review Board），當然還有值得敬仰但略有年代感的電子郵件。我正在尋找每個開發者知道其他開發人員在做什麼的指示。我不是在尋找荒唐到極致的細節，更多的是為了一般意義上的知道。此外，我喜歡看到不同協作工具間的集成。最簡單的例子是在自動構建失敗時隨時發送自動的電子郵件。另一個關於 web-dev 團隊的例子是自動化錯誤記錄服務，當發生嚴重錯誤時或當關鍵指標超過某個閾值時通知團隊的聊天室。

9. 你們使用什麼框架？

我對框架的看法有兩方面：我喜歡時髦的東西。

我喜歡對於我來說是新鮮的東西。

因此，如果一個團隊要使用 Motif 構建一個 AIX 桌面應用，我可能不是很感興趣。但可能你會感興趣。這是一個很個人的話題，你應該對自己的喜好有一個很好的瞭解。不管你的框架偏好是什麼，瞭解團隊為什麼選擇他們的框架是很重要的。是什麼驅動他們這麼做的？他們換框架是不是就像他們換衣服那樣快？他們的代碼庫是否每個月都有碎片化流失，然後變得亂七八糟？他們有沒有被一個久遠的版本卡住？

至於為什麼，我想知道開發者在選擇技術方面有多大的發言權。是管理層選擇技術嗎？管理層是否依賴於開發人員？為了深入瞭解這些問題，我通常會問他們，“你們為什麼在項目中使用某某框架？”如果開發者不知道答案，這可能是一個不好的信號，這意味著他們在項目中不能決定他們要使用什麼技術。我希望團隊裡的成員能夠為他們使用的開源項目做出貢獻。這告訴我他們不僅能夠使用開源代碼，而且他們也以足夠熟悉項目能為它做出貢獻。這些開發者是我喜歡與之合作的類型。如果公司願意為他們此種行為買單，這說明公司知道這些對於開源開發者的意義是什麼。如果團隊正在造輪子，而不是使用現成的工具來幫助他們構建產品，這會讓我擔心。當然也有例外的情況。比如我不會反對 Facebook 用他們自己的框架進行開發（或許我會）。

10. 我們什麼時候可以 “結對”？

如果您想要清楚地瞭解與該團隊一起工作的內容，那麼請嘗試與他們合作。我從來沒有親自做過這種事，但我有一個朋友做過（跟真的似得，對不）。我認為這是一個好主意。 如果你想了解任何有關該團隊的事情，請和他們一起工作半天。可能需要您簽署 NDA。如果團隊甚至願意考慮這個想法，我認為這是一個非常好的信號。

您可能需要與管理人員安排這件事，所以這個問題更多的是為了得到開發人員的反饋。他們可能會因為不值得提升管理層的觀念而感到震驚。

11. 你們的下一個最後期限是什麼時候？

(由 Evan Farrer 貢獻)這個問題旨在讓您更瞭解公司實際遵循的發展歷程。這個問題本身的信息量並不是十分豐富，但是當你添加這些問題時，事情就變的更加有趣了：誰來設定這個期限？

你們遇到了最後的截止日期嗎？ 如果沒有，為什麼沒有遇到？

高質量的團隊會一致同意並承諾期限。武斷地確定的最後期限可能是溝通障礙的徵兆，或者至少在確定時間表時，工程師沒有一席之地。

12. 搭建新的開發環境需要多長時間？

(由 Evan Farrer 貢獻)這個問題有助於衡量公司為優化開發者的開發體驗有多少付出。新的開發者需要幾個小時、幾天或幾周的時間來配置電腦並準備開始編碼？這些操作是自動的還是手動的？這些問題將告訴你，團隊在“支持活動”中的熟練程度，雖然這與編寫軟件無直接聯繫，但有助於支持它。所以看看團隊是否認真對待這個問題。有些公司會為開發者設置過程如此之快而感到自豪，因為新的開發者在第 1 天就可以投入工作。這表明該公司為開發者提供了無縫的體驗。

對於工程經理的問題

1. 你最近寫代碼是什麼時候？

我喜歡經理有很強的技術背景。無意冒犯我的 MBA 朋友們，但是我需要的經理是那些與我做相同事情的人。

2. 你是如何成為經理的？

我喜歡的是那些真心喜歡並有一些小竅門而去選擇成為經理的人，而不是那些被迫變成經理的人。我也喜歡那些近似於更專注服務團隊的經理們。我最喜歡的經理類型是那些專注於讓團隊人員生活得更好的人，而不是精於“管理”的人。他們認為自己是團隊的幫手和保護者。他們有一種服務態度，而且他們認為自己最重要的工作是讓他們團隊成員的工作環境更好。

3. 你的工程師如何知道每天的工作？

既然我問了工程師們相同的問題，我希望對比一下經理的回答，看看他們是否一致。如果不同，可能意味著出現了溝通障礙。最糟糕的情況是還沒意識到此障礙。我相信找出這種差距並解決它是經理的工作。

4. 現在你的團隊最大的挑戰是什麼？

他們通常會回答人員短缺。因為這是一個顯而易見的答案(畢竟他們正在招聘)，我想要問的是他們第二大的挑戰。我要尋找他們的松馳時間安排，產品質量問題和人際關係中的危險信號。當你看到它們你就知道了。每個團隊都有問題，所以你得到的回答取決於以下幾個因素：

• 經理對問題的意識
• 經理對你坦誠的意願
• 團隊問題的嚴重性

5. 你如何衡量個人表現？

有經驗的，有技術的經理能做到這一點。 當評估個別團隊成員的表現時，優秀的管理者將會仔細收集整個團隊的反饋意見。 一個糟糕的管理者將會根據自己的觀察得出結論，而不是通過小組。

6. 你做正式的績效評估嗎？

我喜歡為那些重視反饋意見和幫助團隊成員進步的經理工作。 績效評估比較麻煩，但能激發團隊成員的幹勁。據我觀察，大多數人都不喜歡績效評估。 優秀的經理一旦意識到這一點，就會立即採取措施，改善績效評估的方式，讓人心甘情願參與進來。

後續問題：

• 你能告訴我你曾幫助他人提升的經歷嗎？
• 通過這些績效你如何引導他人？

7. 您經歷過年薪增長嗎？

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

有些工程師在問這樣的財務問題可能會感覺不舒服。大可不必這樣。工程師通常花費很小一部分時間來思考這些話題，但管理人員一直會涉及這些話題。主管已經對這些問題習以為常：

您如何為加薪做預算？

• 去年的工資上漲的中位數是多少（百分比）？
• 我可以期待一年以後工資是多少？最好的情況？最壞的情況？

我並不把提出這些問題作為簽署合同或者保證未來提升的前提。相反，我想了解該公司如何運作。我是否必須按照我的方式來要求加薪，還是已經存在有一個標準的流程？

8. 我可以得到一些描述公司利潤的關鍵點資料嘛？

(由Evan Farrer提供)我認為大多數人已經知道要詢問這個問題了，但為了完整起見，還是值得一提的。 大多數公司都準備給你一堆紙質材料或一個描述公司利潤的網站。 重要的是你要知道在哪裡，因為它通常是你補償的很大一部分。 這可能只適用於美國。 我並不清楚位於其他國家中由公司所提供的醫療保險優惠政策是如何工作的。

9.你把員工一起排列嗎？

（供稿人：Matt Ryan）

一些公司通過在一個大排序列表中排列每個員工，從最好到最壞，然後迫使一定比例的員工成為“好”、“中等”和“壞“的子列表，確定提升和獎金。

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

當我遇到這種情況，可能不會立即意味著這家公司是一個可怕的工作場所。在這樣的公司裡，經常會有一些小小的“空間”在雷達下飛行。詢問面試官他們是否喜歡這樣的系統。一些管理人員對於系統的不滿情緒會很坦率，有的甚至會告訴你有關他們用來為他們的團隊謀利的“遊戲”系統的策略。如果你找到這種經理，你可能會忽視排名系統。

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

• 你真的認為 X％ 的員工“差勁”嗎？ 這反映了招聘過程的什麼問題？ （這是一個大膽的問題 - 謹慎回答）
• 你會運用曲線圖來標明表現最好的人嗎？
• 你使用什麼指標來對員工進行排名？
• 你如何知道這些指標是否收集準確？
• 你如何知道這些指標能反映員工的最佳表現？

更多相關信息，請參閱 Matt Ryan 對該問題的準確分析。

10. 你會做定期的團隊回顧嗎？

(由 Aric Parkinson 貢獻)如果是這樣的話，他們喜歡什麼？你大概多久可以收到團隊成員的反饋？你最近一次根據你收到的反饋改變了你的團隊運作方式是什麼時候？這些問題能夠指引你發現你期待的管理層的樣子，還能讓你看見團隊是否向管理層提供了足夠多的反饋。如果團隊不進行總結回顧，就難以發現工作中的問題，更不用說變速來糾正錯誤。 如果管理人員不相信反饋意見能促進團隊發展，那麼他們可能會對團隊出現的問題聰耳不聞，或者會營造一個緘默的氛圍，團隊成員再問題面前都不敢發聲。

針對領導人的問題

我和公司的高層領導交談的時候不多，尤其是在大公司，每當我這樣做的時候，就是我想理解公司財務能力的時候。在每一次的會面中，我可以瞭解到一些顯著的問題。 此外，我也想知道自上而下的文化是什麼的，因為這些信息可以告訴我公司如何積極地和消極地對待工程師的。

1. 您是如何融資的?

我正在努力加深對公司背後資本的瞭解。如果他們由風投、私募股權、公共股票或通過營收自籌的資金，我想對此有所瞭解。通常我可以在面試前弄清楚這一點，但公司的領導層常常會加深我在某些問題上的理解，這些是我通過 Google 或 CrunchBase 找不到的知識。

2. 你盈利了嗎？

如果已經盈利，太棒了！ 如果沒有盈利，你的盈利計劃是什麼？在其他創業公司則通過收購或 IPO 尋找出口的時候，你也開始制定一項計劃吧。

後續議題：

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

風險盈利，如競標、意外支出和意外收入不足。

運營: 在籌集更多資金前，公司可以運營多長時間。

3.你怎麼看外包？

我想知道我申請的工作在未來是否會外包，或者是否這個工作會變成管理外包工程師的職位。

我在這裡不光是討論離岸外包。這也包含了承包商。

4.告訴我公司的文化。

這是另一個我過去常常用來調和工程師的觀點和領導的觀點之間的衝突的問題。我尋找一些差異做為異常的信號。如果領導和工程師意見一致，那就說明上下溝通比較通暢。我想知道高級管理層是否已經脫離了前線的員工。我也想看看領導層是否有良好溝通的堅實視野。我理想的公司是有一個強大的，共同的願景的。

一些公司非常重視企業文化，這可能是件好事。 至少這對你清晰瞭解公司的價值觀有所幫助。 而對於另外那些不重視企業文化的公司，你必須通過隱含的不成文的習慣來發掘。 文化可以非常重要。政治鬥爭存在嗎？專業的價值如何？誠實被重視嗎？有加班費嗎？

5.你用什麼保證這個公司會取得成功？

針對這個問題，我嘗試尋找真實的證據，而不僅僅是營銷炒作。 如果高層領導給我真實的數字，如收入，市場規模和市值，這將帶來很大幫助。 此外，如果我可以從其他來源驗證這些信息，那就更好了。另外，數字也有可能反映出糟糕的結果，就像一個月的跑道，很快就沒有資金。

6. 告訴我你的報告結構。

對我來說，這個問題的最佳答案其實很簡單。如果你能畫出一個簡單的組織結構圖來解釋報告結構，我就十分滿意。我個人偏向於為規模組織小、敏捷、開銷也不大的公司工作。每個人偏好不同，但不管你的偏好是什麼，這個問題都是為了提供你所需要的信息，以便對公司做出明智的決定。

結論

面試是雙向的。 如果你有幸獲得錄取通知，請確保你從已有的經驗中做出明智的決定。祝你好運！

https://www.oschina.net/translate/how-to-interview-as-a-developer-candidate?lang=chs

閱讀更多 誰不曾年少輕狂 的文章

關鍵字: 支付 面試 片面