歡迎光臨
每天分享高質量文章

14 年經驗程式員的吐槽:如何招不到程式員?

【導讀】:咦,怎麼是招不到程式員?標題沒寫錯麽?嗯,沒寫錯,國外程式員 Nikita 最近寫了一篇文章《How NOT to hire a software engineer》,吐槽大公司在招程式員的一些不合理的做法。

一起來看看他是從哪些方面吐槽的?吐槽的是否有道理?

—-

我不是大公司的招聘專家,但我是一個有 14 年工作經驗的程式員,對小公司招聘還是有較多經驗和一點常識。

早在 2013 年,我為 AboutEcho 組織了一次非常成功的招聘活動,最終招聘了 9 名高級工程師。

這讓我有信心來聊聊如今互聯網巨頭招程式員的做法。

(插圖來自 Yulia Prokopova)

1、不要面試時追求最佳解決方案

當求職者到達面試現場時,面試官給出一個問題,並希望在 2 分鐘內得到解決。如果花的時間更長,他們就會開始擔心,至少會要求你做點什麼。

我能理解,畢竟他們只有 45 分鐘,他們有很多事情想和求職者一起經歷。

我不能理解的是,面試官是根據求職者在 2 分鐘內想出的解決方案的質量來評判。因為那不是人類創造力的工作方式。想出很多點子很容易,但期望最佳點子總是第一個出來就很奇怪了。即使是天才,也無法在幾分鐘給出世界上的最佳解決答案。

創造力是評估和過濾你所想到的想法的能力。如果你們真的對此感興趣,為什麼不讓求職者來比較和評估多種解決方案呢?然後判斷求職者是否能夠評估解決方案的性能?求職者是否能清楚看到所有的優點和缺點?

如果要求在幾分鐘內想出最好的解決方案,你們測試的是運氣,僅此而已。你們是在雇佣幸運的員工嗎?還是招能力的員工?

2、不要在面試中問謎題

如何檢查鏈表是否有迴圈?一個 N 維的盒子能裝進另一個 N 維的盒子里嗎?你能在沒有第三個變數的情況下交換兩個變數嗎?如何找到兩艘行進中的船之間最短的距離?

別誤會我的意思,這些謎題很有趣,討論起來很有趣,解決方法也很有見地。我以前還是個孩子的時候,我就喜歡看《Mathematical Recreations and Essays》。

然而,不管謎題有多有趣,它們只是一些軼事。謎題的性質是,你要麼知道答案,要麼不知道。它沒有告訴你其他任何事情。它與未來的表現無關,與聰明、能力或其他任何事情無關。知道一個特定的答案,並不意味著你可以採取通用和可預測的方式去解決實際問題。它告訴你的唯一一件事是,當某人與他人分享一個解決方案時,那這個人已經有了一種解決方案。不多也不少。就夠了。

(蠟燭燒斷繩子之前,你會如何自救?)

3、接受其他選擇/解決方案

這在某種程度上是意料之中的,但大公司似乎仍然在這方面失敗了。如果求職者提出了另一種解決方案,這是面試官學到一些東西的機會。如果提出的解決方案不可能實現,或者不太好,這也是一個深入討論的好機會。

儘管如此,我還是因為曾經提出過一個同樣複雜的替代解決方案而被 pass 了(而且我背負著一場關於“解決問題的真正方法”的講座)。另一次面試時我引入了一個特定的解決方案,面試官急迫地忽視我所有考慮到的,只想討論他認定的解決方案,後來面試官對我的反饋是“沒啥印象”。

沒有人知道所有的事情。放開心態,傾聽他人,多思考。是的,即使你在面試他人。

4、容忍瑕疵

由於某種原因,單位元組上限溢位(Off-By-One)錯誤被廣泛認為是 CS 中最難的問題之一,幾乎每個人都會犯此類錯誤。錯誤是程式員生活的一部分,並不是你可以擺脫掉的。優秀的程式員知道該怎麼做。程式員的素質,並不取決於他/ TA 犯的錯誤有多少。

現在,如果你只選擇那些在面試中沒有出錯的人,你就能得到一群總是能寫出完美代碼的程式員。你只是不知道當他們不可避免地犯錯誤時,他們會怎麼做。

所以犯錯其實是件好事,因為你會瞭解到求職者是如何消除錯誤的。不要只看到錯誤,而是要看求職者是如何處理錯誤的:

  • 簡單的代碼

  • 分治

  • 自檢

  • 不變數

  • 斷言

  • 編譯和運行

  • 測試

噢,不好意思,最後兩項。我都忘了你們在面試時不會讓求職者運行程式的。那你們還指望什麼呢?

5、讓我測試!

說真的,在白板上寫程式有什麼用?

我的意思是,我寧願在面試時討論演算法,討論抽象的東西更有效率。

但是在白板上寫程式,真正的程式?甚至不用運行?這樣有什麼意義?

獲得代碼初稿,僅僅是編程整個過程的十分之一,接下來是編譯、檢查、調優、測試、評審等等。我們在開玩笑吧?這些是任何程式員工作流程的基本部分。代碼只有在經過所有流程之後才適合查看,而不是在此之前。

這就好比你讓一個畫家畫馬,然後在第一次畫的時候,當你看到四條線代表腿的時候,讓 TA 停下來,然後判斷。你會對 TA 有多少瞭解呢?

6、深入點吧

整 5 個簡短的面試題呢?還是搞 2 個長點的面試題?

有了 5 個題,你就有了 5 個獨立的意見,這比 2 個好。但 45 分鐘能挖多深呢?實踐表明,45 分鐘僅僅編寫 20~30 行代碼並問幾個非常簡單的問題(複雜度是多少?如何測試它?)

下一個面試官只是簡單地重覆同樣的過程,和前一個面試官一樣。這並不夠,一點也不夠。

為什麼不寫 2 個呢,但要寫得很全面?午飯前 1 個,午飯後 1 個?3 個小時也不算多,但至少你有機會瞭解求職者如何測試代碼、如何更改代碼、如何處理需求——所有這些都是前後相關中進行的,而不是每 45 分鐘就重新開始。

有了這麼多時間,你甚至可以讓 TA 把代碼編寫成一個系統的一部分,而不僅僅是一個抽象的演算法任務,並瞭解 TA 在現實世界中的表現。

如果你想要更多的意見呢?讓多名面試官在一個房間里,然後讓他們辯論。

7、多瞭解求職者的背景

我的意思是,我有 14 年的工作經驗。我很樂意談談函式式編程、分佈式系統、一致性、復用(replication)、協作文本編輯、CRDTs、並行架構、UI框架、團隊流程、產品設計和用戶體驗。我在這些領域都有實踐和研究經驗。它們都或多或少與我面試過的互聯網巨頭有直接的利益關係。

有人問過我這些問題嗎?沒有。

我得到的面試題是“假如你有一個函式,要用一個串列……”,連續 5 次。5 個學校級水平的面試題,能給你們一個足夠深刻的印象麽?我讀科曼等人的文章有多透徹?公平地說,你也很少被問到這些問題。

相反,要根據求職者的經歷來調整面試。談談 TA 擅長什麼。那你們將有機會提出更深入的問題,瞭解更多關於 TA 的經驗水平和 TA 能為公司帶來的好處。

8、無縫流程

方向錯了?推遲票?需要特別安裝 Adober 閱讀器才能打開的調查問卷?廉價的超極本配著不熟悉的鍵盤佈局,基於 Web 的糟糕編輯器,沒有任何快捷方式。打擾一下,我這還是在全球知名 IT 公司的辦公室面試嗎?

在我遇到的中,一個面試官每天要安排 5 次面試。每天 5 個人,乘以公司面試官的數量。想象一下,所有求職者都對這個過程感到有點沮喪。日復一日,年復一年。

你可能認為這無關緊要,還得視情況而定。電視劇《Louie | 路易不容易》中有一集,一個喜劇演員發現房門上自己名字被拼錯了。所以他爭辯道:是的,這是一個容易犯的錯誤,但也是一個容易糾正的錯誤。

是的,我相信任何人都能做得更好。

結語

如果你所在公司在招軟體工程師,大公司的那套常規做法不是你的「朋友」。常識、公平、寬容、真正的興趣和開放的心態,這些才是你的「朋友」。

好好招聘咯!

    已同步到看一看
    赞(0)

    分享創造快樂