開發人員的面試指南 – A developer’s guide to interviewing

另一個標題：如何面試一家公司。

你有沒有過，當你在面試的時候，面試官坐在桌子對面，雙眼注視著問你：「你還有其他問題嗎？」，而你回眼回去並說：「umm, 大概沒有了」。如果這曾經發生在你身上，你有很大的機率得到了一個單一面向的面試經驗。

作為一個應試者，可以想見你把目標放在一件事情上：取得工作職缺。但是別忘記，面試並不是一個單向的工作。如同面試官在面試你，你也必須要面試公司。

不過，你需要問他們什麼呢？

許多在尋找工作的開發者都問過我這個問題。在過去的 15 年內，我曾在 7 間公司工作 (包含兩個實習以及一個六個月的新創公司)，並且面試過無數次。我最後決定寫下我在這些面試中問的問題，好幫助其他面試者，並且期望對他們會有所幫助。

下面的列表中，針對不同的人，我有不同的問題詢問他們。注意到，有些問題我會在不同人之間重複詢問，然後比較他們之間是如何回答。

這是一篇很長的文章。 比較像是一份 reference，而不是一篇拿來閱讀的文章。如果我今天正在面試，我會將這份指南帶在身上，然後 (謹慎的) 在面試中使用裡面的提問。

大部分的問題沒有所謂「對」或是「錯」的答案。它們被設計來讓你更了解整個公司的文化、流程以及組織架構。它們也能拿來當作一個對話的開頭，這在你的大腦因為面試而呆滯的時候會有些幫助。

針對軟體工程師的問題：

1. 你如何知道你每天要做什麼？

   這個問題的目的是要了解有無工作流程上的障礙 (dysfunction)。我會希望從 2 到 3 個工程師口中問到答案。如果公司的領導階層說他們遵循幾個流程，但是工程師卻沒有談到的時候，這是一個流程障礙的跡象。如果你從不同的工程師口中問出幾個不同的答案，這又是另一個流程有問題的跡象。

   在一個高素質的團隊中，我會從不同口中得到相同的答案。每個工程師都知道工作流程，而這個流程又不會繁重到壓迫團隊，反而是支持他們運作。

   一個好答案的例子 (還有很多其他的答案) 像是：「我們有一個 N-星期的 sprints，工程師會根據一系列的 features 以及 bugfixes 來 commits。我們每日會根據自身的進度回報給其他人知道。我們有個很好的專案管理 (Project Manager)，他會幫我們處理客戶問題以及協助我們針對 features 與 bugfixes 標記優先度」。

   一個壞答案的例子 (還有很多其他的答案)：「我進到辦公室然後看哪邊起火了。通常我會被一個緊急事件給打斷。」

   注意到我沒有提到「Scrum」或是其他方法論的字眼。比起公司使用了什麼樣酷炫的工程方法，我更關心「實際上的運作在每天是如何完成的」。

2. 你們使用什麼樣的工具做版本控制？

   使用好的工具是一個好團隊的強力指標。如果一個團隊使用一個古老的版本控制系統，他們極有可能也使用一堆過時的工具。更甚者，他們可能不重視在投資在好工具上可以得到的效率增長。

   一個接續的問題會詢問有關 workflows。你們有使用 branches？你們偏好使用 rebasing 還是 merging (git 專有名詞)？這些問題會讓你了解到他們對於自己挑選的工具有多專精，這也會告訴你他們的能力深淺。這反過來告訴你，當你接受了這份工作，你該有什麼樣的期待。舉例來說，你是會變成「公司的 git 專家」？還是變成向Linus Torvalds 第二學習？

   這個問題可以作為關於工具討論的開頭，這通常會給你一些良好的觀察。

3. 你喜歡在這裡工作嗎？

   強指標：我從我的工作中獲得許多成就。
   強指標：我們的工作很有趣。
   強指標：我喜歡跟一群聰明、友善的同事工作。
   強指標：管理團隊很尊重工程師。

   強指標越多越好。我不必獲得所有的強指標答案來給一個公司高分。注意到有些人不一定能自然的給出強指標得答案，這是可以理解的。

   但是如果我聽到下面這些答案，而且聽到很少強指標，我會開始緊張：

   弱指標：他付我薪水。
   弱指標：我不用認真的工作。
   弱指標：這裡沒有太大的壓力來提交成果。
   弱指標：出了點大錯也無妨。
   弱指標：(一片沈默)

   不要以為我在虎爛，我真的在面試時聽過這些答案。

   我不會因為聽到弱指標的答案就考慮這是一家不好的公司。但是如果我只聽到弱指標，我會開始考慮其他地方。

4. 你們寫單元測試嗎？

   對於這個問題的結論要根據工程團隊在單元測試的實踐上小心的處理。如果一個團隊因為這個問題而感到興奮，這通常是一個好的指標。另一方面，如果他們不能解釋為什麼需要單元測試，或不能解釋單元測試的缺點，這有可能是盲從的指標。如果他們給出一個不好的理由說明他們為什麼不寫單元測試，尤其是像「我們沒有時間」這樣的理由，這對我而言就是一個壞指標。

   如果工程師能告訴我他們寫單元測試，並且他們能夠告訴我他們測試的指標，像是花了多久的時間運行，他們有多少測試，以及他們的程式覆蓋率，這就很吸引我了。這告訴我他們有好的工具，而且知道要怎麼使用。另一方面，如果他們相信 100% 程式覆蓋率代表著 bug-free 的 code base，我會有些警覺。

   我希望能在開始工作前得知我是否會工作在一個大的、老舊的、未經測試的 codebase. 這能讓我管理自身的期望，以及決定這是不是我想做的。

   接續提問的問題：

   • 你偏好單元測試 (unit test) 還是整合測試 (integration tests)？
   • 你們有驗收測試 (acceptance tests) 嗎？
   • 你們使用什麼樣的測試框架？你喜歡嗎？
   • 一次單元測試需要花多久的時間運行？

5. 你們有持續整合(CI)嗎？

   一些我所知道的好軟體團隊會使用諸如 Jenkins, Travis 以及 Buildbot. 如果團隊上沒有使用持續整合，我會試圖衡量他們是否熟悉這個概念。如果沒有，這在我的經驗中這會是個壞指標。使用 CI 系統代表著團隊信任自動化，在我的經驗中這是一個非常好的指標。

   對於某些團隊，這會自然的轉向有關持續交付 (Continuous Delivery) 的討論，這是一個跟 CI 有關但是不同概念的東西。如果是一個前端工程師的職位，我會期望團隊至少聽過 CD，而一個好團隊會傾向使用 CD，或至少某些地方。

   相關的問題：

   • 當 CI 回報失敗，你們團隊會花多久的時間開始修復？
   • 你喜歡 / 不喜歡你們 CI 系統的哪個部分。
   • 你們的 CI 會花多久時間運行？你們有試著讓它變快嗎？

6. 你們測量什麼？

   這是一個開放式問題，用來找出團隊是否有投入心力來量測他們的軟體。對於一個網頁前端團隊，答案會希望聚焦在性能指標諸如伺服器回應時間、request throughput、使用者數量、客戶端響應等等。不過討論可能會變成各種語言的用戶數量、瀏覽器崩潰、cache hit/miss rates、以及無數的其他話題。如果團隊沒有時間來做量測，這可能是一個指標，說明團隊沒有使用真實的資料來做出決定。他們可能會過早優化。我用一個團隊有沒有使用真的、可測量的資料來做出決定來衡量一個團隊，尤其是在效能上，不過這也可以用在其他事情上面。

   如果面試官能夠回答這些問題，這是一個高素質團隊的指標。如果他們對於為什麼需要花心力測量這些數據沒有頭緒的話，這可能會是一個壞指標。

   同樣的，關於教條式的規則也適用於此。如果一個團隊鎖定在一個沒什麼價值的測量指標上，而且他們沒有辦法解釋到你滿意，這可能是一個警告的指標。

   相關的問題：

   • 你們最重要的產品指標是什麼？
   • 你們使用什麼樣的量測系統？(e.g., MixPanel, statsd, etc.)

7. 你們如何找到並且修復 bugs?

   一個好的團隊通常會有專門的測試工程師，而團隊的工程師專注在質量上。一個真的好的團隊會有讓人為之一亮的自動化測試。有些團隊可能太小而不需要專職的測試工程師或是自動化測試，不過這不帶表他們就是一個不好的團隊。當我詢問這個問題時，我試著去感受他們的流程。他們是否經常火燒屁股？他們有理性的流程來找出 bugs 以及標記優先度嗎？他們是否依靠使用者來尋找 bugs？

   相關的問題：

   • 你們如何為 bugs 標記優先度？
   • 你們使用什麼 bug tracker？(還有你最討厭這東西什麼地方)
   • 你們使用 Excel 來追蹤 bugs 嗎？(noooo!)
   • 你們有多少 bugs 在 bug tracker 中？
   • 你們的 bugs 通常花多少時間修復？(min / max /typical)？

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

   在我的經驗中，高功能的團隊使用許多協作工具。他們經常使用 chat 服務 (Slack, IRC, HipChat, Jabber)，code review 服務 (Gerrit, GItHub, GitLab, Review Board)，以及那個雖然很老但是還是很有用的 Email。我會希望看到的指標是每個工程師能夠知道其他人在做什麼。我不是要來尋找極度細節的東西，更多是一般情況下的狀況。

   還有，我喜歡看到協作工具的整合使用。最簡單的例子莫過於當自動組建 (automated build) 失敗時，會有自動的 Email 提醒。另一個例子是當出現嚴重錯誤時，一個網頁前端團隊會有自動紀錄服務會去通知團隊的聊天室問題的發生，或某些關鍵指標跨越特定閥值時。

9. 你們使用什麼框架？

   我個人對於框架的偏愛可以分為兩類

   1. 我喜歡現代的東西
   2. 我喜歡「對於我而言新的」東西

   因此如果一個團隊是在建構一個基於 Motif 的 AIX 桌面軟體，對我而言就沒那麼有吸引力。但對你可能有。這是一個很個人的話題，你必須要對自己的喜好有深入的了解。

   不論你對於框架的偏好，了解團隊為何選擇這個框架是至關重要的事情。看他們是被流行驅動 (hype-driven)？他們換框架的速度是不是跟翻書一樣快？他們的 codebase 是不是跟著「每月最佳框架」的變動而被攪動的散落一地？他們是否被卡在某個框架的古老版本？

   關於「為什麼」這個層面，我希望可以了解工程師在選擇技術上有多大的自由度。管理階層是否要求某些使用某些技術？管理階層是否依賴於工程師？為了得到這些問題的答案，我通常會問：「你們在某專案裡面為何選擇使用 X 框架？」。如果工程師不知道這個答案，這有可能是一個壞指標，或只是代表他們還很菜，不必去理會這些問題。

   我喜歡看到團隊對於他們使用的開源專案有所貢獻。這告訴我們團隊不只是有能力使用開源專案，還夠專業到能夠貢獻回該專案。我樂於與這樣的工程師們工作。如果公司願意付錢讓他們這樣做，可以說是更好。這告訴我一間公司了解身為開源公民的意義。

   如果一個團隊喜歡重新製造輪子多於使用現成可用的工具來幫助他們建造產品，我會感到緊張。當然，這有例外的，例如說 Facebook 就在做他們自己的框架，我不會用這條規則去對抗他們(或者我會)。

10. 我們什麼時候可以來 pair programming?

    如果你對於跟這個團隊合作已經有一個明確的想像，那試著真的跟他們工作。我個人沒做過這件事情，但有我有一個朋友曾經這樣幹過 (對，真的很像故事)。我認為這是一個很棒的點子。如果你希望從他們身上了解整個團隊的運作，那就去跟他們合作半天吧。你可會被要求簽署一些 NDA。如果團隊能夠考慮這樣的點子的話，我認為是一個非常棒的指標。

    你可能會需要跟管理團隊來接洽這件事情，所以這個問題是設計來觀察工程師的反應。他們可能會被你的點子嚇到，因為這應該要跟管理團隊的人說，而不是工程師。

11. 你的下一個 deadline 在什麼時候？

    (contributed by Evan Farrer)

    這個問題是設計來了解更多有關於團隊開發流程的實際狀況。如果只有這個問題單獨提問，會顯得沒那麼有意義，不過如果你追加提問這些問題，事情就變得有趣了：

    • 誰設定這個 deadline？
    • 你遇到你的 deadline 了嗎？如果沒有，為什麼？

    高素質的團隊會一同決定 deadline. 如果 deadline 是被任意決定的，這可能是一個流程失衡的壞指標，或是至少告訴我們工程師在檯面上是沒有規劃排程的權利。

12. 設定一個新的工作環境會需要多長的時間？

    (Contribute by Evan Farrer)

    這個問題可以幫助我們測量一間公司在工程師體驗 (developer experience) 中花費了多少努力。公司需要花費一小時、一天、還是一個禮拜來讓新的工程師設定完成他們的電腦來開始工作？這些是自動的還是手動的？這會告訴你團隊在非直接相關於軟體開發上的行政能力。團隊是否把這件事情嚴肅看待？

    某些公司對於他們的流程能夠讓工程師在 day 1 就將程式碼放入 production 中感到驕傲。這說明公司對於提供工程師一個無縫接軌的環境看得很嚴肅。

針對大頭 / 管理階層 (Engineering Managers) 的問題：

1. 你最後一次寫 code 的時間？

   我喜歡有堅實技術背景的管理階層。無意對我的 MBA 朋友無理，但是我發現我喜歡那些做過我做的事情的管理階層。

2. 你如何成為管理階層的？

   我喜歡那些成為管理階層的大頭，是那些因為他們真的樂在其中而且對於管理這件事情有訣竅，而不是那些想要成為管理階層的人。我也喜歡那些專注在服務團隊的管理階層。我最喜歡的是那些專注在讓團隊變得更好，而不是「管理好」團隊的大頭。他們把自己當作是團隊的 helper 以及 protector。他們有著服務的態度，而他們認為他們最重要的工作是讓團隊成員的工作變得更好。

3. 你手下的工程師如何得知每日該做什麼？

   因為我問了工程師相同的問題，我想要來比較管理階層的答案，來看看他們是否有吻合。如果不吻合，這可能表示有流程上的問題。最糟糕的流程問題就是無法辨別出流程有問題。我相信管理階層的工作是要辨別出這些差異並且修復他們。

4. 你們團隊目前最大的挑戰是什麼？

   他們通常會回答是缺少工程師。這是一個常見且明顯的答案 (他們正在招募你啊！)，我喜歡繼續問他們第二大的挑戰是什麼。我會尋找一些危險的標誌，例如說無法照著流程運行、產品品質問題、以及人際互動的衝突。當你遇到的時後，你會知道什麼是危險標誌。任何團隊都有問題，所以答案跟一些因素會有關聯：

   • 管理階層對於問題的敏銳度
   • 管理階層是否願意誠實的面對你的問題
   • 問題在團隊中的嚴重程度

5. 你們如何界定一個人的績效？

   一個有能力的管理階層會有好的方法來做這件事情。一個好的管理階層會在需要測量個人績效時，小心地從團隊獲得回饋。一個差勁的管理階層則是只會根據自己的觀察而非詢問團隊出擊。

6. 你們會做正式的績效評估回顧嗎？

   我喜歡為會給予有價值的反饋以及幫助團隊成員進步的管理階層。績效回顧可以是一個痛苦或正面的經驗。根據我自身的觀察，我認為大多數的人覺得這很痛苦。一個好的管理階層知道這件事情，並且會採取措施，讓績效評估回顧變得更好，讓你對這件事情刮目相看而願意為他們工作。

   相關問題：

   • 你可以告訴我你曾在什麼時候幫助其他人增進他們的績效嗎？
   • 你如何在這些回顧中指導別人？

7. 你們有固定的年薪調整嗎？

   我喜歡知道我的薪水會如何根據我對公司的貢獻而作出調整，而這應該至少要每年有一次的正式檢視。對於那些符合條件的公司，我會詢問資產上 (equity) 的問題。我會有股票的選擇權嗎？我的股票選擇權會逐年調整嗎？

   有些工程師對於詢問這些財務問題會感到不自在。請別這樣。工程師花很少時間在想這些問題，但是管理階層時時都在做這些對話。這些問題對管理階層而言不該有所不適：

   • • 你如何規劃薪資上漲調整？
     • 去年在你的團隊中薪資上漲調整超過中位數有多少？ (用百分比)
     • 我對於一年後的薪資調整能有什麼樣的期待？最好的情況，最壞的情況？

   我問這些問題並不代表他一定要寫入合約或是保證未來會如此，反而是我希望能夠了解公司的運作方式：我到時候需要自己詢問薪資調整這件事情，還是已經有一個標準的流程在那了。

8. 我可以拿一些可以帶回家的公司福利描述嗎？

   (Contributed by Evan Farrer)

   我以為大多數的人已經知道要問這個問題，不過還是值得在這邊提醒一次。大多數的公司會準備成堆的紙張，或網頁，告訴你公司的福利。知道這點是很重要的，因為這會是你的薪資中的一大塊。這有可能只適用於美國。我不太清楚其他國家對於公司提供健保的狀況是如何。

9. 你會拿一位員工去比較另一位嗎？

   (Contributed by Matt Ryan )

   有些公司對於如何決定加薪以及獎金 (我在這邊不會列出來) 會使用一個大列表將所有員工標上名次，從最好的到最差的，然後再把某些百分比的員工放入一個「好」、「平均」、「差」的子列表中。

   我從來沒有遇過一個工程師喜歡這樣的做法。這在大公司中很常見到。這會影響到你如何與你的同事互動，因為你知道，有天你會為了薪水而跟他們競爭。

   當我遇到這樣的狀況，這不一定就直接的代表這個公司是一個很差勁的地方。總是有些地方可以在這樣的系統下過得很自在。詢問面試官他們喜不喜歡這樣的系統。有些管理階層會坦率地說出對於這個系統的不滿，有些則會告訴你他們如何「玩弄」這樣系統的招式，來讓他們的團隊獲益。如果你遇到這樣的管理階層，你大可以忽略到這樣的排名系統。

   請記住，這不代表所有人都討厭這種系統。只因為我沒有遇到，不代表喜歡這樣系統的人不存在。

   相關的提問：

   • 你真的相信 X% 的員工是「差勁」的嗎？這說明了你們的招募程序什麼樣的問題？(這是一個一針見血的問題，小心使用)
   • 你們在評估頂尖的工程師的時候有設下什麼樣難度的挑戰嗎？
   • 你們使用什麼樣的指標來評估員工？
   • 你怎麼知道這些指標有被精確地收集？
   • 你怎麼知道這些指標明確的標記出頂尖員工？

   更多資訊，Matt Rayn 這邊有一個很好的分析。

10. 你會定期做團隊回顧嗎 (team retrospective)？

    (Contributed by Aric Parkinson)

    如果有，他們如何運行？你多常得到來自團隊成員的回饋？你最後一次根據你從團隊上獲得的回饋來調整某些東西是什麼時候？

    這些問題的答案能夠給你一個對於期望管理階層如何回應有所概念，以及團隊是否會向管理階層回報問題。

    如果 retrospectives 沒有發生，對於團隊而言將很難標記出問題所在，更不用說糾錯來導正事情。而如果一個管理階層不覺得他們收到回饋，能讓團隊變得更好，那他們可能就是對於團隊的問題裝聾作啞，或是在建立一個沒有人覺得對問題發聲是一件安全事情的環境。

針對領導階層的問題：

我並沒有每次都與公司的領導階層談話，尤其是大型公司，不過當有機會的時候，我會視為一次評估公司財務可行性的機會。我不是這麼的夠格做這件事情，不過還是有一些顯而易見的問題可以在面試時詢問並發現。同時，我喜歡知道一間公司的 top-down 文化是否相符合，因為這可以告訴我公司是如何重視其公司的員工，不論是正面或是負面的部分。

1. 你是如何被投資的？

   我會試著深入了解公司背後的資金狀況。如果他們是被風險投資、私募股權、公開股票或是自籌資金，我想要知道。通常在面試前我能夠得知這件事情，但是公司的領導階層通常會加上 Google 或 CrunchBase 所不能查詢到的資訊。

2. 你們有利可圖嗎？

   如果有利可圖，讚！如果沒有，你對接下來開始轉盈的規劃是如何？一些新創公司會對這件事情有規劃，其他可能會透過收購或是 IPO。

   相關議題：

   • 前幾季/幾年的歷史收入。是否有提升的跡象？
   • 競爭風險？諸如競爭對手，意外開銷以及意外的收入跌落風險。
   • 準備開跑：公司在找到下一個投資前，還可以運作多久？

3. 你對於外包的看法？

   我要知道我申請的職位是否會在未來被外包，或是可能變成管理外包工程師的職位。

   這裏我不是只談離岸外包，還包括 contractors。

4. 跟我說一下公司的文化

   這又是另一個用來調和工程師以及領導階層觀點的題目。我會用來尋找差異的地方當作是程序失調的警示標記。如果領導階層以及工程師站在同一個觀點，這代表著公司有良好的上到下溝通。我想知道領導階層是否跟第一線員工有所脫鉤。我同時也想知道領導階層是否有堅實的遠見以及良好的溝通。我喜歡與有強大的，共同願景的公司工作。

   有些公司在文化上看得非常重，這可能是個好事。至少你對於公司的價值能夠有所了解。對於其他公司，你必須要透過隱晦的，甚至是未明說的細節來了解公司文化。文化可以是非常重要的一環。那邊是不是正在上演政治鬥爭？專業精神有價值嗎？誠實是被看重的嗎？有加班文化嗎？

5. 你有什麼保證這間公司會成功？

   這個問題我旨在尋找真正的證據，而非一些市場空話。如果領導階層能夠給出實際的數目，像是營收、市場大小以及收益資本化率，這就是個好的指標。當然，如果我能夠從外部的資訊來確認這個消息，更是一個更好的指標。另外一方面，數字可能給出一些不好的狀況，像是只剩下一個月的營運資金，然後沒有其他的投資者。

6. 說一下你們的回報架構？

   對我而言，最好的答案就是最簡單的一種方式。如果他可以畫出一個簡單的組織架構圖來解說回報的架構，我就滿意了。我的個人偏好是在小型、敏捷而有精簡組織與低溝通成本的公司工作。你的偏好可能不同，這是很 ok 的。不論你的偏好為何，這個問題是用來給你有關的資訊，以便對於 offer 做出明智的決定。

結論

面試是雙向的。如果你有能力可以獲得一個 offer，確保你從所需的經驗中做出明智的抉擇。祝你好運！