最近一段時間都在做集中招聘，參加了許多面試，累個半死。加上之前在團隊中最近幾年也做了不少面試，關於測試工程師招聘的話題，剛才沒事特意google了一下，除了一些面試題外居然沒有幾篇心得方面的文章。上午招聘輪空，抽空寫一下自己的看法，僅供參考。記得看完即焚。
所有團隊的招聘，基本上都是要找最“合適”的人，而不是技術最強的人，或者最優秀的人。技術最強的人不一定合適，原因有很多，
1. 崗位一定的情況下，並不需要超出崗位能力特別多的人，完全沒有這個需求。
2. 價效比問題。因為這些人比較“貴”。如果不給比較高的待遇和級別，無法吸引這類候選人。
3. 如果團隊的整體技術水平是6分(滿分10分)，但候選人是個10分，你覺得他會很樂意跟水平是6的人合作嗎?就像把詹姆斯請到cba來打球，即便你付得起薪水，詹姆斯自己也會很鬱悶，在他眼中“不怕神一樣的對手，就怕豬一樣的隊友”。
4. 對管理的挑戰比較大，一般來講，強人一般在融入團隊方面有點小問題，除非遇見了比他更強的人。可以參加下文的非技術部分。
招聘的目的就是要找到最“合適”的人，跟結婚很像，要選擇跟自己搭得上的，自己不帥還要那些臉蛋漂亮、身材火爆的，沒用，早晚得離，弄不好還給自己帶一頂綠帽。
在團隊管理中也要充分發揮每個人的長處，揚長避短，讓合適的人做適合的事情，才能讓團隊的貢獻最大化(這是另外一個話題，以後有時間再寫)。所以在招聘中要試圖去發現候選人更多的優點，而不是找他的缺點。你很容易就用一道特別難的題把候選人給問住，或者使勁在他不熟悉的領域讓他難堪，除了打擊一下候選人的自信之外沒啥意義。所以整個面試過程中，多數時間都花費在找優點上。只要不是特別嚴重的缺點，都可以通過後期的團隊管理來弱化其影響。
技術方面
首先要確定，測試工程師是一個技術崗位。為了彰顯這一點，許多公司都把測試崗位的 title 改為測試開發工程師，像微軟的sdet(software design/develepment engineer in test)、谷歌叫set(software engineer in test)等。純粹的手動黑盒測試工程師早已不復存在。所以，技術技能是最基本的要求，我會針對初級崗位、高階崗位或專業崗位的不同要求來講對招聘的要求。
程式碼能力
對於測試開發工程師的招聘，由於其是基礎崗位，要求也是最基本的編碼能力，所以針對這類崗位，我一般會花費80%的面試時間在技術考核上。之前很多團隊遺留下來的惡習，總是覺得測試對技術的要求不高，強調“Test Sense”的重要性，我不是否定它的重要性，但對於應屆畢業生或者初級崗位的人，壓根兒沒做過測試，他有個屁的test sense，還不如去花點時間考核候選人的邏輯思維能力靠點譜。我一般喜歡讓候選人現場寫寫程式碼，對絕對不是那種巨**的演算法問題，一般都是二分法、字元處理、簡單資料結構相關的小題目，只是想看看候選人有沒有基本的程式碼功底。在review程式碼的時候可以有針對性地對編碼語言的一些關鍵字提問，看看候選人的程式碼掌控能力。基本上，只要能把自己想法通過程式碼實現且沒有大的邏輯錯誤，在程式碼考核這一關都會放過。但如果要得到很高的分數，那必須在程式碼的可讀性、異常處理、演算法效率、可測試性方面有比較好的表現。我認為對於測試工程師來說，寫程式碼的能力是必須要有，但不一定要求到達“精通”的地步，特別是在演算法效率方面。很多的測試工作，都是在工程系統的驗證層面上，你要那麼牛逼的演算法背景做甚? 未來轉崗去開發嗎?有人可能會在這裡崩出來說了，編碼語言不精通說明潛力不足。潛力是什麼?潛力只能說明你現在能力很差而已，有很大的上升空間。幸虧我寫這篇文章的時候只是沉溺在自己的思維世界裡，否則還不被那些唱反調子的人給噁心死。好了，繼續聊我的。具備了基本的程式碼能力，可以寫自動化的程式或者工具即可。在測試程式的演算法效率和巧妙性上花費太多的時間，我覺得這是一種不務正業的表現，除了有助於提高你的個人技術之外，對於公司的專案沒有任何的價值，對於測試來說，其自動化用例的編寫的效率要比執行效率重要的多。在實際的工作中，指令碼語言是也是測試程式碼的最愛，life is short, test in Python，道理大家都懂。