面试了 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 程序员的人都是写不出这行代码的。我也一会儿明白了为何前面总说听不懂问题，由于他对我说的东西彻底没概念，脑子里一片空白。把责任推给我，伪装是我没问清楚，多是在这种情形下他惟一能作的防护了。

对于后面的面试者，我仍是会把这些问题拿几个出来问一问，但再也没有跟对方死磕。事实证实，对于比较优秀的那几个面试者，我历来不用多费口舌，轻轻一点就能立刻说出我想要的答案，真是十分畅快。这是我第一次意识到，沟通能力低的背后其实可能只是技术能力低。工程师之间的沟通技巧，背后是工程经验、架构水平和技术知识在支撑的。

就这几个问题而言，我以为一个比较有区分度的是“作过哪些重构”，由于获得的回答很是明显的两级分化：一种是“基本没怎么作过，我写的时候就很注意了，不须要重构”，或者说作过，但实际上只是由于前面代码质量太差而推翻重写；另外一种是“很是常见，常常会作”。在我看来，后一种工程师水平是比前一种要高一层次的。不是代码写得烂因此总要重构去修改，而是随着时间推移、业务变化，重构是必须的，但只有对技术有追求、对本身有要求的工程师才会发现这个问题、才会冒风险去重构。没作太重构，要么说明他作项目没深度、作一个扔一个，要么说明懒惰或过于忙碌，但不管如何是不可取的。

（篇幅已经比较长了，剩余的内容会放在 下 篇里。有兴趣看下去的话能够过段时间再来看。）