最近一段時間都在做集中招聘，參加了許多面試，累個半死。加上之前在團隊中最近幾年也做了不少面試，關於測試工程師招聘的話題，剛才沒事特意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，道理大家都懂。
測試思路（“Test Sense”）
對於一些稍微高階的崗位，例如資深測試開發工程師或者測試專家的招聘，需要考核更多的測試思路和測試技術（參見下一段），不再是簡單的程式設計問題。關於測試思路，在寫完一段程式碼之後，會被要求來測試這段程式碼。這個時候，候選人的測試思路就會湧現出來，嘗試儘可能多的測試方法與思路來測試這段程式碼。一般的候選人會考慮正常情況下的使用場景、邊界情況、bad case等功能性的方面問題，這說明你入了門，知道基本的思路，而經驗豐富的候選人，會在效能方面多考慮一些，例如performance test, load test, stress test（不知道他們的區別，我只能說你不是效能測試專家，趕緊去google一下吧）。在這裡，肯定又有好事者會跳出來說了，哥是來應聘效能測試專家的，你讓我寫程式碼我就認了，你還讓我針對這些程式碼做效能測試，我可是正經的效能測試出身，之前都是用的loadrunner、jmeter這些高階大氣上檔次的效能工具，根本不用自己寫程式碼針對某個函式做效能測試。哎，遇到這種人，也不知道是他的不幸還是我的不幸，但在面試官面前我覺得你還是應該低調一些，如果你公開拒絕，我除了認為你比較坦誠之外還會認為你很有“潛力”，注意這個潛力是上一段中所說的潛力。廢話少說，白盒的效能測試或者叫效能分析能力，在跟蹤定位效能問題的時候特別重要，如果你還能把gperftool(google perfmance tool)、operfile等工具原理及使用場景告訴我，加分！效能測試絕對不是簡單的系統方面的效能測試，能夠指出整個系統的效能結果只是第一步，系統級別的效能測試工具loadrunner可以做到，但如果想定位到效能瓶頸所在、並提供改進方案那你就必須要掌握剛剛提到的白盒效能分析能力，從系統層面到模組級別、再到函式級別的問題定位，這才能彰顯牛逼人的牛逼之處。就是比普通人多那麼一點點。發現我的廢話還真多，繼續說測試思路的事情，優秀的候選人會提供功能、效能方面的思路，再優秀的人會提供更多的思路，例如穩定性方面，這段程式碼在持續執行24小時之後怎樣？函式的響應時間、記憶體和cpu的佔用情況還跟呼叫之初一樣嗎？是否符合預期？還有一些人會考慮安全方面的場景，在多執行緒的呼叫下程式會出錯嗎？是否執行緒安全？多程序的情況下呢，是否有共享的程序間資料安全問題，有沒有被死鎖的可能等等。還有很多測試思路方面的點子，在這裡就不再一一羅列，你要感興趣，我們可以私下交流。總之，對於有豐富測試經驗的人（可不是工作年頭），總是可以提出很多思路和方法，而獲得這些知識的唯一來源就是實踐，否則幾個問題深入下去你就露餡兒，而在面試過程中“誠信”永遠是底線，不可違背。
測試技術
針對高階測試崗位需要一些有針對性的測試技術類問題。例如，針對前端測試崗位，在技術提問上會由針對性地在前端提問，沒有自己寫過前端程式的人也很難把前端測試做好，html/css/js/Wartir/Selenium/Webdriver等方面的知識必不可少，開源的工具沒用過，沒有關係，你只要能把類似的思路說清楚也可以。怎樣精準定位web頁面上得元素、如何得到這個物件而不是另外一個相同型別的元素、背後原理是怎樣的，等等這種有針對性的問題很容易試探出候選人在前端測試方面的技術深度。再例如，一個測試工具開發的候選人必須知道框架、工具、平臺的區別，框架如何提供介面給業務測試人員使用，哪些是框架要解決的問題哪些是業務測試自己要解決的問題，他們的問題域和解決方案都必須要了如指掌。類似地，在單元測試、api測試、安全測試、mobile測試、後端服務測試、大資料測試等方面，都會有針對性的問題等著你。相比較之前的程式碼能力，面試官一般更看中測試技術本身的掌握能力，程式碼能力只能說明你有潛能，而測試技術是未來會在專案中真實用到的技術，會真正地幫助到測試本身的技術。
技術熱情
在之前的面試中，遇到很多候選人，但被問及為什麼來選擇來做測試時，有些會說“我是女生，我很細心”。臥槽，適合不適合做測試跟細心有個毛線關係，我承認細心體貼是中華女性的傳統美德，可測試真不是靠細心就能做的很好的。而且我發現有一批人的確就是這麼想的，所以有必要在這裡囉嗦幾句。可以這樣說，細心地觀察是可以發現一個事物的某處缺陷，就像“鑑寶”節目中你要細緻地觀察，你細心你可以發現某個青花瓷藏品中是否砂底有釉，但如果你不瞭解元青花背後的知識背景即便你發現了這個缺陷你也無法做出正確的判斷，相比較細心，更重要的是背後積累的技能知識。知識技能的增長因素中，很重要的就是技術熱情。所以即便候選人技能還不到火候，但如果技術熱情飽滿，我還是會認為這樣的人是真正有潛力的人，甚至會給一個通過。俗話說，“活到老，學到老”，背後依賴的就是熱情。沒有熱情的人就像是一潭死水，工作對他而言更多的是一份工作，毫無聲色與激情。在技術日新月異當下，沒有熱情，慢慢地你就“死”了。
技術之外
每一個崗位都有它的針對性，有及技能要求，也有技術之外的要求。團隊中需要什麼樣的人，我們就招聘什麼樣的人。除了技術能力之外，你最希望團隊中的人具有什麼特質？這個恐怕因人而異，但你不得不去思考這些問題。如果你招聘到一個不合適的人，對團隊的影響是巨大的，會破換團隊的水質。一旦發現這類人，一定要“fire quickly”，否則遺患無窮。這裡居然扯出了facebook得招聘理念“hire slowly, fire quickly”，我把它翻譯成“結婚慢慢找，離婚快點離”，哎呀，我的思路可真發散啊，都不知道自己要說啥了。:)
言歸正傳，在面試過程中，技術之外，考查更多的幾個軟技能大致如下， 1. 溝通能力。整個面試過程本身就是一次溝通的過程，你能夠很好地理解面試官的問題，面試官也能聽懂你的答案，perfect，這算是一次完美的溝通了嗎，體現了候選人優良的溝通能力。錯，大錯特錯，特別是針對面試這種場景，針對測試這個崗位。候選人聽得懂你的問題，有可能是你講的很明白，而你能聽懂他的回答是因為你是這個問題域的專家，可以從少數關鍵字中抽取出正確的答案，這種語境下，並不能說明候選人就具備良好的表達能力或者優秀的理解力。我個人認為，考核一個人的溝通能力時需要提問一些模糊的問題，在逆境下方顯能力。如果候選人可以針對你的問題多問幾個問題以及經過後繼的一些反覆確認，這才能證明他具備一定的溝通能力，並說明候選人是一個愛問問題的人，而對於測試來說，愛問問題或者懷疑的態度永遠是最彌足珍貴的品質。 2. 團隊合作。測試是整個研發環節中的一環，大型的專案更是需要多人一起測試完成。人與人一起打交道，就會有各種合作的需求。合作關係是一種共贏逐利的行為，強調同步與整體，節調一致。但對於一個產品或者專案，有人做紅花就要有人甘願做綠葉，所以在合作中需要奉獻。情商較低的人團隊合作一般都比較困難。 3. 執行力。執行力不是簡單的聽話，“執行”才是聽話，“力”更多的是強調執行的結果。沒有一個主管喜歡不聽話的下屬，但聽話的下屬執行力卻不一定強。很多人說的漂亮但做起來卻沒有說的那麼好，相反，有些人動手能力很強，但不苟於言辭。堅強的人，或者笨的人更容易成功，因為他們懂得堅持。 4. 易相處。很多團隊強調這一點，一個nice的人，一般都很容易相處，團隊成員之間的關係也會比較和諧。一般情商比較高的同學，在這方面都不會有太大的問題。反倒是一些智商高的人，容易讓人有點擔憂。易相處絕對不是唯一的標準，不易相處的同學會給管理上帶來一定的難度，多數管理者都會希望自己的團隊成員不是那麼的刺頭。但在面試的過程中對一個人做出這樣的判斷還是非常困難的。通用言談舉止，或許可以做出一定的判斷，但人一是會偽裝的，或者說是掩飾，特別是一些知道自己缺點的人，會嘗試掩蓋自己的不足。
面試技巧
所有的技巧基本上都沒有什麼用處，基本上都是狗屎，再好的技巧都是為了掩飾。所以切記在面試過程中使用什麼“技巧”。
最後
說了這麼多，多數都是對候選人的要求，其實對於面試官也一樣，你配做面試官嗎？你能真實考察出候選人的能力嗎？你判斷的依據又是什麼。千里馬難尋的背後往往是因為伯樂太少。寫這段話的時候，我也打了幾個激靈，