T 面试了 20 个初 - 中级 iOS 工程师之后(上) - CocoaChina_让移动开发更简单

首页 >iOS开发

面试了 20 个初/中级 iOS 工程师之后(上)

2017-03-20 09:13 编辑: suiling 分类:iOS开发 来源:戴仓薯的简书

好几周没更新过我的博客了,因为这段时间实在是太忙了…… 先是自己换了工作,然后为了给之前公司找个出色的接班人,马上紧锣密鼓地开始了招聘。招聘花了一周时间,总共看了超过 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 程序员的人都是写不出这行代码的。我也一下子明白了为什么前面总说听不懂问题,因为他对我说的东西完全没概念,脑子里一片空白。把责任推给我,假装是我没问清楚,可能是在这种情形下他唯一能做的防御了。

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

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

(篇幅已经比较长了,剩余的内容会放在 下 篇里。有兴趣看下去的话可以过段时间再来看。)

搜索CocoaChina微信公众号:CocoaChina
微信扫一扫
订阅每日移动开发及APP推广热点资讯
公众号:
CocoaChina
我要投稿   收藏文章
上一篇:养一只”无限猴子”帮你测试
下一篇:今年第一个独立 App,TKeyboard,也是第一个开源项目
我来说两句
发表评论
您还没有登录!请登录注册
所有评论(0

综合评论

相关帖子

sina weixin mail 回到顶部