**最重要的話寫在前面：本文從現在開始不允許任何公眾號、論壇社群、微博轉載。已經轉載的管不了了，後面看到這句話請一定不要轉載，謝謝。
這篇文章引起這麼大反響是我始料未及的，本意只是想記錄下自己這段時間的經歷，完全沒想到被轉載出去之後這麼多人來看。一開始我自己發在簡書和掘金，都是很平靜的，但沒想到在 CocoaChina 居然被噴了 >< 。我把回應寫在下面。
真心抱歉讓大家不開心了，但是倉鼠被噴了，自己也很難過。我的本意就是想跟其他有需要面試的人分享經驗，難道這篇文章我說的不就是問知識性的題效果不好、最好多問一些貼近實際的嗎？難道我對我的轉變強調得還不夠嗎？大家噴的很對，我一開始問的這些問題是不應該，雖然我自己和朋友去大公司面試時候人家問得比這還要深。我在後面做出了很多的努力去調整，還專門來分享這些調整的經驗，專門建議不要問第一部分的問題。您們不看，光抓著第一部分噴。倉鼠不開心 T T。
下面是倉鼠的回覆：首先跟大家說一聲抱歉，好像有幾位同學看到第一部分的問題都不太開心。大家說得很對，開發中確實用不到這些東西。倉鼠後面確實也有所調整，重點不放在這些問題上了。如果我有什麼能為自己解釋的，就是這些題都是我從別的公司、尤其是大一點的公司借來的，他們真的會以這類問題為主，而且還有很多難得多的問題……我的第一反應是下意識隨大流的，覺得別的公司問這種問題、那我們也問唄。根據後面的經歷，我以後再也不會以這類知識性問題為重了。不過還是要提醒大家，會問這類問題的公司很多很多，很可能佔到大多數；而且就現在市場情況來看，我們遇到比較優秀的面試者都是能回答得很好的……所以如果以後自己要找工作的話，真的不可避免，最好還是準備一下，背一背也好：）**
好幾周沒更新過我的部落格了，因為這段時間實在是太忙了…… 先是自己換了工作，然後為了給之前公司找個出色的接班人，馬上緊鑼密鼓地開始了招聘。招聘花了一週時間，總共看了超過 60 份簡歷，面試了 20 位左右工程師，好在最後結果非常圓滿，招到一位很優秀的小夥伴。感慨頗多，與大家分享，希望能對大家之後的找工作或招聘有幫助。
整體感受
現在招人難嗎？我的感受是：很累，但不難。
剛看到拉勾上公司掛出的職位時，我還是有些擔憂的。這個職位的要求是，3 年工作經驗，獨立開發，作為創業公司唯一的 iOS 工程師一個人負責整個 app 的全部功能迭代，未來可能還要帶一個小組。開發業務要非常熟練，非常需要能獨當一面，非常需要能跟產品和後端良好溝通。基本至少是一箇中級工程師的要求，而拉勾上掛出的薪水範圍是 10~20k。雖然公司的業務是電商類，技術沒什麼特別的難點，我還是擔心給得不夠，怕真正有 3 年經驗的工程師看見這個薪資連簡歷都不會投。
事實上，職位一掛出就收到了大量的簡歷，其中工作經驗 3~5 年者比比皆是。算來平均一天面 5 個，連續面了 4 天，面得我累得要死。有幾次剛說到一半，視線的餘光裡看到下一個已經再等了。而來面試的 20 多位工程師，有四成左右在技術方面是沒有問題的，其中又有 5 位都可以算非常優秀，完全能滿足這個職位的要求，他們期望的薪水也大多落在我們給出薪資範圍的中段。而我們只招一個人，只能遺憾拒絕了其他幾位。可見現在 iOS 3 年經驗左右、中級工程師的人才市場還是買方市場，公司相對強勢，招到滿意的人還是比較容易的。
所以雖然面試者中有一大半水貨，浪費了我不少時間精力，讓我這幾天時時氣惱無奈；但是最後回頭看，總體來說還是對面試者心懷愧疚的。才招一個人卻約了這麼多面試，從某種程度上來說，我也浪費了他們的時間精力。真心抱歉，也祝願他們都能找到理想的工作。
篩簡歷的經驗
人力部門給我們送過來兩撥簡歷，第一波老大讓我篩，我麻煩兩位朋友幫我篩的；第二波我沒看到郵件，最後老大自己篩的。之後面試過程中，明顯感覺老大篩的結果沒有朋友篩的好。
幫我篩簡歷的兩位朋友都是 iOS 工程師，其中一位是培訓出來的，他說有幾份一看就是培訓班的模板，幫我過濾掉了。不知道他怎麼看出來的，反正這一波靠譜的多、不靠譜的少；而且他只標出一個優秀，結果果然很不錯。
而老大篩簡歷，雖然他也會點 iOS ，不過他說他主要是看工作年限、經驗，事實上他選出的簡歷也主要是年齡偏大、工作年限長的。但這就帶來一個問題，我們的薪資範圍已經擺在那兒了，而 5 年經驗還來投這麼低廉的職位，本身就說明一些問題。事實證明，這一波有很多明顯簡歷造假的面試者，弄得我非常煩、非常無奈。老大人非常 nice，只是不瞭解現在 iOS 環境的險惡。
就我自己篩簡歷的感想，在沒看到這些簡歷之前，我天真地以為可以看看學校、看看大公司、看看有什麼技術亮點什麼的。事實證明我想多了。就我們這個級別的招聘而言，收到的簡歷學校一概沒聽說過，而後來的面試也證明了碩士未必強於本科、三本未必不如二本。我自己寫簡歷時，寫技術點挖空心思、字斟句酌，拿著放大鏡找自己工程裡用到高大上的東西，力求能讓人看到亮點。而事實是看到所有人簡歷寫的技術點都非常非常非常雷同，所以大家也許是絞盡腦汁、洋洋灑灑列出的技術點，看簡歷的人不過是一掃而過。在實際面試中也發現意義不大，比如幾乎每個人都寫了熟練使用 SDWebImage，但我問它是怎麼快取的，幾乎都說不出，區別只在於有些人坦言知道，有些人憑想象編兩句；只要能說出有記憶體和磁碟兩級儲存的人，我內心都謝天謝地了。
讓我最為意外的是，大部分簡歷都是做過的專案一大群，三、五個月一個專案。這點完全顛覆了我的認知，以前在我的思維裡一個公司就約等於一個專案，專案黃了公司也就倒閉了。我沒想到這麼多小公司都三個月一個新產品，打一槍換一個地方。這種公司對工程師的發展其實很不利，很累不說，尤其是有些架構上的問題是工程大了、時間長了才能感覺出來的。
招聘結束後再反思篩簡歷的過程，我發現有一個指標是確定管用、對於篩簡歷非常有效率的，就是近期專案的質量。對於朋友幫我篩過的簡歷，我專門花時間下載了每位候選人最近的一個專案。就我們面試的經歷而言，專案是聽說過的、百度能搜到新聞的，介面整潔美觀、能看出確實有一定使用者量，有動畫或手勢互動的設計，對應的工程師技術 100% 過關。而那些一看就設計粗糙簡陋、細節不禁看的 app，已經是殭屍狀態、內容都疑似測試資料的專案，app store 上更新記錄少、評論寥寥，對應的工程師偶爾也有好的，但相對少得多。所以跟我們體量差不多的公司，如果需要篩簡歷，我會強烈建議下載最近專案看看質量，可能比簡歷上的其他任何部分都管用。
面試的經驗
我用於面試的問題經歷了3個階段的變化。
第一階段：知識性問題
因為自己最近剛經歷了一次面試，加上身邊朋友好幾個換了工作，我收集了一些如百度、頭條、美團等大公司常問的面試題，主要是一些語言知識、記憶體管理、多執行緒、稍微有點底層知識等。我想，來這麼多人，總有都能回答上來的吧。
事實證明，對我們這個級別的公司，這個級別的要求，這些常見面試題的效果並不太好。區分度非常低，要麼大家都會，要麼都不會。最簡單的問題比如“weak 和 strong 有什麼區別”，幾乎所有人（確實有不知道的）都能說出 weak 是弱引用，strong 是強引用；“你什麼情況下用 weak” 大部分能說出 delegate，防 block 迴圈引用。然後再問一句 “weak 的實現原理是什麼，為啥物件釋放掉了會變成 nil” 只有一兩個人能說出“雜湊表”這三個字，其他人要麼是一陣長久的沉默，要麼是說一些不著邊際的猜測。
再比如多執行緒，“atomic 和 nonatomic 有什麼區別”，很多人就不假思索地回答 “atomic 是執行緒安全的”（還有好幾個人說，不知道 atomic 是什麼，反正從來不用）。這已經是一個錯誤的答案了，我會提醒 NSMutableArray 的執行緒安全性，但得到的反饋往往是一臉迷茫。再問自己重寫 atomic 屬性的 getter、setter 方法，能說出加鎖，不管是 @synchronized 還是 NSLock，已經寥寥無幾了。
還沒來得及用上什麼大公司的面試題，才剛到我自己想的幾個簡單的鋪墊問題面前，就呼啦啦幾乎全倒下了。一旦這種情況發生兩三次，明顯面試者的情緒就變得低落，我作為面試官也很尷尬。第一天面試結束後，我回去好好反思了一下，為啥這些網上遍地都是、我本以為培訓班剛出來的人也能背得爛熟的題，我們找來的人基本全都答不出呢？難道是我們公司太 low 了？然而，我們要找的並不是什麼黑客科學家，我們只是要找一個能幹活的人，就算不知道 weak 的實現原理又有什麼關係呢？這並不影響日常幹活，這種面試方法完全可能讓我們錯過一個編碼熟練、溝通能力強的工程師。
想到這裡，我決定改變第二天面試的模式。其實從最後的結果來看，優秀級別的那 5 位面試者面對這類問題是能回答得不錯的。所以，單就結果而言，如果答不出這種常見面試題，就直接拒掉，這個策略似乎也不會有什麼壞影響。不過，對於大多數普通工程師，這類題的區分度不好。因此，在後續的面試中，雖然我基本每個人都還是問了兩句這類問題，但再也沒有把它們當做重頭戲。
第二階段：一般性問題
再也不想讓面試過程的大部分被尷尬的沉默佔據了，我決定想幾個能讓每個人都聊得開心的問題。例如：
- 您在工程中遇到過什麼很難的問題？不論是特殊的互動方式、複雜動畫、效能、安全問題…… 最後怎麼解決的？
- 展示您做過最複雜的一個介面 / 自己封裝得比較好的元件，介紹它的結構和為什麼這麼做；
- 您在工程中做過哪些重構？做出了哪些改變，最後的效果如何？
- 平常工程中用到哪些第三方開源庫？您讀過它們的原始碼嗎？講講自己最熟悉的一個開源庫的原始碼結構；
- 下面給您看的這幾張圖是我上一期剛開發完的需求，如果讓您開發的話，您能給出一個估時嗎？其中有什麼難點和風險點嗎？
- ……
這些問題的好處是顯而易見的，每個人都能多少說上幾句。回答大部分是“沒有”、“沒什麼”的基本可以 pass 了，而優秀的工程師往往有很多內容可聊。但是這些問題也有一個顯著的缺點，就是對我的要求陡然提高：不像知識性問題能簡單粗暴地比對標準答案，我必須全神貫注地傾聽面試者的回答，儘可能地理解、猜測他講的技術，同時還要時刻注意尋找能進一步挖掘的點，然後再往深處問下去，還要儘量表達清楚深一層的問題。
這樣面試一個人，我比自己接受一次面試還要累。其中一個主要原因，就是努力讓對方聽懂我進一步提出的問題。
比如一個人講他封了一個彈框那種 HUD，我就順便問，如果調起這個 HUD 的方法不是在主執行緒呼叫的，是不是會 crash 呢，你是怎麼處理的？對方一臉不解，於是開始了數個回合的拉鋸糾纏：“調起是什麼？” “就是把它顯示出來，你總要把它顯示出來吧？” “那就把它顯示出來呀，不明白您想問什麼” “我就問如果不是在主執行緒做這件事兒，怎麼做？” “……沒什麼區別呀？什麼情況不會在主執行緒，我沒遇到這種情況” “比如在網路請求的回撥裡呀，如果網路請求不是主執行緒，是不是會 crash 呀，網路失敗了我是不是要顯示這個彈框彈一個錯誤呀” “我就是這麼用的，沒有 crash 呀……”
其實只是想問 dispatch 到 main 這麼一個簡單的事情，但似乎就是無法表達清楚我的問題。看著對方莫名其妙的樣子，我開始後悔提了這個問題，猶豫是放過還是糾纏下去。兩三場面試下來，我聽到最多的一句話是“我不明白您想問什麼”“我不確定我理解了您的問題沒有”，彷彿我們說的不是同一種語言。從反覆解釋到最終語塞，我感到了深深的挫敗感，對我的溝通能力產生了巨大的懷疑，彷彿聽到對方在想：“這人問的這都什麼跟什麼，她到底懂不懂技術。”
於是我決定把電腦帶進會議室。下一個人我問看過什麼開源專案，他說用 JSONKit 把 json 轉成 model。我沒看過 JSONKit，但看過 JSONModel，感覺應該差不多，就問他 JSONKit 是怎麼把 json 轉成 model 的。同樣的場景又重現了，完全說不到一塊兒去，他一直莫名其妙地說：“就是那麼轉的呀？不知道你在問什麼。”
我開始懷疑人生，懷疑這個我看過的庫是不是用法別具一格，跟我想象的完全不一樣。所幸我帶電腦進來了，於是我快速寫了一個 Student 類，定義了一個 NSDictionary* dictionary = @{@"name":@"hamster"}，讓他簡單寫一下 dictionary 是怎麼變成 model。他是這樣寫的：
Student* student = dictionary;複製程式碼看到這行程式碼，我一瞬間明白了很多。就算我沒看過這個庫，但我也知道 OC 裡沒有這種神奇魔法；即使我讓他現場寫 dictionary 轉 model 要求太高了，但是任何一個工作過一天的 iOS 程式設計師的人都是寫不出這行程式碼的。我也一下子明白了為什麼前面總說聽不懂問題，因為他對我說的東西完全沒概念，腦子裡一片空白。把責任推給我，假裝是我沒問清楚，可能是在這種情形下他唯一能做的防禦了。
對於後面的面試者，我還是會把這些問題拿幾個出來問一問，但再也沒有跟對方死磕。事實證明，對於比較優秀的那幾個面試者，我從來不用多費口舌，輕輕一點就能馬上說出我想要的答案，真是十分暢快。這是我第一次意識到，溝通能力低的背後其實可能只是技術能力低。工程師之間的溝通技巧，背後是工程經驗、架構水平和技術知識在支撐的。
就這幾個問題而言，我覺得一個比較有區分度的是“做過哪些重構”，因為得到的回答非常明顯的兩級分化：一種是“基本沒怎麼做過，我寫的時候就很注意了，不需要重構”，或者說做過，但實際上只是因為前面程式碼質量太差而推翻重寫；另一種是“非常常見，經常會做”。在我看來，後一種工程師水平是比前一種要高一層次的。不是程式碼寫得爛所以總要重構去修改，而是隨著時間推移、業務變化，重構是必須的，但只有對技術有追求、對自己有要求的工程師才會發現這個問題、才會冒風險去重構。沒做過重構，要麼說明他做專案沒深度、做一個扔一個，要麼說明懶惰或過於忙碌，但無論如何是不可取的。
（篇幅已經比較長了，剩餘的內容會放在 下 篇裡。有興趣看下去的話可以過段時間再來看。）