如何面試資料科學家? (How to Interview Data Scientist?)

本篇內容來自Daniel Tunkelang (Director @ LinkedIn’s Data Science Team)於Strata 2013的演講(投影片連結), 他探討面試一個資料科學家的方法以及其優缺點比較. 雖然他特別指明是”data scientist”, 但覺得他的方式挺適用於大部份的developer職位.

Daniel Tunkelang @ Strata13 — How to Interview a Data Scientist

How to Interview a Data Scientist

以下是Daniel Tunkelang闡述的幾個重點. (註: 斜體字部份是我的想法)

乾脆不要面試?!

好的面試方法就像藝術, 必須在短時間內interview跟interviewee都問對了問題, 才能讓雙方互相了解—也因此非常的難. 所以, 不如乾脆不要面試, 但用下列方式雇用candidates?

1. 只雇用認識的人: 如一起學習過, 一起做過projects等等. 畢竟可以從過往真實的經驗中知道他們的能力.
2. 雇用interns.
3. 利用短期契約(short-term contract).

第3點感覺跟台灣的”試用期”想法雷同, 但要能真正有效利用短期契約也許得先思考幾個問題:

1. candidates是否夠清楚desired目標及標準在哪裡?
2. candidates是否也能理解目標是合理的? 或是問題本身是可觸及的(tangible)?
3. candidates是否能明白此目標要測驗的能力是什麼? (e.g. coding skills or analytics skills?)
4. 此目標是否能讓candidates理解一個team的核心價值在哪裡?
5. 雙方是否有討論空間來合理訂定以上1~4?

這些讓我想到一個滿重要的面試者常會問的問題, “你們預期我在三個月, 六個月, 以及一年內的achievements是哪些?” 如果這些能非常清楚的定義, 那麼有助讓candidates在短期內了解部門的運作流程以及預期自己將能夠培養哪些能力, 或者要在這裡工作最重要的能力, 更能及早體認是否有足夠的動力在這裡工作.

上述僱用流程的問題

1. 若只雇用認識的人: 認識的人中樣本數太少了, 就像是最佳化問題裏的local optima一樣. 一來有可能產生公司單調文化(mono-culture)的隱憂, 二來很難找到足夠數量符合需求的人.
2. 若雇用interns: 要從interns裏面挑人成為正式員工, 必須要先投資一個成功的internship program, 但這代價可不小, 他們不僅僅只是薪資較低的職員 — 你必須花時間管理他們的工作, 可能換來不那麼正向的productivity; 即便找到了你覺得夠好的interns, 他們也許認為公司不夠好. 又或者一些interns隔年也不一定馬上就畢業開始工作了 — 這些都是長期投資的過程, 無法在短期內解決擇才的問題.
3. 若利用短期契約: 是一個很棒的方法 — 只對雇主而言. 因為對於傑出的員工來說, 不缺乏其他公司的全職合約, 那為什麼要付出這些機會成本?

“更自然的(More Natural)”面試方案

Candidates愈能享受整個面試流程, 愈能使他的能力被看到 — 所以要讓他覺得自在. 而有tight time constraint之下的面試(e.g. 30 minutes), 可能就會讓其感受到緊張甚至失常. 可能的方式也許是,

1. 花一天時間一起工作: 設立一個work session, 定義一個問題一起處理.
2. Take-home assignment: 讓candidate有時間花一天或是一個週末準備問題, 並且在充分準備下present給你聽對應的想法 — 付他們錢做這件事情也是可能的.
3. 檢閱過去的成果: 可能是從google scholar看publication, Kaggle看competition ranking, Slideshare看過去的presentation或是GitHub看repositories等. 這些成果都是他們在”natural condition”之下產出.

Still, They Got Problems

1. 花一天時間一起工作: 你可能會說, “ok, 我們來一起分析這些資料吧!” 但candidates不可能看過這些資料, 再者資料常是雜亂無章, 必須從Data Cleansing的步驟做起 — 非常花時間. 所以不可能期待candidates在有限的co-working time做完這些事情.
2. Take-home assignment: 如果candidates想辦法作弊? 尋求他人幫忙?
3. 檢閱過去的成果: 不可能每個人都把過往的codes上傳到GitHub吧, 可能是還沒完成, 或是codes的所有權是屬於其他公司的.

所以這樣看來, 繞了一大圈, 還是得依賴一個好的面試過程來衡量candidates.

面試的三個原則

1. 保持真實性 (Keep it real)—你該問些真正會遭遇到的問題.

談論這點之前, 先談談如何測驗coding能力—Data scientists必須要會寫codes吧. 面談中很難評估程式能力, 因為再簡單的邏輯問題都會有一堆在LinkedIn上看起來有經驗的coders或是資工系畢業的人答錯 — 例如FizzBuzz. 再者, 面試條件下寫code的方法也不一定代表你平常寫code的方法, 因為面試環境就是不那麼natural.

另外, 出白板題呢? 並且要求面試者上去寫codes? 這是個完完全全不natural的方式, 你大可以讓interviewee選擇他們喜愛的editor, 帶他們自己的筆電等 — 他們習慣的方式.

接著, 你會需要知道candidates是否善長演算法設計. 那來問個如何解根號的演算法如何? 或是來個re-hashing方法? 並且祈求inter-viewee記得教科書上這些基本的知識—如果他們學的夠紮實的話. 其實這些都是毫無意義的問法, 因為在工作上太基本的東西一般的tools就能幫你解決了, 為什麼需要由你自己來實現開根號呢?

所以, 這裡有兩個建議, 1. 問真實的演算法問題. 2. 請candidates談談如何設計你們的產品.

• 真實的演算法問題
  end user可能將關鍵字不小心連起來, 例如: bigdatascientist, 我們要怎麼自動解譯成其實他要輸入”big data sci-entist?” (在給定一個整理過的word dictionary之下, 推論一個較好的分割)—這是基本的字串分割問題, 但非常常被拿來做data cleans-ing或data manipulation.

• 請candidates談談如何設計你們的產品
  LinkedIn的search功能會將使用者自身職業納入參考, 不同職業之下的使用者輸入”archit-ect”, 軟體工程師將會搜尋到”軟體架構師”, 而若從事房地產相關人士將會搜尋到”土木建築師”. 所以, 你會怎麼設計我們工師的產品? 這已經不全然是coding問題, 而比較像是產品設計的問題—雖然你可能已經知道怎麼設計了, 但這仍然是個開放問題, 也許你可以與他們共同討論出一個更好的答案, 或是幫助他們探索出既有的答案, 更可能從interviewee身上得到免費又更好的答案. Again, 這是個真實存在的問題. 更重要更重要的是, 你能讓candidates知道, 你們公司的產品最酷的地方是哪些, 以及利用演算法解決公司真實遭遇的問題有多麼酷—回想如果你是問那些在教科書上寫的演算法, 你根本無法讓candidates感受到the coolest points of your company.

2. 不要想辦法考倒candidates (No Gotchas)

• 避免問那種”單一且特別的解法或見解才能解決的”問題
  此狀況下, 若interviewee答得出來, 那反映了他恰好有相關經驗, 並沒有反映出才智. 問這類問題並不能讓interviewee靠邏輯推論出, “喔, 我可以用某個graph algorithm或資料結構來解決.” — 就像前段所述的string segmenta-tion, 是有許多解法的.
• 避免測驗太深入的問題, 只測驗general但夠smart的techniques
  例如對於一般的computer science職位, 測驗string/set怎麼使用. 又例如測驗candidates是否懂machine learning可以從decision trees and regression問起, 而不是從某種非常特別的regularization方法開始. 原因是, 這些方法可能在on-board時就可以學到—如果工作上常用的話, 或是on-line courses就可能教到.
• 當個嚴格的interviewer, 但不要當個混蛋
  這是個interview而不是測驗抗壓性的時刻, 所以不要嘗試著想要把candidates考到哭為止. Interview比較像是在交換彼此價值的時刻, 應該要讓過程變得有趣—即便最後某個candidate沒有被錄取, 但他卻有”真希望我能進來一起跟這群人工作”的想法. (這讓我想到一個hearsay, 要評估一個team是否適合你, 可以從”你是否想變成面試你的主管的樣子”.)

3. 避免模糊地決定是否要錄取該candidate (Maybe = No)

• 每個Interviewer需要做清楚的決策(錄取/不錄取)
  而不是”我覺得maybe OK, 不如你也去面試他看看?” 或是設立一個5-star rating的制度, 這樣給個3-star給某個candidate, 本質上是很模糊的—強迫公司派出去的interviewer作清楚的決定, again, 錄取/不錄取. 同時interviewer錄取candidate之前, 必須要清楚這個人可能會做的比你好, 能力比你好; 相反的, 不錄取candidate之前, 也必須要明白, 若是data scientist在市場上的需求很高的話, 這個人將會加入另外一個更好的company.
• 每個團隊成員的意見都很重要, 並且相信他們
  兩個人說no, 或一個strong no, 都是no. 或者, 每個人都說maybe yes, 也代表no. — 所以, again, 強迫每個人做出清楚的yes/no決定—雖然面試完發reject letter對interviewee很殘酷, 但如果衡量程序不那麼保守, 繁複, 以及每個人都有意識的話, 等到該candidate進來三個月後fire他, 才是真正更殘酷的事.
• 嚴格的電話/視訊(phone-screen)面試過程, 確保現場(on-site)面試前就有一定的錄取率(如50%左右)
  這點也可說是為了不要浪費雙方的時間. 若視訊面試過程太鬆散, 那麼視訊完你可能會說”真的需要讓他來現場嗎?”, 這樣結果之下, 非常可能等到對方來了之後卻被你reject—這樣是在浪費時間. 所以視訊面試需要更嚴格—也許會讓你喪失good candidates, 但也會節省你很多面試candidates的時間. 現場面試的錄取率應該維持在50%左右. 這樣最大的好處還有, candidate會非常興奮自己獲取了現場面試的機會—因為意味著他離被錄取又更靠近些了, 也會讓他更認真看待這場面試.

如何衡量3C(Culture, Curiosity, Communication)呢?

Candidates是否能適應文化(Culture)? 他們有強烈的好奇心(Curiosity)嗎? 或是他們的溝通能力(Communication)如何? 這些不應該被當作獨立測項, 而是若你有讓team member也參與面試過程, 那麼他們自然能感覺到該candidates是否有3C.

小結以及Q&A Session

清楚記得一個事實—好的candidate難尋, 建議仍是上述三點, 保持真實性(Keep it real)—讓你的candidates被你們的產品所motivated, 不要想辦法考倒candidates (No gotchas), 避免模糊地決定是否要錄取該candidate (Maybe = No)—降低錯誤的雇用機會.

另外, 需要雇用人, 是因為有問題需要被解決, 若無, 則不需要雇用人. 面試software developer跟data scientist有很大的共通點, 無論如何必須要檢驗candidates對於真實存在的問題怎麼反應.

Strata現場有人問說, 要怎麼測驗Passion呢?
Daniel回答, 他覺得passion是一種sense很容易讓別人感受到. 如果你開始問candidate問題, 他們非常盡力的想要解決, 或者你問了個很難的問題, 他們並沒有覺得”OMG, 你到底想要我做什麼?”而是感到非常興奮, 這樣自然就能identify該candidate是否具有一定的熱情.

現場另一個問題是, 萬一candidate在interview真的提出了一個killer solution/feature而被公司採用, 但該candidate反過來告公司怎麼辦? Daniel首先表達他不是個lawyer, 也從未遇到這種狀況. 因為他覺得若是在一個30~40分鐘的interview內, interviewee就有能力提供這種level的solution, 他敢大膽的假設該公司並沒有做足夠多的努力, 或者是在外頭具有更富熱情的人在做跟公司內一樣的事情—(這席話讓我覺得他非常相信團隊內每個人都是帶著熱情在設計產品, 每個人都是一時之選!)

感想

我的感想應該是最不重要的XD, 但我覺得面試過程是一個溝通的過程, 不該是單方向—公司選人, 人也選公司這是必然的. Interviewer是否盡了全力要來了解你, 也讓你了解公司, 並且pinpoint最適合你的位子, 你的角色, 是否跟團隊的核心價值一致; 你是否在面試感到自在, 在沒有預設立場下(例如, 我管你進來做什麼, 我就是要進LinkedIn XD)對公司在做的事情覺得有趣, 以及合乎你真正想要做的事情. 林林總總才造就一個合宜的面試經驗.