**最重要的話寫在前面：本文從現(xiàn)在開始不允許任何公眾號狐粱、論壇社區(qū)伞剑、微博轉(zhuǎn)載斑唬。已經(jīng)轉(zhuǎn)載的管不了了，后面看到這句話請一定不要轉(zhuǎn)載黎泣，謝謝赖钞。

這篇文章引起這么大反響是我始料未及的，本意只是想記錄下自己這段時間的經(jīng)歷聘裁，完全沒想到被轉(zhuǎn)載出去之后這么多人來看。一開始我自己發(fā)在簡書和掘金弓千，都是很平靜的衡便，但沒想到在 CocoaChina 居然被噴了 >< 。我把回應(yīng)寫在下面洋访。

真心抱歉讓大家不開心了镣陕，但是倉鼠被噴了，自己也很難過姻政。我的本意就是想跟其他有需要面試的人分享經(jīng)驗呆抑，難道這篇文章我說的不就是問知識性的題效果不好、最好多問一些貼近實際的嗎汁展？難道我對我的轉(zhuǎn)變強調(diào)得還不夠嗎鹊碍？大家噴的很對厌殉，我一開始問的這些問題是不應(yīng)該，雖然我自己和朋友去大公司面試時候人家問得比這還要深侈咕。我在后面做出了很多的努力去調(diào)整公罕，還專門來分享這些調(diào)整的經(jīng)驗，專門建議不要問第一部分的問題耀销。您們不看楼眷，光抓著第一部分噴。倉鼠不開心 T T熊尉。

下面是倉鼠的回復(fù)：首先跟大家說一聲抱歉罐柳，好像有幾位同學(xué)看到第一部分的問題都不太開心。大家說得很對狰住，開發(fā)中確實用不到這些東西张吉。倉鼠后面確實也有所調(diào)整，重點不放在這些問題上了转晰。如果我有什么能為自己解釋的芦拿，就是這些題都是我從別的公司、尤其是大一點的公司借來的查邢，他們真的會以這類問題為主蔗崎，而且還有很多難得多的問題……我的第一反應(yīng)是下意識隨大流的，覺得別的公司問這種問題扰藕、那我們也問唄缓苛。根據(jù)后面的經(jīng)歷，我以后再也不會以這類知識性問題為重了邓深。不過還是要提醒大家未桥，會問這類問題的公司很多很多，很可能占到大多數(shù)芥备；而且就現(xiàn)在市場情況來看冬耿，我們遇到比較優(yōu)秀的面試者都是能回答得很好的……所以如果以后自己要找工作的話，真的不可避免萌壳，最好還是準備一下亦镶，背一背也好：）**

好幾周沒更新過我的博客了，因為這段時間實在是太忙了…… 先是自己換了工作袱瓮，然后為了給之前公司找個出色的接班人缤骨，馬上緊鑼密鼓地開始了招聘。招聘花了一周時間尺借，總共看了超過 60 份簡歷绊起，面試了 20 位左右工程師，好在最后結(jié)果非常圓滿燎斩，招到一位很優(yōu)秀的小伙伴虱歪。感慨頗多蜂绎，與大家分享，希望能對大家之后的找工作或招聘有幫助实蔽。

整體感受

現(xiàn)在招人難嗎荡碾？我的感受是：很累，但不難局装。

剛看到拉勾上公司掛出的職位時坛吁，我還是有些擔憂的。這個職位的要求是铐尚，3 年工作經(jīng)驗拨脉，獨立開發(fā)，作為創(chuàng)業(yè)公司唯一的 iOS 工程師一個人負責整個 app 的全部功能迭代宣增，未來可能還要帶一個小組玫膀。開發(fā)業(yè)務(wù)要非常熟練爹脾，非常需要能獨當一面，非常需要能跟產(chǎn)品和后端良好溝通朱转」钟耄基本至少是一個中級工程師的要求窿吩，而拉勾上掛出的薪水范圍是 10~20k。雖然公司的業(yè)務(wù)是電商類刽脖，技術(shù)沒什么特別的難點硕糊，我還是擔心給得不夠，怕真正有 3 年經(jīng)驗的工程師看見這個薪資連簡歷都不會投胰默。

事實上，職位一掛出就收到了大量的簡歷，其中工作經(jīng)驗 3~5 年者比比皆是。算來平均一天面 5 個占哟，連續(xù)面了 4 天榨乎，面得我累得要死怎燥。有幾次剛說到一半，視線的余光里看到下一個已經(jīng)再等了蜜暑。而來面試的 20 多位工程師铐姚，有四成左右在技術(shù)方面是沒有問題的，其中又有 5 位都可以算非常優(yōu)秀肛捍，完全能滿足這個職位的要求隐绵，他們期望的薪水也大多落在我們給出薪資范圍的中段之众。而我們只招一個人，只能遺憾拒絕了其他幾位依许」缀蹋可見現(xiàn)在 iOS 3 年經(jīng)驗左右、中級工程師的人才市場還是買方市場峭跳，公司相對強勢膘婶，招到滿意的人還是比較容易的。

所以雖然面試者中有一大半水貨坦康，浪費了我不少時間精力竣付，讓我這幾天時時氣惱無奈；但是最后回頭看滞欠，總體來說還是對面試者心懷愧疚的古胆。才招一個人卻約了這么多面試，從某種程度上來說筛璧，我也浪費了他們的時間精力逸绎。真心抱歉，也祝愿他們都能找到理想的工作夭谤。

篩簡歷的經(jīng)驗

人力部門給我們送過來兩撥簡歷棺牧，第一波老大讓我篩，我麻煩兩位朋友幫我篩的朗儒；第二波我沒看到郵件颊乘，最后老大自己篩的。之后面試過程中醉锄，明顯感覺老大篩的結(jié)果沒有朋友篩的好乏悄。

幫我篩簡歷的兩位朋友都是 iOS 工程師，其中一位是培訓(xùn)出來的恳不，他說有幾份一看就是培訓(xùn)班的模板檩小，幫我過濾掉了。不知道他怎么看出來的烟勋，反正這一波靠譜的多规求、不靠譜的少；而且他只標出一個優(yōu)秀卵惦，結(jié)果果然很不錯阻肿。

而老大篩簡歷，雖然他也會點 iOS 沮尿，不過他說他主要是看工作年限丛塌、經(jīng)驗，事實上他選出的簡歷也主要是年齡偏大、工作年限長的姨伤。但這就帶來一個問題，我們的薪資范圍已經(jīng)擺在那兒了庸疾，而 5 年經(jīng)驗還來投這么低廉的職位乍楚，本身就說明一些問題。事實證明届慈，這一波有很多明顯簡歷造假的面試者徒溪，弄得我非常煩、非常無奈金顿。老大人非常 nice臊泌，只是不了解現(xiàn)在 iOS 環(huán)境的險惡。

就我自己篩簡歷的感想揍拆，在沒看到這些簡歷之前渠概，我天真地以為可以看看學(xué)校、看看大公司嫂拴、看看有什么技術(shù)亮點什么的播揪。事實證明我想多了。就我們這個級別的招聘而言筒狠，收到的簡歷學(xué)校一概沒聽說過猪狈，而后來的面試也證明了碩士未必強于本科、三本未必不如二本辩恼。我自己寫簡歷時雇庙，寫技術(shù)點挖空心思、字斟句酌灶伊，拿著放大鏡找自己工程里用到高大上的東西疆前，力求能讓人看到亮點。而事實是看到所有人簡歷寫的技術(shù)點都非常非常非常雷同谁帕，所以大家也許是絞盡腦汁峡继、洋洋灑灑列出的技術(shù)點，看簡歷的人不過是一掃而過匈挖。在實際面試中也發(fā)現(xiàn)意義不大碾牌，比如幾乎每個人都寫了熟練使用 SDWebImage，但我問它是怎么緩存的儡循，幾乎都說不出舶吗，區(qū)別只在于有些人坦言知道，有些人憑想象編兩句择膝；只要能說出有內(nèi)存和磁盤兩級存儲的人誓琼，我內(nèi)心都謝天謝地了。

讓我最為意外的是，大部分簡歷都是做過的項目一大群腹侣，三叔收、五個月一個項目。這點完全顛覆了我的認知傲隶，以前在我的思維里一個公司就約等于一個項目饺律，項目黃了公司也就倒閉了。我沒想到這么多小公司都三個月一個新產(chǎn)品跺株，打一槍換一個地方复濒。這種公司對工程師的發(fā)展其實很不利，很累不說乒省，尤其是有些架構(gòu)上的問題是工程大了巧颈、時間長了才能感覺出來的。

招聘結(jié)束后再反思篩簡歷的過程袖扛，我發(fā)現(xiàn)有一個指標是確定管用砸泛、對于篩簡歷非常有效率的，就是近期項目的質(zhì)量蛆封。對于朋友幫我篩過的簡歷晾嘶，我專門花時間下載了每位候選人最近的一個項目。就我們面試的經(jīng)歷而言娶吞，項目是聽說過的垒迂、百度能搜到新聞的，界面整潔美觀妒蛇、能看出確實有一定用戶量机断，有動畫或手勢交互的設(shè)計，對應(yīng)的工程師技術(shù) 100% 過關(guān)绣夺。而那些一看就設(shè)計粗糙簡陋吏奸、細節(jié)不禁看的 app，已經(jīng)是僵尸狀態(tài)陶耍、內(nèi)容都疑似測試數(shù)據(jù)的項目奋蔚，app store 上更新記錄少、評論寥寥烈钞，對應(yīng)的工程師偶爾也有好的泊碑，但相對少得多。所以跟我們體量差不多的公司毯欣，如果需要篩簡歷馒过，我會強烈建議下載最近項目看看質(zhì)量，可能比簡歷上的其他任何部分都管用酗钞。

面試的經(jīng)驗

我用于面試的問題經(jīng)歷了3個階段的變化腹忽。

第一階段：知識性問題

因為自己最近剛經(jīng)歷了一次面試来累，加上身邊朋友好幾個換了工作，我收集了一些如百度窘奏、頭條嘹锁、美團等大公司常問的面試題，主要是一些語言知識着裹、內(nèi)存管理兼耀、多線程、稍微有點底層知識等求冷。我想，來這么多人窍霞，總有都能回答上來的吧匠题。

事實證明，對我們這個級別的公司但金，這個級別的要求韭山，這些常見面試題的效果并不太好。區(qū)分度非常低冷溃，要么大家都會钱磅，要么都不會。最簡單的問題比如“weak 和 strong 有什么區(qū)別”似枕，幾乎所有人（確實有不知道的）都能說出 weak 是弱引用盖淡，strong 是強引用；“你什么情況下用 weak” 大部分能說出 delegate凿歼，防 block 循環(huán)引用褪迟。然后再問一句 “weak 的實現(xiàn)原理是什么，為啥對象釋放掉了會變成 nil” 只有一兩個人能說出“哈希表”這三個字答憔，其他人要么是一陣長久的沉默味赃，要么是說一些不著邊際的猜測。

再比如多線程虐拓，“atomic 和 nonatomic 有什么區(qū)別”心俗，很多人就不假思索地回答 “atomic 是線程安全的”（還有好幾個人說，不知道 atomic 是什么蓉驹，反正從來不用）城榛。這已經(jīng)是一個錯誤的答案了，我會提醒 NSMutableArray 的線程安全性态兴，但得到的反饋往往是一臉迷茫吠谢。再問自己重寫 atomic 屬性的 getter、setter 方法诗茎，能說出加鎖工坊，不管是 @synchronized 還是 NSLock献汗，已經(jīng)寥寥無幾了。

還沒來得及用上什么大公司的面試題王污，才剛到我自己想的幾個簡單的鋪墊問題面前罢吃，就呼啦啦幾乎全倒下了。一旦這種情況發(fā)生兩三次昭齐，明顯面試者的情緒就變得低落尿招，我作為面試官也很尷尬。第一天面試結(jié)束后阱驾，我回去好好反思了一下就谜，為啥這些網(wǎng)上遍地都是、我本以為培訓(xùn)班剛出來的人也能背得爛熟的題里覆，我們找來的人基本全都答不出呢丧荐？難道是我們公司太 low 了？然而喧枷，我們要找的并不是什么黑客科學(xué)家虹统，我們只是要找一個能干活的人，就算不知道 weak 的實現(xiàn)原理又有什么關(guān)系呢隧甚？這并不影響日常干活车荔，這種面試方法完全可能讓我們錯過一個編碼熟練、溝通能力強的工程師戚扳。

想到這里忧便，我決定改變第二天面試的模式。其實從最后的結(jié)果來看帽借，優(yōu)秀級別的那 5 位面試者面對這類問題是能回答得不錯的茬腿。所以，單就結(jié)果而言宜雀，如果答不出這種常見面試題切平，就直接拒掉，這個策略似乎也不會有什么壞影響辐董。不過悴品，對于大多數(shù)普通工程師，這類題的區(qū)分度不好简烘。因此苔严，在后續(xù)的面試中，雖然我基本每個人都還是問了兩句這類問題孤澎，但再也沒有把它們當做重頭戲届氢。

第二階段：一般性問題

再也不想讓面試過程的大部分被尷尬的沉默占據(jù)了，我決定想幾個能讓每個人都聊得開心的問題覆旭。例如：

• 您在工程中遇到過什么很難的問題退子？不論是特殊的交互方式岖妄、復(fù)雜動畫、性能寂祥、安全問題…… 最后怎么解決的荐虐？
• 展示您做過最復(fù)雜的一個界面 / 自己封裝得比較好的組件，介紹它的結(jié)構(gòu)和為什么這么做丸凭；
• 您在工程中做過哪些重構(gòu)福扬？做出了哪些改變，最后的效果如何惜犀？
• 平常工程中用到哪些第三方開源庫铛碑？您讀過它們的源碼嗎？講講自己最熟悉的一個開源庫的源碼結(jié)構(gòu)虽界；
• 下面給您看的這幾張圖是我上一期剛開發(fā)完的需求汽烦，如果讓您開發(fā)的話，您能給出一個估時嗎浓恳？其中有什么難點和風(fēng)險點嗎？
• ……

這些問題的好處是顯而易見的碗暗，每個人都能多少說上幾句颈将。回答大部分是“沒有”言疗、“沒什么”的基本可以 pass 了晴圾，而優(yōu)秀的工程師往往有很多內(nèi)容可聊。但是這些問題也有一個顯著的缺點噪奄，就是對我的要求陡然提高：不像知識性問題能簡單粗暴地比對標準答案死姚，我必須全神貫注地傾聽面試者的回答，盡可能地理解勤篮、猜測他講的技術(shù)都毒，同時還要時刻注意尋找能進一步挖掘的點，然后再往深處問下去碰缔，還要盡量表達清楚深一層的問題账劲。

這樣面試一個人，我比自己接受一次面試還要累金抡。其中一個主要原因瀑焦，就是努力讓對方聽懂我進一步提出的問題。

比如一個人講他封了一個彈框那種 HUD梗肝，我就順便問榛瓮，如果調(diào)起這個 HUD 的方法不是在主線程調(diào)用的，是不是會 crash 呢巫击，你是怎么處理的禀晓？對方一臉不解精续，于是開始了數(shù)個回合的拉鋸糾纏：“調(diào)起是什么？” “就是把它顯示出來匆绣，你總要把它顯示出來吧驻右？” “那就把它顯示出來呀，不明白您想問什么” “我就問如果不是在主線程做這件事兒崎淳，怎么做堪夭？” “……沒什么區(qū)別呀？什么情況不會在主線程拣凹，我沒遇到這種情況” “比如在網(wǎng)絡(luò)請求的回調(diào)里呀森爽，如果網(wǎng)絡(luò)請求不是主線程，是不是會 crash 呀嚣镜，網(wǎng)絡(luò)失敗了我是不是要顯示這個彈框彈一個錯誤呀” “我就是這么用的爬迟，沒有 crash 呀……”

其實只是想問 dispatch 到 main 這么一個簡單的事情，但似乎就是無法表達清楚我的問題菊匿「杜唬看著對方莫名其妙的樣子，我開始后悔提了這個問題跌捆，猶豫是放過還是糾纏下去徽职。兩三場面試下來，我聽到最多的一句話是“我不明白您想問什么”“我不確定我理解了您的問題沒有”佩厚，仿佛我們說的不是同一種語言姆钉。從反復(fù)解釋到最終語塞，我感到了深深的挫敗感抄瓦，對我的溝通能力產(chǎn)生了巨大的懷疑潮瓶，仿佛聽到對方在想：“這人問的這都什么跟什么，她到底懂不懂技術(shù)钙姊√焊ǎ”

于是我決定把電腦帶進會議室。下一個人我問看過什么開源項目煞额，他說用 JSONKit 把 json 轉(zhuǎn)成 model悉罕。我沒看過 JSONKit，但看過 JSONModel立镶，感覺應(yīng)該差不多壁袄，就問他 JSONKit 是怎么把 json 轉(zhuǎn)成 model 的。同樣的場景又重現(xiàn)了媚媒，完全說不到一塊兒去嗜逻，他一直莫名其妙地說：“就是那么轉(zhuǎn)的呀？不知道你在問什么缭召≌磺辏”

我開始懷疑人生逆日，懷疑這個我看過的庫是不是用法別具一格，跟我想象的完全不一樣萄凤。所幸我?guī)щ娔X進來了室抽，于是我快速寫了一個 Student 類，定義了一個 NSDictionary* dictionary = @{@"name":@"hamster"}靡努，讓他簡單寫一下 dictionary 是怎么變成 model坪圾。他是這樣寫的：

Student* student = dictionary;

看到這行代碼，我一瞬間明白了很多惑朦。就算我沒看過這個庫兽泄，但我也知道 OC 里沒有這種神奇魔法；即使我讓他現(xiàn)場寫 dictionary 轉(zhuǎn) model 要求太高了漾月，但是任何一個工作過一天的 iOS 程序員的人都是寫不出這行代碼的病梢。我也一下子明白了為什么前面總說聽不懂問題，因為他對我說的東西完全沒概念梁肿，腦子里一片空白蜓陌。把責任推給我，假裝是我沒問清楚吩蔑，可能是在這種情形下他唯一能做的防御了钮热。

對于后面的面試者，我還是會把這些問題拿幾個出來問一問哥纫，但再也沒有跟對方死磕霉旗。事實證明痴奏，對于比較優(yōu)秀的那幾個面試者蛀骇，我從來不用多費口舌，輕輕一點就能馬上說出我想要的答案读拆，真是十分暢快擅憔。這是我第一次意識到，溝通能力低的背后其實可能只是技術(shù)能力低檐晕。工程師之間的溝通技巧暑诸，背后是工程經(jīng)驗、架構(gòu)水平和技術(shù)知識在支撐的辟灰。

就這幾個問題而言个榕，我覺得一個比較有區(qū)分度的是“做過哪些重構(gòu)”，因為得到的回答非常明顯的兩級分化：一種是“基本沒怎么做過芥喇，我寫的時候就很注意了西采，不需要重構(gòu)”，或者說做過继控，但實際上只是因為前面代碼質(zhì)量太差而推翻重寫械馆；另一種是“非常常見胖眷，經(jīng)常會做”。在我看來霹崎，后一種工程師水平是比前一種要高一層次的珊搀。不是代碼寫得爛所以總要重構(gòu)去修改，而是隨著時間推移尾菇、業(yè)務(wù)變化境析，重構(gòu)是必須的，但只有對技術(shù)有追求错沽、對自己有要求的工程師才會發(fā)現(xiàn)這個問題簿晓、才會冒風(fēng)險去重構(gòu)。沒做過重構(gòu)千埃，要么說明他做項目沒深度憔儿、做一個扔一個，要么說明懶惰或過于忙碌放可，但無論如何是不可取的谒臼。

（篇幅已經(jīng)比較長了，剩余的內(nèi)容會放在 下 篇里耀里。有興趣看下去的話可以過段時間再來看蜈缤。）