如何在技术初试中考察程序员的技术能力

考察目标和思路

首先明确,技术初试的考察目标:

  • 候选人的技术基础;
  • 候选人解决问题的思路和能力。

技术基础是基石(冰山之下的东西),占七分, 解决问题的思路和能力是落地(冰山之上露出的部分),占三分。 业务和技术基础考察,三七开。


为什么要考察技术基础

程序员最重要的两种技术思维能力,是逻辑思维能力和抽象设计能力。逻辑思维能力是基础,抽象设计能力是高阶。 考察技术基础,正好可以同时考察这两种思维能力。能不能理解基础技术概念及关联,是考察逻辑思维能力;能不能把业务问题抽象成技术问题并合理的组织映射,是考察抽象设计能力。

绝大部分业务问题,都可以抽象成技术问题。在某种意义上,业务问题只是技术问题的领域化表述。

因此,通过技术基础考察候选者,才能考察到候选者的真实技术实力:技术深度和广度。


为什么不能单考察业务维度?

因为业务方面通常比较熟悉,可能就直接按照现有方案说出来了,很难考察到候选人的深入理解、横向拓展和归纳总结能力。

这一点,建议有针对性地考察下候选人的归纳总结能力:比如, 微服务搭建或开发或维护/保证系统稳定性或性能方面的过程中,你收获了哪些可以分享的经验?


为什么要考察业务维度?

技术基础考察,容易错过的地方是,候选人的非技术能力特质,比如沟通组织能力、带项目能力、抗压能力、解决实际问题的能力、团队影响力、其它性格特质等。


技术基础考察

技术基础怎么考察?通过有效的多角度的发问模式来考察。


是什么-为什么

是什么考察对概念的基本理解,为什么考察对概念的实现原理。

比如 索引是什么? 索引是如何实现的?


引导-横向发问-深入发问

引导性,比如 “你对 java 同步工具熟悉吗?” 作个试探,得到肯定答复后,可以进一步问: “你熟悉哪些同步工具类?” 了解候选者的广度;

获取候选者的回答后,可以进一步问:“ 谈谈 ConcurrentHashMap 或 AQS 的实现原理?”

一个人在多大程度上把技术原理能讲得清晰,包括思路和细节,说明他对技术的掌握能力有多强。


跳跃式/交叉式发问

  • 比如,讲到哈希高效查找,可以谈谈哈希一致性算法 。 两者既有关联又有很多不同点。也是一种技术广度的考察方法。

总结性发问

  • 比如,你在做 XXX 中,获得了哪些可以分享的经验? 考察候选人的归纳总结能力。

实战与理论结合

  • 比如,候选人叙述 JVM 内存模型布局之后,可以接着问:有哪些原因可能会导致 OOM , 有哪些预防措施? 你是否遇到过内存泄露的问题? 如何排查和解决这类问题?

  • 比如,候选人有谈到 SQL 优化和索引优化,那就正好谈谈索引的实现原理,如何建立最佳索引?

  • 比如,候选人有谈到事务,那就正好谈谈事务实现原理,隔离级别,快照实现等;


熟悉与不熟悉结合

针对候选人简历上写的熟悉的部分,和没有写出的都问下。比如候选人简历上写着:熟悉 JVM 内存模型, 那我就考察下内存管理相关(熟悉部分),再考察下 Java 并发工具类(不确定是否熟悉部分)。


死知识与活知识结合

比如,查找算法有哪些?顺序查找、二分查找、哈希查找。这些大家通常能说出来,也是“死知识”。

这些查找算法各适用于什么场景?在你工作中,有哪些场景用到了哪些查找算法?为什么? 这些是“活知识”。


学习或工作中遇到的

有时,在学习和工作中遇到的问题,也可以作为面试题。

比如,最近在学习《操作系统导论》并发部分,有一章节是如何使数据结构成为线程安全的。这里就有一些可以提问的地方:如何实现一个锁?如何实现一个线程安全的计数器?如何实现一个线程安全的链表?如何实现一个线程安全的 Map ?如何提升并发的性能?

工作中遇到的问题,也可以抽象提炼出来,作为技术基础面试题。


技术栈适配度发问

如果候选人(简历上所写的)使用的某些技术与本公司的技术栈比较契合,则可以针对这些技术点进行深入提问,考察候选人在这些技术点的掌握程度。如果掌握程度比较好,则技术适配度相对更高一些。

当然,这一点并不能作为筛掉那些没有使用该技术栈的候选人的依据。比如本公司使用 Mongodb 和 MySQL, 而一个候选人没有用过 Mongodb, 但使用过 MySQL, Redis, ES, HBase 等多种存储系统,那么适配度并不比仅使用过 MySQL 和 Mongodb 的候选人逊色,因为他所涉及的技术广度更大,可以推断出他有足够能力掌握 Mongodb。

创造有个性的面试题库

每个技术面试官都会有一个面试题库。持续积累面试题库,日常中突然想到的问题,就随手记录下来。


解决问题能力考察

仅仅只是技术基础还不够,通常最好结合实际业务,针对他项目里的业务,抽象出技术问题进行考察。

解决思路重在层层递进。这一点对于面试官的要求也比较高,兼具良好的倾听能力、技术深度和业务经验。首先要仔细倾听候选人的阐述,找到适当的技术切入点,然后进行发问。如果进不去,那就容易考察失败。

设计问题

  • 比如多个机器间共享大量业务对象,这些业务对象之间有些联合字段是重复的,如何去重?

  • 如果瞬时有大量请求涌入,如何保证服务器的稳定性?


项目经历

项目经历考察不宜超过两个。因为要深入考察一个项目的详情,所占用的时间还是比较大的。

一般来说,会让候选人挑选一个他或她觉得最有收获的/最有挑战的/印象最深刻的/自己觉得特有意思的项目。然后围绕这个项目进行发问。通常是从项目背景出发,考察项目的技术栈、项目模块及交互的整体理解、项目中遇到的有挑战性的技术问题及解决方案、排查和解决问题、代码可维护性问题、工程质量保障等。


面试过程

预先准备

面试官也需要做一些准备。比如熟悉候选者的技能优势、工作经历等,做一个面试设计。

在面试将要开始时,做好面试准备。此外,面试官也需要对公司的一些基本情况有所了解,尤其是公司所使用技术栈、业务全景及方向、工作内容、晋升制度等,这一点技术型候选人问得比较多。


面试启动

一般以候选人自我介绍启动,不过候选人往往会谈得比较散,因此,我会直接提问:谈谈你有哪些优势以及自己觉得可以改进的地方?

然后以一个相对简单的基础题作为技术提问的开始:你熟悉哪些查找算法?大多数人是能答上顺序查找、二分查找、哈希查找的。

问题设计

提前阅读候选人简历,从简历中筛选出关键词,根据这些关键词进行有针对性地问题设计。

比如候选人简历里提到 MVVM ,可以问 MVVM 与 MVC 的区别; 提到了观察者模式,可以谈谈观察者模式,顺便问问他还熟悉哪些设计模式。

宽松氛围

即使问的问题比较多比较难,也要注意保持宽松氛围。

在面试前,根据候选人基本信息适当调侃一下,比如一位候选人叫汪奎,那我就说:之前我们团队有位叫袁奎,我们都喊他奎爷。

在面试过程中,适当提示,或者给出少量自己的看法,也能缓解候选人的紧张情绪。


学会倾听

多问少说,让候选者多表现。根据候选者的回答适当地引导或递进或横向移动。

引导候选人表现他最优势的一面,让他或她感觉好一些:毕竟一场面试双方都付出了时间和精力,不应该是面试官 Diss 候选人的场合,而应该让彼此有更好的交流。很大可能,你也能从候选人那里学到不少东西。

面试这件事,只不过双方的角色和立场有所不同,但并不代表面试官的水平就一定高于候选人。


记录重点

认真客观地记录候选人的回答,尽可能避免任何主观评价,亦不作任何加工(比如自己给总结一下,总结能力也是候选人的一个特质)。


多练习

模拟面试?


作出判断

面试过程是一种铺垫,关键的是作出判断。

作出判断最容易陷入误区的是:贪深求全。总希望候选人技术又深入又全面。实际上,这是一种奢望。如果候选人的技术能力又深入又全面,很可能也会面临两种情况:1. 候选人有更好的选择; 2. 候选人在其它方面可能存在不足,比如团队协作方面。

一个比较合适的尺度是:1. 他或她的技术水平能否胜任当前工作; 2. 他或她的技术水平与同组团队成员水平如何; 3. 他或她的技术水平是否与年限相对匹配,是否有潜力胜任更复杂的任务。


不同年龄看重的东西不一样

对于三年以下的工程师,应当更看重其技术基础,因为这代表着他的未来潜能;同时也考察下他在实际开发中的体现,比如团队协作、业务经验、抗压能力、主动学习的热情和能力等。

对于三年以上的工程师,应当更看重其业务经验、解决问题能力,看看他或她是如何分析具体问题,在业务范畴内考察其技术基础的深度和广度。

如何判断一个候选人的真实技术水平及是否适合所需,这方面,我也在学习中。


给候选人的话

为什么候选人需要关注技术基础

一个常见的疑惑是:开发业务系统的大多数时候,基本不涉及数据结构与算法的设计与实现,为什么要考察 HashMap 的实现原理?为什么要学好数据结构与算法、操作系统、网络通信这些基础课程?

现在我可以给出一个答案了:

  • 正如上面所述,绝大多数的业务问题,实际上最终都会映射到基础技术问题上:数据结构与算法的实现、内存管理、并发控制、网络通信等;这些是理解现代互联网大规模程序以及解决程序疑难问题的基石,—— 除非能祝福自己永远都不会遇到疑难问题,永远都只满足于编写 CRUD;

  • 这些技术基础正是程序世界里最有趣最激动人心的地方。如果对这些不感兴趣,就很难在这个领域里深入进去,不如及早转行从事其它职业,非技术的世界一直都很精彩广阔(有时我也想多出去走走,不想局限于技术世界);

  • 技术基础是程序员的内功,而具体技术则是招式。徒有招式而内功不深,遇到高手(优秀同行从业者的竞争及疑难杂症)容易不堪一击;

  • 具备扎实的专业技术基础,能达到的上限更高,未来更有可能胜任复杂的技术问题求解,或者在同样的问题上能够做到更好的方案;

  • 人们喜欢跟与自己相似的人合作,牛人倾向于与牛人合作能得到更好的效果;如果一个团队大部分人技术基础比较好,那么进来一个技术基础比较薄弱的人,协作成本会变高;如果你想和牛人一起合作拿到更好的结果,那就要让自己至少在技术基础上能够与牛人搭配的上;

  • 在 CRUD 的基础上拓展其它才能也不失为一种好的选择,但这不会是一个真正的程序员的姿态,顶多是有技术基础的产品经理、项目经理、HR、运营、客满等其它岗位人才。这是职业选择的问题,已经超出了考察程序员的范畴。


不要在意某个问题回答不上来

如果面试官问你很多问题,而有些没有回答上来,不要在意。面试官很可能只是在测试你的技术深度和广度,然后判断你是否达到某个水位线。

重点是:有些问题你答得很有深度,也体现了你的深度思考能力。

这一点是我当了技术面试官才领会到的。当然,并不是每位技术面试官都是这么想的,但我觉得这应该是个更合适的方式。


参考资料:

技术面试官的9大误区


posted @ 2021-08-21 13:36  琴水玉  阅读(134)  评论(0编辑  收藏  举报