面試流程最佳化的反思

A-Tsai
8 min readOct 11, 2021

--

圖一、線上刷題補習班的有趣比喻 [1]

最近聽到一位前同事準備找下一份工作而努力每天上 LeetCode [2] 去刷題,因為他想進 FAANG 等大公司,而這些公司目前面試流程的第一關就是刷 LeetCode 上的題目,網路上也有很多人分享如何刷題進大公司的文章 [3,4,5]。

其實早就聽過 LeetCode,但認為這平台只是一套給大學生參加程式比賽時的練習系統,或者是剛從畢業的新觧人準備找第一份工作時,程式部分不知從何準備起在用的。不過,剛剛試玩了一下,發現整套系統使用者體驗超棒、考題豐富、分類清楚,的確是個練功的好去處。

我曾經遇到面試官在白板上畫一個圓,問我想到什麼的技術。回想我參與過面試流程最佳化的演進,試著從以下三個面向來進行探討:

第一層次 — 面試官

因為曾在大公司和新創待過,發現兩者的面試最佳化流程非常不同:

大公司上班間期

之前在國內知名的軟體公司當第一線主管時,公司己經有一套蠻成熟的面試流程:

  • 第一階段 — 大海撈針期:用人單位跟 HR 說這次打算找怎樣的人才,HR就會從 104 等線上人力銀行幫我們過濾出合適的人,再將履歷寄給我們用人主管。
  • 第二階段 — 雞蛋裡挑骨頭期:用人主管要從 HR 寄來的一堆履歷中找出合適的人選,再請 HR 幫忙約到公司來實體面試。
  • 第三階段 — 我愛紅娘期:實體面試有兩關,第一關是筆試,包含觀念題和程式題;第二關是口試,通常是一對一面試,有時面試者太搶手或時間有限,就會多個主管同時對一位應徵者進行面試。

然而,在這最佳化的過程中,卻慢慢走向局域最佳解的結果。HR被某些主管抱怨怎麼每天都寄一堆履歷,看都看不完。不然,就是抱怨怎麼都寄一些不合適的人選,所以 HR 在過濾人選時越來越謹慎,最後最佳化的結果就是只寄「台清交」畢業的人選就好。

不過,前公司在選才的過程給用人主管很高的彈性,有些主管會直接跟 HR 要104帳號來過濾履歷,有些主管會在面試前先請應徵者來幾題上機題,有些找來面試的第一關筆試太差,就直接跟 HR 講請對方回去。當然,也常有透過內部推薦的方式來找人。基本上,應徵者遠多於聘任員額,也就是供大於求的情況,所以通常可以在短時間找到合適的人選。

新創上班間期

跟之前的大公司不同,在新創找人基本是供不應求,因為好人才都被台積、Google、微軟等大公司搶走了。因為我們是没没無名的小公司,所以我們通常是主動出擊,透過校園授課或公開演講來吸引同好。另外,我也常利用 Facebook 分享一些工作的心得或成果來找志同道合的人。

由於我們使用的技術非常廣,從雲端到地端、從科研到臨床、從標準化到最佳化、從自動化到客製化、從Multi-Thread到Distributed Computing、從Data Integrity 到 Data Security、從 Interaction 到 Regulation、從Genomics到Multi-omics、、、等,所以我們找人的重點不是看你己經學會「什麼」,而是你「學會什麼的潛力」。另外,至於「什麼」根本不重要!重點是釐清你之前學會的「什麼」倒底學了多深入。

前幾年,我們一開始都直接約面試者來公司面試。只是,通常面試聊不到 5 分鐘就知道合不合適了,所以若覺得不合適,就會馬上改變策略,協助受試者進行生涯規劃及適性發展,也會協助推薦到其它更合適的公司。因為我們是誠心感謝面試者接受我們的面試邀約,雖然無法錄取,但希望至少盡力協助對方成長並結個緣,將來說不定還會有緣合作。

只是這樣做太花時間了,而新創最缺的就是時間了。所以這幾年改成先 phone interview,這樣遇到不合適者,雙方都可以不用浪費時間。而且一開始不是聊技術,而是開門見山地表明我們平常 team work 的方式,很多人都會被這樣的面試方式嚇到,因為我們溝通都很直接,不需要因為面試去假裝或包裝自己,因為在「很直接的溝通」時,每件假衣服都會一一褪去。若個性合和心態對,再來就是約時間直接跟團隊進行技術深度交流。

這次一直在想要不要把 LeetCode 也加進面試過程中,結果是否定的。原因就在「魔球」(Moneyball)[6] 這部電影中。若是照大公司的方式來找人,我們的薪資與福利沒什麼競爭力(雖然我們堅信產業前景與技術研發深度等優勢),所以得從不同角度切入才有機會發掘好人才。另外,Coding 的能力可以從應徵者的 GitHub 或其它作品來了解,還有直接問幾題深入的技術題就可以了解七八成。更何況我們有興趣的「生物資訊」領域大部分的人選都是來自「生物」背景,沒有接受過寫程式的正規訓練,就算是「資訊」背景畢業的,在學校也沒受過完整軟體平台開發的訓練,所以我們很清楚要找的人不是他/她己經會什麼,而是「學會什麼的潛力」。

第二層次 — 應徵者

對應徵者的面試最佳化的第一步,就是上 LeetCode 刷題去,因為這是現在市場上的主流。

個人對「利用 LeetCode 刷題來準備面試」這件事完全沒問題,但我想提出的問題是「因為要去面試,所以開始刷題」這件事。

對新觧人而言,若其對寫程式有興趣,應該平常就會去刷題,也會參與一些 Open Source Projects 來增進自己的能力才是;對己經工作一陣子的人,平常工作就會需要寫程式,應該會常用到這些資料結構、演算法等技能,所以這方面根本不需要額外透過 LeetCode 來練習才是。

所以,「因為面試才開始刷題」有兩個可能性:

  1. 對新觧人而言,你想要自我突破,但這並不是原本的你。
  2. 對資深工程師,你目前的工作上根本用不到 LeetCode 上這些題庫的技能。

很怕應徵者不是「真心喜歡寫程式」,而是喜歡去「FAANG」等大公司上班。類似以前考聯考,補習班會推出「考前衝次班」、「台大保證班」等。若不是真的喜歡寫程式,就算拿到 Offer 了,相信也無法久待。

另外,相信每個人在寫程式的領域中都有自己的專長,演算法只是其中的一項,還有很多是演算法以外的知識與技能。在LeetCode上大部分都是這方面的題目,所以我才會覺得它像大學時參加程式比賽才會用的平台。

還有,遇過不少只為了「錢」的應徵者,我們在新創初期會盡量避免,原因是:

會為了錢而來,也一定會為了錢而走。

一家企業總會有遇到瓶頸的低潮期,這時,先跳船的一定是這群人。我了解很多離職的原因都是因為錢沒給到位,但身為經營者後,為了讓公司繼續經營下去,必須做出一些困難的決定。我們也曾歷經兩次好幾個月發不出薪水的艱苦時期,感謝相信我們一定可以的好伙伴們一路堅持下去,這些過程今後一定可以自豪地跟別人說上好幾個晚上(前提是我們得成功才行)。

第三層次 — 旁觀者

如同最佳化一個機器學習的模型一樣,常在 Precision 和 Recall 之間的決擇。很明顯地,LeetCode 成為面試第一關是為了提升 Precision 而犠牲了 Recall,如幾年前發生 Max Howell 第一關沒過而被 Google 刷掉的情況 [7]。

然而,成為刷題高手真的是公司要的人選嗎?

當然不一定,我絕對不是要誤導大家不要去刷題,而是要進一步了解刷題能培養的技能並不是全部。

我們公司內部會議常會提到 「Developer」與 「Programmer」的差異,在 LeetCode 上成為刷題高手只是讓你成為「Programmer」而己,因為你學會如何解決別人定義好的問題,但並不能證明你是位「Developer」。

另外一個觀察,就是 FAANG 等大公司把 LeetCode 上刷題當第一關,應該就是要即戰力。換句話說,就是不想花時間培養員工寫程式的能力,應徵者應做好心裡準備。

就如同去相親,男方一開始就跟媒人婆說要白白的和留長頭髮的女生才要去一樣。現在的 FAANG 就如同這樣,設了一個這個前題,但相信很多好女生是曬得很健康或留短髮。所以每個人都可以對自己的技術很有自信,如同被 Google 刷掉的 Max Howell 一樣,大家還是視他為大神。

結論

從人類基因體的變異點來看,大多數的變異點都不是壞事,而是讓人類的個體產生多樣性。好男生的定義不是只有高、富、帥這三個條件,還有聰明、體貼、溫柔、老實、有愛心、工作認真、待人真誠、有同理心等優點都算好男生。那為什麼好員工卻可以用一種方式來篩選呢?

藉由本文的探討,讓我更清楚知道公司該怎樣找好人才,也讓我更清楚接下來個人的技術地圖該往那裡開發。希望以上這些討論對您在生涯規劃上有些幫助,並祝大家都能找到理想的工作。

參考資料

[1]https://me.me/i/here-do-c-leetcode-60bb5dc181e0491bbcbf0b42fd7b1a53
[2]https://leetcode.com/
[3]https://tw.alphacamp.co/blog/leetcode-introduction
[4]https://www.dcard.tw/f/tech_job/p/235326118
[5]https://glints.com/tw/blog/leetcode%e5%88%b7%e9%a1%8c%ef%bc%9a500%e9%a1%8c%e5%be%8c%ef%bc%8c5%e5%80%8b%e9%87%8d%e9%bb%9e/
[6]https://www.youtube.com/watch?v=EntXQjSdUMw
[7]https://www.ithome.com.tw/voice/97188
[8]https://crossing.cw.com.tw/article/10739

--

--

A-Tsai
A-Tsai

Written by A-Tsai

Practitioner of Multi-Party Computation

No responses yet