1 Star 0 Fork 72

楼方岳 / 设计模式之美

forked from BuxsRen / 设计模式之美 
加入 Gitee
与超过 1200万 开发者一起发现、参与优秀开源项目,私有仓库也完全免费 :)
免费加入
该仓库未声明开源许可证文件(LICENSE),使用请关注具体项目描述及其代码上游依赖。
克隆/下载
258207.md 7.02 KB
一键复制 编辑 原始数据 按行查看 历史
1kb 提交于 2021-07-06 11:10 . update

加餐九 | 作为面试官或候选人,如何面试或回答设计模式问题?

加餐六中,我们讲到,对于程序员的编程能力,我们一般从数据结构和算法、设计模式这两个方面来考察。加餐六重点讲到了如何考察数据结构和算法,今天,我们重点讲讲,如何考察设计模式。

除此之外,很多人反映,在面试中被问到设计模式问题的时候,一般都没有什么思路,基本都是想到哪说到哪。今天,我就总结一下回答设计模式相关面试题的一些套路,希望能让你在今后的面试中有章可循。

话不多说,让我们正式开始今天的内容吧!

作为面试官,如何面试设计模式问题?

有些面试官喜欢让候选人手写常用的设计模式,比如单例模式、工厂模式,以此来考察候选人对设计模式的掌握程度。实际上,对于比较常用的设计模式,盲写的要求并不过分,毕竟在开发中,徒手写个单例模式、工厂模式,也是常有的事情。

不过,这种偏向记忆的面试题目,实际上是一种应试考试的面试方式。一方面,它没有区分度,另一方面,候选人容易突击准备。这往往考察不出候选人真正的代码设计和实现能力。我们学习设计模式的初衷是提高代码质量。学习设计模式的重点,是掌握应用场景、能解决哪些问题,而非记忆定义、代码实现。所以,我面试时有个原则,不直接问记忆性问题和过于理论性问题。

筛选候选人就是筛选将来与你共事的人。我们面试的最终目的,还是希望能在短短的1小时内,粗略地看出候选人在今后工作中的表现。相对应的,在面试中考察候选人设计模式相关的知识,是看他在今后的项目中,能否写出易读、易扩展、易维护的高质量代码。

为了更准确地反映候选人在以后的工作中的表现,最好的面试方式是拿真实项目来考察,而且最好是候选人入职之后要参加的项目。当然,这个要求稍微有点高了。一般来讲,其实只要比较贴近真实项目就可以了。

对设计和代码能力的考察,我一般有两种面试思路。

第一种,给候选人一个功能需求,让他去做代码设计和实现,然后,基于他的代码实现,讨论代码的可读性、扩展性等代码质量方面的问题,然后让候选人继续优化,直到满意为止。第二种是,给候选人一段有质量问题的代码,让他去做Code Review,找出代码存在的问题,然后做代码重构。实际上,在我们的专栏中,很多文章中的例子,都符合刚刚两种面试思路。比如第25263940讲,3435讲,3637讲。你可以回过头去再看下。

这里我要重点强调一下,这种代码设计实现问题,本身没有标准答案,背景又过于复杂开放,如果只是丢给候选人回答,中间没有任何交流和引导,候选人很难抓住重点,展现出你心里期望的表现。所以,面试的过程切忌像笔试一样,一问一答单向沟通。相反,我们要把面试当做一场与未来同事的技术讨论,在讨论的过程中去感受候选人的技术实力。

当候选人写完代码之后,如果面试官一个问题都不提,然后就跳到其他面试题目,这种体验,不管是对候选人,还是面试官来说,都不是很好。相反,如果面试官能一语中的地提出设计中的缺陷,深入地跟候选人去讨论,这样一方面能给候选人充分发挥的机会,另一方面,也会赢来候选人对公司技术的认可。

作为候选人,如何回答设计模式问题?

刚刚我们从面试官的角度,讲解了如何面试设计模式相关的问题。现在,我们再从候选人的角度,讲下如何回答设计模式相关的问题。

刚刚我讲到,很多面试官喜欢让候选人手写常用设计模式的代码实现,虽然我本身比较讨厌这种面试方式,但保不齐有些面试官喜欢。应对这种面试问题,你只能面试前突击复习一下了。

刚刚我也讲到,我个人比较喜欢拿真实的功能需求和代码来面试候选人。一种面试题是给功能需求,让候选人写代码,另一种面试题是给代码,让候选人做Code Review和代码重构。针对这两种类型的面试题,我分别讲讲应该如何应对。

对于第一种面试题目,我们首先要明确需求。大部分情况下,面试官给出的功能需求,都是比较笼统、模糊的,这本身就是为了考察你的沟通能力、分析能力,是否能通过挖掘、假设、取舍,搞清楚具体的需求,梳理出可以执行落地的需求列表。

跟面试官确定好需求之后,就可以开始设计和实现了。前面也提到,面试的目的是考察候选人在真实项目开发中的表现。在工作中,我们都是从最简单的设计和实现方案做起,所以,回答这种设计面试题,也不要一下子就搞得太复杂,为了设计而设计,非得用些比较复杂的设计模式。

不过,在用最简单方式实现之后,你可以再讲一下,如何基于某某设计模式,进一步对代码进行解耦,进一步提高代码的扩展性。基于这种最简单的代码,再行讨论优化,这样跟面试官讨论起来,也会更加言之有物。这也能体现你的代码演进思维,以及具体问题具体分析的能力。更加详细的回答套路,你可以参看第1314讲。

比起第一种题目,第二种面试题目会更加明确、具体。你就把它当作一次真实的Code Review来回答就好了。对于如何进行Code Review,你可以回过头去再看下第34讲,里面有罗列一些Code Review的checklist。

实际上,回答这种没有固定答案的开放性问题,你要跟面试官多问多沟通,不要觉得问多了就是自己理解能力不够,就会导致面试官反感。相反,面试官不仅不会反感,反倒会觉得你是一个思路开阔、有想法的人。如果你只是自己闷头写代码,面试官有可能会觉得你不善沟通。

课堂讨论

作为面试官,你是如何考察候选人的代码设计和实现能力的呢?作为候选人,你遇到过最想吐槽的设计模式相关的面试题是什么样的?

欢迎留言和我分享,如果有收获,也欢迎你把这篇文章分享给你的朋友。

Java
1
https://gitee.com/LouisLoufy/design-pattern-books.git
git@gitee.com:LouisLoufy/design-pattern-books.git
LouisLoufy
design-pattern-books
设计模式之美
master

搜索帮助