談到設計 Staff-plus 工程師的面試流程，第一件要說的事是：沒有任何人對自己的 Staff-plus 面試流程有信心。許多流程最後其實是在找「一個解題特別快的資深工程師」，而這並不反映真實的角色；有些流程專注於溝通能力，那確實是角色的關鍵部分，但絕非全部；還有少數公司甚至把流程設計成評估「候選人是否像現有資深工程團隊的一員」，把卓越誤當成熟悉。
即便沒人對自己的流程感到滿意，仍有一批集體累積的經驗可以借鑑。本節會先檢視 Staff-plus 面試流程常見的失敗模式，接著討論你真正想測到的訊號，最後談幾種評估這些訊號時特別有用的面試形式。
常見的失敗模式#
技術面試整體本就一團亂，而針對非常資深候選人的面試，問題更是多到能自成一台「掙扎巴士」。在思考什麼做法更好之前，先理解這些常見失敗模式會有幫助。
- 「資深工程師，但更強」。 許多流程把 Staff-plus 工程師看成「各方面都好一點」的資深工程師：快一點、溝通清楚一點、架構討論細膩一點。這源於多數人不熟悉 Staff 角色，通常會導致 Staff-plus 工程師在這類流程中表現不佳。尤其多數 Staff-plus 工程師寫程式比資深工程師少，因此在死記硬背式的程式任務上是更慢、而非更快。你會遇到一些仍然很快的 Staff-plus 工程師，但你不會發現這種速度和他們的影響力之間有多少相關。
- 「資深工程師，但更弱」。 反過來，有些流程意識到 Staff-plus 工程師寫程式較少，於是預期他們在較平淡的程式練習上會慢一些。這讓 Staff-plus 工程師更容易通過，卻抓不到「這類工程師之所以格外有影響力」的訊號。若你不加上額外面試來捕捉那些強項，較慢的死記速度雖然會和資歷有某種程度的相關，但它和其他許多因素的相關更強。
- 「資深工程師，但他們會接 offer」。 另一種失敗模式是：公司招不到資深工程師，於是在不改變角色期待的情況下灌水頭銜。此時面試與實際工作相符，但頭銜不符。當公司與候選人都不願正視這種灌水，該公司未來所有的 Staff-plus 招募都會蒙上一層不確定的疑雲。
- 「和我們一樣的人」。 許多流程聚焦於候選人是否散發出和公司現有 Staff-plus 工程師相同的智慧與自信，面試講評可能出現「他感覺會很自然地融入這個團隊」這類說法。這種做法更可能錨定在「他如何展現自信」這類半隨機特徵上，而非候選人的實際能力。
- 「沒有比我強」。 尤其在招募第一批 Staff-plus 工程師時，你常會遇到一些較資淺的面試官，低估候選人的強項，反而錨定在「候選人能不能做好我現在這份工作」。於是你手上有位出色的 Staff-plus 候選人，面試小組卻懷疑他能否勝任一個中階工程師的角色。這種情況在女性與少數族群候選人身上被提及得最頻繁。
- 反向過濾器。 某些面試本身就是訊號，透露出你的組織不知道該怎麼用 Staff-plus 工程師：白板演算法題、面試官清一色是資淺者，諸如此類。許多 Staff-plus 流程會讓最好的候選人在早期就退出，而且往往在招募指標上悄無聲息、看不出來。
- 太過看重頭銜？ 到了某種成就水準，人們其實不太在乎內部職級，通常是因為他們已經財務無虞。這對「首次踏上 Staff-plus」的人造成一種奇特壓力：他們得避免顯得太在意職涯或頭銜，反而讓人更難第一次取得這個頭銜。
這些失敗模式中，有些相當難解，有些只要記在心上就好處理，但當你開始設計或重新構想 Staff-plus 面試流程時，全都值得納入考量。
你想測到的訊號#
最好的面試流程是從「你想捕捉的訊號」反推回面試主題與形式。因此第一個要回答的重要問題是：「要成功招到 Staff-plus 工程師，哪些訊號才重要？」
- 自我覺察（Self-awareness）。 他們會為錯誤負責嗎？在自己過去較弱的領域，是否展現過成長？
- 判斷力（Judgment）。 他們能否預見拐角後的問題？能否駕馭廣泛、模糊的問題？能在關於取捨或設計的爭論中有效居中調解嗎？能為困難問題的執行降低風險嗎？
- 協作（Collaboration）。 他們和別人合作得好嗎？和經驗不如自己的人呢？比自己資深的人呢？他們的經理？跨職能？高階主管？
- 溝通（Communication）。 他們是能理解他人論點的好聽眾嗎？能清楚傳達自己的想法嗎？能用你公司仰賴的形式（書面、口頭等）溝通嗎？
- 培養他人（Development）。 他們會讓周遭的人成長嗎？在他們領導的領域，「組織的板凳深度」是變厚還是萎縮？壞掉的系統與流程會被清理乾淨嗎？
值得注意的是，許多人不會把這些明確地視為技術技能。領域專業是在這一切上成功的重大因素，但真正讓一個人從資深工程師蛻變為 Staff-plus 的，是把那份專業與其他關鍵技能和行為「合併運用」的能力。
形式與結構#
設計面試流程時，永遠要問自己兩個關鍵問題：
- 這個人日常要成功，需要具備哪些任務與行為？
- 我們要怎麼讓他們真的把這些「做出來」給我們看？
多數資深候選人會變得越來越圓滑，光是「問」他們的工作，遠不如「看」他們工作來得有用。若導師帶人是最重要的活動，別靠他們談論導師帶人，而要設法看他們實際帶一個人；若是架構，就把你現有的系統攤開，請他們帶著問題來，看他們如何面對自己不認同的決策——遠離那些模糊的抽象。
除了典型的一對一討論與程式面試，以下是我發現對評估 Staff-plus 訊號特別有效的幾種形式：
- 結構化簡報（Structured presentation）。 讓候選人針對一個窄主題，準備並向一群同儕做二十到三十分鐘的簡報。這個形式對「結構化思考、溝通、傾聽並回答問題」能給出很好的訊號；依你選的主題，還能在一兩個你想看的面向上取得強訊號。這個形式特別適合聽出他們如何談論自己的同儕與同事。
- 程式碼審查（Code review）。 準備一個 pull request，請候選人給予回饋，重點看同理心、清晰度與實用性。
- 資料建模、介面與架構。 請候選人走過一個系統的設計，通常聚焦在「如何演進它以因應需求變化」。這類面試常想做太多事：把焦點收窄，並為題目加上層次，好讓你能對取得顯著進展的候選人繼續往深處鑽。
- 領域專業（Subject matter expertise）。 測試他們專精領域的面試。例如前端工程師可能和設計師、PM 協作，討論技術限制會如何影響某個提案設計與上線時程；後端工程師則可能拿到一段壞掉的軟體或環境，請他們一路除錯到修好。
- 導師帶人小組（Mentorship panel）。 若你的面試小組全是資淺者，會很難招到 Staff-plus 候選人；但若候選人沒展現過成功帶更資淺者的能力，就錄用他同樣有風險。安排三到四位「未來可能被他帶」的人帶著問題來，看他如何把粗略框架的問題導向成一場有用的討論——這對洞察他在新角色中帶人的能力，是格外好的窗口。
如果這些形式還不夠，那就開口去問吧！多數公司都為自己的 Staff-plus 流程設計過客製做法，你能從那些討論中學到很多。
如何把它整合起來#
你或許合理地期待這節會以「一套可直接套用、拿來評估 Staff-plus 工程師的預編面試流程」作結——很抱歉要讓你失望了。我認為大部分的價值，來自你去想清楚「哪些訊號對你重要」，並設計出能以「對你和你公司而言合理的方式」觸及那些訊號的形式。
無論你最後採用哪些面試，都要去測試它們、蒐集候選人的回饋，並持續讓它們變得更好！