「謙虛」、「飢渴」、「聰明」這三個關鍵特質，是由 派翠克·蘭奇歐尼（Patrick Lencioni）在《理想的團隊合作者》中所提出的理想團隊的特質。我認為這是個相當好用的評估框架。
特別要注意的是這邊所指的 Smart 並不只是 Book Smart 而已，而是指情商高、互動能力強，能理解和管理自己的言行對他人的影響。理想的同事應該同時具備這三個特質，不過以開發職來說，我認為智力上的聰明還是相當必要。不是說那種一定要從小打數學奧林匹克競賽，打程式競賽，而是有動手解決問題，不斷挖深的能力。
如果是初階工程師，只要具備 Smart + Humble 就可以了。但不可以是這兩個組合：
聰明與飢渴，雖然在做產品或是開發時會有更多想法，但隨之而來的是可能會一意孤行不顧團隊意見，對我來說只有 Smart & Hungry 在組織內通常無法發揮得很好，甚至容易對團隊帶來傷害。Humble + Hungry 就更不用說了，組織不需要謙虛但事情總是做不好、眼高手低的人。
Vue 的作者 Evan 就曾經提過，有些人是真的很聰明，但他會否定任何你提出來的意見。這種人通常沒有辦法讓專案順利進行。
https://x.com/saucedopen/status/1798973109598351683?s=46
Some people can be very technically brilliant but disagree on almost everything with you
Humble + Hungry 還有一種可能性是他其實很聰明，只是因為太謙虛而沒有展現出來。這類型的人可以從多問專案內容下手，讓他們在自己擅長的領域大展身手。
由於現在更看重解決問題的能力，一般還是需要根據公司想要的人才調整策略：
Denny 曾跟我分享一篇 DHH 的文章《You can’t fix core competency with a stern conversation》。DHH 認為如果新的雇用狀況不理想，通常可以把情況分成兩種——Engagement 與 Competency。
如果是 Engagement 的問題，例如溝通、協作不符合預期，那麼很簡單，只要跟他講開來，對齊彼此的認知與目標即可；如果是工作能力的問題，靠對話並沒有辦法解決。DHH 的論點是專業技術能力需要花很長時間培養，如果他呈現出來的就是這樣子，期待用對話得到改變是不切實際的想法。
我覺得 DHH 這篇寫得很好，也是後來我評估人選的方式之一。任何候選人提到的專案，只要有寫上來，我會盡可能把細節問到底。是不是真的有實作過，還是改個小東西就直接掛名，蠻容易在這個環節就確認完。
另外我會做的事情是現場 live coding。不一定要是完整的程式碼，可以是簡單的功能實作，語言特性（用 JavaScript 總要知道非同步吧），一起 Code Review。而且我也不排斥，甚至鼓勵面試者可以用 AI 輔助。
我想觀察的有幾點：
雇用很難，尤其在新創公司中，若是不適任的人選，往往會對團隊的士氣造成很大影響。在短短的面試裡要找到有潛力的候選人，不得不說跟抽籤有點像。在這種情況下，只能採取提高精確率的做法。這件事我到最近才意識到。前陣子總是想著海納百川，只要履歷還不錯就面試，但面試後才發現與想像中落差極大。在資源有限的情況下，只能從更客觀的數據去做篩選，學歷、任職過的公司、經歷、專案。
資源有限的情況下，應該要以優化人才精確率為目標做雇用，而非提高 Recall。
由於面試者沒在公司內部工作過，所以對公司的印象往往來自於面試官與面試流程。因此面試過程不僅僅只是找到合適的對象而已，面試過程的好壞會影響公司的信譽。我在面試時會盡可能把握以下原則：
很多面試官以把面試者問倒為目的，然後洋洋得意地在社群媒體上諷刺面試者。我對這種風氣不以為然，感到非常厭惡。就先不論問題的難度如何，今天面試官用著「你連這個都不知道你還敢來應徵」的心態來看待一位面試者，這注定是一場無效面試了。
講了那麼多，最關鍵的大概就是——把人當人看。
當然面試是雙向的，如果覺得已經得到足夠資訊評估，大方一點說聲：「我已經得到足以評估的資訊，不妨提早結束吧」也是一個方法。
iThome鐵人賽
看影片追技術