mirror of
https://github.com/cheetahlou/CategoryResourceRepost.git
synced 2025-10-01 07:36:43 +08:00
50 lines
7.2 KiB
Markdown
50 lines
7.2 KiB
Markdown
<audio id="audio" title="加餐九 | 作为面试官或候选人，如何面试或回答设计模式问题？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/48/04/486500f651600f15159f0362a53ce204.mp3"></audio>
|
||
|
||
在[加餐六](https://time.geekbang.org/column/article/255697)中，我们讲到，对于程序员的编程能力，我们一般从数据结构和算法、设计模式这两个方面来考察。加餐六重点讲到了如何考察数据结构和算法，今天，我们重点讲讲，如何考察设计模式。
|
||
|
||
除此之外，很多人反映，在面试中被问到设计模式问题的时候，一般都没有什么思路，基本都是想到哪说到哪。今天，我就总结一下回答设计模式相关面试题的一些套路，希望能让你在今后的面试中有章可循。
|
||
|
||
话不多说，让我们正式开始今天的内容吧！
|
||
|
||
## 作为面试官，如何面试设计模式问题？
|
||
|
||
有些面试官喜欢让候选人手写常用的设计模式，比如单例模式、工厂模式，以此来考察候选人对设计模式的掌握程度。实际上，对于比较常用的设计模式，盲写的要求并不过分，毕竟在开发中，徒手写个单例模式、工厂模式，也是常有的事情。
|
||
|
||
不过，这种偏向记忆的面试题目，实际上是一种应试考试的面试方式。一方面，它没有区分度，另一方面，候选人容易突击准备。这往往考察不出候选人真正的代码设计和实现能力。我们学习设计模式的初衷是提高代码质量。学习设计模式的重点，是掌握应用场景、能解决哪些问题，而非记忆定义、代码实现。所以，我面试时有个原则，不直接问记忆性问题和过于理论性问题。
|
||
|
||
筛选候选人就是筛选将来与你共事的人。我们面试的最终目的，还是希望能在短短的1小时内，粗略地看出候选人在今后工作中的表现。相对应的，在面试中考察候选人设计模式相关的知识，是看他在今后的项目中，能否写出易读、易扩展、易维护的高质量代码。
|
||
|
||
为了更准确地反映候选人在以后的工作中的表现，最好的面试方式是拿真实项目来考察，而且最好是候选人入职之后要参加的项目。当然，这个要求稍微有点高了。一般来讲，其实只要比较贴近真实项目就可以了。
|
||
|
||
**对设计和代码能力的考察，我一般有两种面试思路。**
|
||
|
||
第一种，给候选人一个功能需求，让他去做代码设计和实现，然后，基于他的代码实现，讨论代码的可读性、扩展性等代码质量方面的问题，然后让候选人继续优化，直到满意为止。第二种是，给候选人一段有质量问题的代码，让他去做Code Review，找出代码存在的问题，然后做代码重构。实际上，在我们的专栏中，很多文章中的例子，都符合刚刚两种面试思路。比如第[25](https://time.geekbang.org/column/article/179644)、[26](https://time.geekbang.org/column/article/179673)、[39](https://time.geekbang.org/column/article/193221)、[40](https://time.geekbang.org/column/article/193555)讲，[34](https://time.geekbang.org/column/article/190979)、[35](https://time.geekbang.org/column/article/191621)讲，[36](https://time.geekbang.org/column/article/191642)、[37](https://time.geekbang.org/column/article/191647)讲。你可以回过头去再看下。
|
||
|
||
这里我要重点强调一下，这种代码设计实现问题，本身没有标准答案，背景又过于复杂开放，如果只是丢给候选人回答，中间没有任何交流和引导，候选人很难抓住重点，展现出你心里期望的表现。所以，面试的过程切忌像笔试一样，一问一答单向沟通。相反，我们要把面试当做一场与未来同事的技术讨论，在讨论的过程中去感受候选人的技术实力。
|
||
|
||
当候选人写完代码之后，如果面试官一个问题都不提，然后就跳到其他面试题目，这种体验，不管是对候选人，还是面试官来说，都不是很好。相反，如果面试官能一语中的地提出设计中的缺陷，深入地跟候选人去讨论，这样一方面能给候选人充分发挥的机会，另一方面，也会赢来候选人对公司技术的认可。
|
||
|
||
## 作为候选人，如何回答设计模式问题？
|
||
|
||
刚刚我们从面试官的角度，讲解了如何面试设计模式相关的问题。现在，我们再从候选人的角度，讲下如何回答设计模式相关的问题。
|
||
|
||
刚刚我讲到，很多面试官喜欢让候选人手写常用设计模式的代码实现，虽然我本身比较讨厌这种面试方式，但保不齐有些面试官喜欢。应对这种面试问题，你只能面试前突击复习一下了。
|
||
|
||
刚刚我也讲到，我个人比较喜欢拿真实的功能需求和代码来面试候选人。一种面试题是给功能需求，让候选人写代码，另一种面试题是给代码，让候选人做Code Review和代码重构。针对这两种类型的面试题，我分别讲讲应该如何应对。
|
||
|
||
对于第一种面试题目，我们首先要明确需求。大部分情况下，面试官给出的功能需求，都是比较笼统、模糊的，这本身就是为了考察你的沟通能力、分析能力，是否能通过挖掘、假设、取舍，搞清楚具体的需求，梳理出可以执行落地的需求列表。
|
||
|
||
跟面试官确定好需求之后，就可以开始设计和实现了。前面也提到，面试的目的是考察候选人在真实项目开发中的表现。在工作中，我们都是从最简单的设计和实现方案做起，所以，回答这种设计面试题，也不要一下子就搞得太复杂，为了设计而设计，非得用些比较复杂的设计模式。
|
||
|
||
不过，在用最简单方式实现之后，你可以再讲一下，如何基于某某设计模式，进一步对代码进行解耦，进一步提高代码的扩展性。基于这种最简单的代码，再行讨论优化，这样跟面试官讨论起来，也会更加言之有物。这也能体现你的代码演进思维，以及具体问题具体分析的能力。更加详细的回答套路，你可以参看第[13](https://time.geekbang.org/column/article/171760)、[14](https://time.geekbang.org/column/article/171767)讲。
|
||
|
||
比起第一种题目，第二种面试题目会更加明确、具体。你就把它当作一次真实的Code Review来回答就好了。对于如何进行Code Review，你可以回过头去再看下[第34讲](https://time.geekbang.org/column/article/190979)，里面有罗列一些Code Review的checklist。
|
||
|
||
实际上，回答这种没有固定答案的开放性问题，你要跟面试官多问多沟通，不要觉得问多了就是自己理解能力不够，就会导致面试官反感。相反，面试官不仅不会反感，反倒会觉得你是一个思路开阔、有想法的人。如果你只是自己闷头写代码，面试官有可能会觉得你不善沟通。
|
||
|
||
## 课堂讨论
|
||
|
||
作为面试官，你是如何考察候选人的代码设计和实现能力的呢？作为候选人，你遇到过最想吐槽的设计模式相关的面试题是什么样的？
|
||
|
||
欢迎留言和我分享，如果有收获，也欢迎你把这篇文章分享给你的朋友。
|