中高级技术面试考察过程中的关键点

曾经根据自己的面试经验写过，这是一种标准化，流程化的方式，用于考察一个人的方方面面，然而，一次面试时间不过短短30，40分钟，在这段时间内，要全面的考察一个人是一项挑战。有时候，候选人各有优点和缺点，比如，有些人对自己项目的业务比较熟悉，方方面面也能回答出一二来，但技术点往深了问就不知所措了，有些人对某几个技术点的深入总能自圆其说，但不熟悉以前项目的核心业务，面试的时候准备也不够充分，又有些人，看他平时做的项目也比较多，但笔试的时候许多题目却做得一团糟。因此，面试者要把握面试中的关键点，特别是在中高级面试中，对面试者的综合能力要求比较高，不妨换一个角度来考虑面试的过程，以一种敏捷的，带有重点的节奏来考察。

你可以想象，这哥们明天就要来了，可以被安在一个什么岗位上呢，他就坐我旁边，以后能够顺畅地进行合作，给公司的项目进展带来帮助吗？他是一个只会背答案的人吗？是一个沟通不顺畅的人吗？是一个对眼前的bug和优化点漠不关心的人吗？他对现有项目的维护和优化会起到多大帮助？所以，面试嘛，聊得投机，感觉好就行。

这种方式在大公司的成熟团队中几乎不可能，因为有固定的流程和标准，在快节奏的创业公司，却有实施的可能，但是它靠谱吗？靠谱，但是对面试考察者的要求比较高，即他的直觉要对，而直觉是基于过往的阅历和技术经验的。因此，考察还是要遵循一定规范的，按着规范操作的时间久了，便自然形成了透过表象看透本质的直觉。

直接目标是考察一个人，据此确定此人能力是否够的上期望薪资，和公司岗位是否匹配。

那重点考察什么呢？我觉得是一种面对问题的态度和思路，即他的态度是否积极，解决问题的思路是否能自圆其说，这是技术特长和性格特质相结合的产物，是一种普通人需要长期的技术积累才能拥有的综合能力，不是靠临时背背书，看看资料，做做样子能够表现出来的。比如你问一个问题，虽然有点难度，但稍加提醒即可打通思路，而面试者却很快气馁放弃思考，或者所说方案前后矛盾而不自知，这都是有问题的。

因此，面试过程中，结合其以往项目具体业务考察其技术特长是一种不错的方式，如果他对某个框架比较了解，就直接问框架知识。

比如，他简历中有这么一段认为最出彩的项目经历：

给小贷公司开发一个小额信贷平台，涉及信贷，财务，账务，银企直连，客户关系等多个模块，投资规模数千万，采用springboot+zookeeper+kafka+grpc+redis等技术。

那么，面试中也许会这么提问：

问：你们kafka主要用于什么业务场景？

答：主要用于模块之间的解耦和异步化操作，比如信贷模块，贷款主流程任务执行完毕，将相关数据推送给财务系统，财务系统作为消费者，从消息队列中fetch数据进行凭证制作、记账。

问：怎么防止消息重复消费？

答：我们是在业务端口实现消息去重功能的，消息是放在表里，并且初始化状态，每次消费前都会忽略已经消费过的消息。

问：你们并发量多少？频繁地对数据表读取消息不会造成很大压力吗？

答：没多少并发，上线没几个月.......（说明这套技术系统没有充分经过实战检验，接下来的问题将会超过面试者的技术实战范围。）

问：但万一平时活动，并发量上来了，发送端插入消息的时候数据库响应延迟，那可以怎么改进？你们为什么要有消息插入数据库这一步，消息已经在消息队列里了？

答：这是出于业务操作原子性的考虑，由于消息发送速度比贷款操作事务提交更快，为保证任务顺序执行，贷款业务和相关消息发送是分开放在前后两个事务中的，又为了防止贷款业务事务提交后，消息发送失败导致业务中断、不完整的情况，我们在贷款业务事务内加入了在表中插入消息的操作？

问：那为什么不从保证消息队列本身的可靠性角度出发呢？ 对事务消息有没有了解？

答：对事务消息不是很了解，但我理解事务的概念，我们操作数据库用的就是事务，操作失败就会回滚。

问：在这个业务中有这样一种异常情况，即贷款业务执行成功了，消息却没有发送成功，对此，除了你原来项目中通过本地消息表，借助数据库的事务机制来实现回滚外，还能通过什么方式呢？一定要回滚吗？

答：这个没怎么细想过.......

面试感想：从面试中大概可知，面试者能结合具体业务场景，使用一些中间件，有一定的设计方面的经验，但对相关中间件不是非常熟，限于一般使用层面，一般的业务开发没有问题。

比如，他曾经的项目就只用过ssm那一套技术体系，那么面试过程大概是这样的：

问：为了提高开发效率，有没有用过mybatis自动生成代码的一些功能没有？

答：mybatis-generator

问：那为了在自动生成model的时候根据数据表里的注释自动生成注释，可以怎么改造呢？

答：.......

问：spring mvc中的controller和servlet有什么区别？

答：这......平时用的都是controller，servlet好久没接触了。。。

面试感想：如果项目中没有复杂的业务逻辑，也没有担任管理方面的工作，业余也没有钻研其他的技术，那为什么不好好钻研下目前项目正在使用的框架呢，如果自己来造轮子，该怎么去做？

上面的过程主要是招有一定设计能力和架构意识的中高级程序员，有时候，如果只要求会一般的业务开发，招人又比较急，可以问一个开发中的细节问题，这都不是面试题集中会出现的，比如：“tomcat中的负载均衡是怎么配置的？” 有个小伙伴毕业工作一年多换工作面试就被问了这么一个问题，第二天就去上班了。

考察的过程其实是一个从有招到无招，从方法论到直觉的过程，如果中间发现偏差，需要引入新的方法来修正你的直觉。时间久了，你会发现有些人只要见一面，聊几句，就大抵知道他适不适合这个团队和岗位了。做其他事情，包括技术，规律也大抵如此吧。