1 引言
据不完全统计，自12年参加实习到14年正式工作以及15年10月来到美团，我大小参加过约80场面试，其中约20场是以面试官的身份进行。下面分享一下我作为面试官的一些思考与总结。
2 基础知识
2.1 相关定义
一般来说，在接触到一个新事物的时候，我们总习惯先对相关理论知识进行学习。比如，最基本的，要了解面试、面试者和面试官的定义，以及三者的关系。相关细节我们不展开，可以直接Google。
2.2 面试流程
按照时间先后顺序，面试大约有如下环节。首先，流程发起，即上级或者HR发起流程告诉你于X时间，Y地点，面试Z人，跟记叙文三要素一样，通常此时你会看到该面试者的简历。其次，面试前准备，面试前准备主要是针对面试者的简历，找出一些你感兴趣的地方，根据这些兴趣点预先想好一些问题并记录下来，作为面试过程中的参考问题。再次，面试过程，即面试官跟面试者问答的过程，此时需要简要记录问答过程，并有理有据的做出合理判断。最后，结论输出，根据面试过程中面试者对相关问题的回答来确认该面试者是否通过面试并邮件周知相关人员（附上面试记录）。
3 一些考察点
3.1 流程熟悉度
流程熟悉度类问题适用于有一定工作年限或者是有项目管理经验的面试者。基础能力模型是熟悉项目迭代流程，如需求，排期，开发，测试，灰度，上线等。判断一个面试者是否真正参与过这些流程有一个比较简单的方式，就看他使用的工具。比如，在排期阶段我们使用的工具比较简单就是wiki文档+日历+jira。专业一点的团队可能会使用OmniPlan。再比如，开发中他们使用git吗?是gitflow来协作的吗？对CI是否了解，知道CI系统的组成元素吗？TestCase是通过专业系统给出的吗，还仅仅是word文档？对后台日志系统是否熟悉？鉴于这些东西我也只是粗浅了解，就不过多展开。
3.2 业务理解
业务理解度问题适用于每个业务开发者。他是否对自己所做的业务熟悉，能屡清楚业务流程吗？知道业务都有哪些坑吗?针对这种坑有采取措施吗？他的这些措施是否会产生副作用？他自己清楚副作用吗？几乎没有完美的方案，有的只是适合当前业务的方案。举个例子，某次一个做打车软件的面试者，说他针对订单状态机紊乱的问题做了状态机切换的客户端校验。这种手段当然能解决状态机紊乱，但是可能带来的副作用就是客户端强感知业务状态变化固化业务逻辑。面试者对具体方案的细节点处理是否了解。再举一个例子，有一次一个面试者说他参与设计了一套换肤系统。恰好我也做过类似模块。那么他对资源包格式，断点下载，并发下载，下载进度交互，下载解压失败处理，这些东西是否真正了解。询问对方领域技术模型，比如打车电商这些APP，一般都会涉及状态机模型。工具类App，可能会涉及网络资源配置模型。资讯类App，一般会涉及缓存模型。他在模型描述过程中的理由是否充分成为业务理解度的重要指标。
3.3 知识储备
基础知识这个一般问的也比较多，基本就是分两大块，iOS相关和CS基础，这种问题基本网上都有相关资料，这里也不过多展开。一般就是看谁的储备多。
3.4 通用技术
经常有面试者在简历上写他参与团队的Code Review，那么他经常Review出哪些问题呢？针对这些问题，他是否有总结，形成规范，达成一致，方便后来人。还有一些同学在简历上写他进行崩溃的处理，那么他是否有对crash类型，crash日志格式，常见的crash有总结，是否规约化了。还有就是性能优化，基本的套路是问题发现，原理调研，业界方案，方案选择，效果验证， 规约化，工具化。然后就是二次封装，经常会有开发者在简历上写熟悉XX开源库的原理，那么他是否参与过开源库的二次封装呢？比如网络库，通参添加，GET网络请求去重，服务器宕机处理，这些点是怎么搞的。SDWebImage，图片尺寸参数什么，失败retry什么的怎么做的？这些点都能体现水平。
4 后记
这篇博文是17年5月为团队培养新面试官所作，距今半年有余。这半年随着个人眼界和水平的提升，对面试这件事又有些新的认识。比如文中尚未提及问题解决能力，这个点这里也不详谈，之后的面试中会重点关注。