軟體人才並不難找
但是你的面試方法可能會妨礙你找到他們。
Blake Callens是PencilBlue公司的聯合創始人及CEO,也是 Raleigh創業加速實驗室的聯合創始人。是ExitEvent的中堅力量。
每一個軟體工程師都經歷過這樣的面試，在面試中，他們被迫使表現的更像是一個字典，而不是人類。普遍存在的誤解是，為了能夠開發軟體，程式設計師必須知道職位要求所列出的每種語言的每一個細節。過去，程式設計師需要從手冊上獲取這些知識，這種面試是那個時代遺留下來的產物了。
對於有經驗的程式設計師，如果這樣面試他們，他們通常會認為這個公司不入流，與此同時，很多公司因為在面試中沒有考察創造性，也錯過了非常好的潛在僱員。
有一次，我進行了一次長達一個小時的電話面試，他們一直問我在JavaScript和jQuery中，變數的命名和方法有什麼不同。而不是一個與我在實際工作如何利用web技術完成商業目標的經驗相關的問題，儘管這是在招聘一個跨國企業的領導崗位。
有很多次，我不得不聽非技術人力資源經理磕磕絆絆的問出那些由技術領導給他們的“資格審查”問題。顯然這些面試官們本可以使用星際迷航裡面的嘮叨術，因為他們只會這個。
這些問題通常帶有出題人的偏見；更多時候是“我是怎樣做事的”而不是“它是如何工作的？”當然，面試官並不知道這些。如果面試者的回答不符合那個唯一的答案，則會被標記為沒有答對。
有一次我被安排進行現場程式設計，他們讓我在瀏覽器視窗寫一個JavaScript應用(沒有等寬字型可以用，而且按一下tab就會跳出輸入區域-但是，我的書寫格式卻要被他們所評判，這是當然的了。)在提交程式碼前，我沒有辦法去測試它，因為面試官就看著我寫，然後複製貼上到瀏覽器中。
這是一次我至今還感到得意的壯舉，這個程式第一次啟動就完美的執行了。面試官隨後坦率又無禮的向我介紹了他個人解決這個問題的方法。他顯然花費了很多時間思考和重構了這個方案，而不是像我一樣進行現場程式設計，而且這個方案中包含了更多的個人喜好而非改進。
上述面試經歷，與問我SAT分數的那個面試官一比，就都顯得蒼白了。那個時候我已經34歲了。
這些情況真是徹徹底底的荒唐，我並不是單指這些人，而是因為現代軟體開發的一條不言而喻的真理：開發軟體，其中4分之3是要知道程式設計的總體思想，並且知道如何串聯這些知識。剩下的你都可以通過Google來搜尋。
不信我？這裡有一些你可以在“最佳面試題”裡面找到的技術面試問題：
- jQuery如何將一個單擊事件繫結到一個文件物件型別的物件上?
- 在C#中如何讀取檔案？
- Java支援哪些資料型別？
有兩件事，比其他任何事情都更能阻止你找到並僱用最好的軟體工程師：
- 專注於純粹的技術知識而不是實際工作經驗。
- 想要得到意見的一致性而非差異性..
問競聘軟體工程師一些業務問題，因為這些問題在你僱用他們之後就會遇到。問一些和你正在面對的現實中的挑戰相關的問題：
- 我們的客戶想要把一個再銷售售貨機整合到我們的銷售終端系統。你有和email銷售和（或） REST API打交道的工作經驗麼。
- 現有一個類似Photoshop的應用。你怎麼建立它的前端？你想用什麼技術？
- 你對公司使用的技術有什麼建議？它有什麼強項或者弱項？
這三個問題都可以把談話帶向更深入的技術問題，這些問題可以涵蓋軟體工程師正確完成他的工作所需的知識。這三個問題都不會讓應聘者不得不去證明他們死記硬背屬於的能力。你也可以更好的瞭解這個人將要如何進行團隊合作。畢竟，教會一個人專業技能比教會一個人如何和同事互動容易的多。
告訴你的技術領導人員，當應聘者回答這些問題的時候，他(她)可以挑戰應聘者的看法，但是前提是可以這麼做可以推進對話。任何情況下，都不能告訴應聘者技術面試官的個人程式設計喜好比他們的強。
這是一個技術面試官非常容易犯，又具有毀滅性的錯誤，這一錯誤會滲透到方方面面而不單單是面試。只有當這些迫使你完全按照他們的指示行事的領導被解僱，問題才會得到解決。一個軟體要想是健康的，開發者必須在構建和維護中能夠提出多樣的點子。
當一個程式設計師不被允許在團隊創作軟體時加入自己的想法，會錯過很多改進軟體的機會。那些通過在專案中融入自己獨特經驗並可以讓產品變得更好的優秀軟體開發者會在看到傲慢的技術領導後轉身就走。
總的來說，當你招聘一個軟體工程師的時候有件事情必須謹記，招聘他們與招聘其他任何技術工人沒有任何區別。你不會去要求一個銷售崗位應聘者去複述高德納發展規律週期的每一階段，所以你為什麼要這樣對一個軟體工程師呢。
打賞支援我翻譯更多好文章，謝謝！
打賞譯者
打賞支援我翻譯更多好文章，謝謝！
任選一種支付方式
