面試了 20 個初/中級 iOS 工程師以後（上）

**最重要的話寫在前面：本文從如今開始不容許任何公衆號、論壇社區、微博轉載。已經轉載的管不了了，後面看到這句話請必定不要轉載，謝謝。

這篇文章引發這麼大反響是我始料未及的，本意只是想記錄下本身這段時間的經歷，徹底沒想到被轉載出去以後這麼多人來看。一開始我本身發在簡書和掘金，都是很平靜的，但沒想到在 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，但我問它是怎麼緩存的，幾乎都說不出，區別只在於有些人坦言知道，有些人憑想象編兩句；只要能說出有內存和磁盤兩級存儲的人，我心裏都謝天謝地了。

讓我最爲意外的是，大部分簡歷都是作過的項目一大羣，3、五個月一個項目。這點徹底顛覆了個人認知，之前在個人思惟裏一個公司就約等於一個項目，項目黃了公司也就倒閉了。我沒想到這麼多小公司都三個月一個新產品，打一槍換一個地方。這種公司對工程師的發展其實很不利，很累不說，尤爲是有些架構上的問題是工程大了、時間長了才能感受出來的。

招聘結束後再反思篩簡歷的過程，我發現有一個指標是肯定管用、對於篩簡歷很是有效率的，就是近期項目的質量。對於朋友幫我篩過的簡歷，我專門花時間下載了每位候選人最近的一個項目。就咱們面試的經歷而言，項目是據說過的、百度能搜到新聞的，界面整潔美觀、能看出確實有必定用戶量，有動畫或手勢交互的設計，對應的工程師技術 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 程序員的人都是寫不出這行代碼的。我也一會兒明白了爲何前面總說聽不懂問題，由於他對我說的東西徹底沒概念，腦子裏一片空白。把責任推給我，僞裝是我沒問清楚，多是在這種情形下他惟一能作的防護了。

對於後面的面試者，我仍是會把這些問題拿幾個出來問一問，但再也沒有跟對方死磕。事實證實，對於比較優秀的那幾個面試者，我歷來不用多費口舌，輕輕一點就能立刻說出我想要的答案，真是十分暢快。這是我第一次意識到，溝通能力低的背後其實可能只是技術能力低。工程師之間的溝通技巧，背後是工程經驗、架構水平和技術知識在支撐的。

就這幾個問題而言，我以爲一個比較有區分度的是「作過哪些重構」，由於獲得的回答很是明顯的兩級分化：一種是「基本沒怎麼作過，我寫的時候就很注意了，不須要重構」，或者說作過，但實際上只是由於前面代碼質量太差而推翻重寫；另外一種是「很是常見，常常會作」。在我看來，後一種工程師水平是比前一種要高一層次的。不是代碼寫得爛因此總要重構去修改，而是隨着時間推移、業務變化，重構是必須的，但只有對技術有追求、對本身有要求的工程師纔會發現這個問題、纔會冒風險去重構。沒作太重構，要麼說明他作項目沒深度、作一個扔一個，要麼說明懶惰或過於忙碌，但不管如何是不可取的。

（篇幅已經比較長了，剩餘的內容會放在 下 篇裏。有興趣看下去的話能夠過段時間再來看。）