那天晚上，我正在回想面試中間我最出彩的表現。讓我那次表現特別有趣的，不是我做得『有多麼好』，而是我『如何做得很好』。以及對自己以及整個過程不滿意的地方。

我那時正在應聘一個軟體開發的職位，這個公司的面試流程先是電話面試，再到程式設計測試，最後才正式面試。我在電話面試中表現得很棒，那位招聘人員也說公司對我很感興趣 —— 我心想有戲了，一切努力都沒有白費。

雖不知那位招聘人員的具體評估是怎樣的，但那個公司給了我程式設計測試的機會。面試是發生在我讀研的時候，而且我當時正在學的一門課叫“高階資料庫設計”，主要是講找可靠的方案來替代傳統的、關係型的資料庫。當時聽著可能有些超前，因為 NoSQL 運動尚未成氣候。

當他們發給我程式設計測試題的時候，我已經學了一單元如何用 JUnit 來儲存地理資訊的內容了。這單元包括 JUnit 是什麼、以及怎樣用和一點偽碼來梳理一下知識點。無巧不成書，JUnit 剛好成了我的必殺技。

分析下我為什麼能拿下這場面試

那次面試對我來說簡直就是小菜一碟。因為我知到我所學的可以用在這面試裡，同時我還這麼做了。我用幾個自動化測試來驗證，將其用在測試裡以至於整個測試都做的非常快。

我甚至都不用看招聘人員的反應就知道考官們都驚呆了。所以他們直接給錢讓我過來參加最後的面試並且告訴我這是目前為止他們所見過最好的方法。我感覺我好像奪寶奇兵裡的英雄一樣，古老的門衛等某人來用 JUnit 解決程式設計測試問題用了一千年。

我最後過了整個面試，但只因我有更好的機會而到別的地方去時，他們對我有點失望，告訴我要是我改變主意隨時聯絡他們。我喜歡這家公司，另外，這次經歷讓我感覺良好。

然而，當我回顧這次經歷時感覺有點怪怪的。毋庸置疑的是，這裡有很大成分都是運氣，就像公司這麼看好我一樣。恰恰就是我幾周之前做過練習，不然我是不會用 JUnit 的，要是我遲幾個月做練習的話，我可能也不會用 JUnit 了。要是我沒做過或根本不知道 JUnit 的話，我還能打動考官麼？所以我這次史無前例的面試只是我走運而並不是說我原本就是大神。

在應聘時不要害怕失敗

你有沒有試過在面試時做一些你根本不會的題？如果你有機會去 Google 面試的話，首輪電話面試就像一個口頭的大四Java程式演算法期中考試一樣。O 符號、排序演算法 和其他東西等。所以這些公司絕不是個例，他們的面試過程被奉為經典。

為了在面試時不那麼被動，你應該在應試前努力學習，做到可以回答所有的技術問題。但你永遠也不知道他們會怎樣刁難你。重點是你永遠不知面試時他們會問你什麼，或者你和你的對手最近學到的哪些知識剛好能用在面試上。

你可能會遇到像我這麼走運一樣的人，剛好知道這個問題怎麼解讓考官對其有好感。要是真的發生了，那也只能怪你的運氣不好。

所以你不應該為此失落。因為這種面試其實是不嚴謹的、不科學的。被拒了並不代表你的能力不行。僅僅是你的運氣差而已，沒有看到能讓你通過的答案。

招聘時要注重正確的事

看看你們有沒有像上面那些例子一樣招聘的？在所有人相同條件的情況下是否招了像我一樣走運的人？如果是這樣的話，我建議你好好反省一下看看你的招聘方法有沒有問題。

我認為在招聘的時候應該瞭解其中的幾點，以這個人會什麼、這個人做了什麼和這個人能做什麼為標準。這些標準在大多數情況下都很有用但也很難判斷。

但至少面試時會什麼還是有用的，雖說人花一生時間去學習但忘的也很容易。但這也很容易看得出是不是會，做一些小測試和用一些像你面試過程中的一些東西就行了。

判斷一個人能力怎樣，雖說有點棘手，但這是最有用的標準。雖說他們有簡歷和經歷上，但這很有可能是個忽悠。就拿 JUnit 來舉例，你可以測試他們是否只是說說還是真的會 JUnit 。但如果之前他們就知道怎麼用的話，而不只是說說，那真的是極好的。

對於以上兩個標準來說，最重要的還是要看看這個人面對需要用 JUnit 解決的問題時，是否會做一些基本的學習然後去解決它？這是你需要知道的。同時通過‘做一些基本的學習然後去解決它’的行為也能間接地瞭解這個人的能力。

最後，我不敢說什麼是最佳的招聘方式。評選一個人是很難的。但我可以跟你說如果你越會評估應試者的能力，你就越能招到最好的人。

寫在最後

相關推薦