当面试官问你这个问题的时候，他想听到什么？

你好呀，我是歪歪。

这期我想简单的聊一个面试中出现频率比较高的，但又没有标准答案的面试题。

你在工作中遇到过印象深刻的困难是什么，你怎么克服的？

为什么我想聊聊这个问题呢？

因为我发现这个问题经常出现在各个技术交流群中，大家聊到这个话题的时候大多都苦不堪言，纷纷表示不知道怎么去回答这个问题。

或者说之前就没有想过这样的问题，突然一下被问起来，由于没有准备，也是摸不着头脑的样子。

匆匆的回顾一下自己的职业生涯，发现天天写的都是 crud，也没觉得有什么困难啊。

一时间，竟然想脱口而出：我觉得吧，也没有啥特别大的困难，我做的就挺好的。

面试官听了微微一笑：好了，那我们今天的面试就先到这里，请回去等通知吧。

考的是什么

你必须要知道正常情况下面试官在面试的过程中问的每一个问题，都一定是有他的目的。

比如面试官上来就要求候选人做个简单的自我介绍，很多人说这个目的是为了在候选人自我介绍的时间内看一下他的简历。

也许在早几年，要候选人自己带着简历去面试的情况下，确实是这样的。

但是现在来说，都是无纸化面试了，你的简历的电子版早就到面试官手上了。

正常来说，面试官会在面试之前已经看过你的简历了，不需要面试的时候借着你自我介绍的时间，浏览简历。

我一般让候选人自我介绍的时候，我是在认真的听，我想要从他的自我介绍找挖掘到简历上没有体现的东西，也是在寻找面试的切入点，如果自我介绍中有让我感兴趣的地方，我就会从这个地方开始，围绕着简历往下问。

再比如，问你项目的时候：

说一下你最熟悉的项目。

是问你项目是干啥的，业务场景有哪些吗？

不是的。

问这个问题的目的是想知道你所熟悉的项目的架构是怎么样的，是单体服务还是拆了微服务，拆了哪些模块，每个服务大概多大的体量，它们之间是怎么相互的，涉及到的技术栈有哪些。

知道了这些，面试官才能从中找到讨论的点，从而展开技术面试。

至于项目是干啥的，简单说几句，铺垫一个背景就行了。

有的同学介绍项目的时候把领导在业务上给他画的饼，又给面试官描述一遍。如果不是同一业务线的话，面试官是不会关心你的业务的。

你要知道，如果你要介绍业务场景的话，其目的必然是为了引出背后的一个比较复杂的技术解决方案。否则，面试官不会太感兴趣，多说无益，反而占用了面试的时长。

还不如拿出纸笔，在上面画一下你们的服务交互，同时描述一下对应地方涉及到的技术栈。

再说这个问题：

你在工作中遇到过印象深刻的困难是什么，你怎么克服的？

有的同学说他不会回答，我分析了一下，不会回答的原因其实就是因为不知道面试官考察的是什么方向。

所以只能给出一些诸如查询慢了就加索引、热点数据加缓存、出了问题重启了就好了...这类泛泛地回答，找不到什么让面试官眼前一亮的东西。

怎么能答的闪亮一点呢？

一般来说，我认为这个题有两个回答的方向。

第一个方向就是往技术的深度，对于技术的追求这个方向答。想看看你有没有碰到过什么棘手的技术问题，然后是怎么定位，怎么解决的。

第二个方向就是往主人翁意识，体现主观能动性的方向答。面对一个项目或者领导给到的任务涉及到其他项目组、甚至其他部门的时候，自己是怎么去推动的。

技术的深度

如果你往这个方法答，就得自己平时工作中多积累，多观察相关的案例，然后记录下来。

可以把观察的目光放的长远一点，不一定非得是自己所在的项目组遇到的问题，也可以是其他的项目组遇到的问题。

这里就需要自己有一个情报收集的能力，和对于技术的敏感度。

一听到这问题就应该要知道：这是一个好素材呀，可以深入了解一下。

这个问题都不一定是你解决的，但是你要清楚的知道来龙去脉，就可以包装成自己的经历。

面试官是察觉不出来的。

而且我一直认为，适度的包装，也不算是面试造假。

当然了，这个方向你也可以去背。

但是不能纯粹的背诵，得适当的去扩展。

比如我之前分享过一篇关于 Dubbo 调用超时的文章。

从最开始 Dubbo 调用超时的这个表象，分别从数据库、GC、网络、链路追踪等各个角度去分析了问题，且是一个循序渐进的过程。

你会发现大家对于超时这一类的问题的排查套路都无外乎这样，层层递进的排查，抽丝剥茧的寻找问题。

这个案例你就是可以自己拿去用的，套一个自己工作相关的业务场景。

我就不信了，你们接口调用没出现过超时的情况？

网上这样的文章很多很多，但是作者写的只专注于面试问题的本身。

如果你想要把这个案例套过来自己用，那么而这个问题能延伸出来的东西，你也必须得去研究。

比如前面这个文章里面，为什么要说“失败策略是 failFast，快速失败不会重试”？因为如果是failover，会默认重试，且超时时间是重试时间之和。所以，他告诉我们，这里没有重试，超时不是因为请求重试带来的时间叠加导致的。

文章提到的 ElapsedFilter 过滤器，“超过 300 毫秒的接口耗时都会打印”，是作者公司自己扩展的 Filter，基于Dubbo 的 SPI 实现的，并不是 Dubbo 官方的自带功能。所以，他才额外提了一句“ElapsedFilter是 Dubbo SPI 机制的（自定义）扩展点之一”。

作者用的 Druid 连接池，猜测连接长时间不被使用后都回收了，那么关于 Druid 的配置文件中的有关时间的配置，你是否知道且清楚其作用？

如果要观察 GC 日志，你是否大概知道应该配置什么参数，是否知道应该关注的信息是什么？为什么他这里要提到安全点？安全点和 STW 的时间之间的关系又是什么？

等等后面的一些关于容器的、Arthas工具使用的、网络抓包工具使用的相关技能和知识储备。

当我们把这些知识单独拎出来形成面试题的时候，也许你会觉得，为什么你老是问我 MySQL 的知识、问我网络相关的知识、问我一些用不上的垃圾回收的知识？

问你，把你问的哑口无言不是目的。考察你知识的广度，让你学以致用才是目的。

重要的是把你学的一个个孤立的点，通过某种方式，串联起来。

而“你在工作中遇到过印象深刻的困难是什么”就是你把这些知识点串联起来的一种方式。

另外，还有一个人尽皆知的面试小窍门。

回答问题的时候尽量有意识的引导面试官到自己熟悉的领域中来。

怎么引导呢？

不可能别人问你：你给我说一下线程池吧？

你回答说：这多没意思啊，我给你说一下 HashMap 吧。

面试官一定当时就觉得自己的头大。

我们可以在这些开放的问题上就可以去引导面试官。

如果你对 kafak、RabbitMQ、RocketMQ 这一类技术了解的比较深入，又或者对于 Redis、MySQL 这一类存储的技术学习的比较多，你准备这类问题的时候就可以多讲这方面的原因。

比如如果让我来讲，我可能就会选择回答一些由于 Dubbo 框带来的技术问题，让面试官进入到我熟悉的领域，让他在这里面和我展开博弈。

再或者说往 JVM 方向引导，反正大家学这东西，看的都是同一份资料，就看你记得多还是我记得多了。

又或者我们可以 battle 一下多线程领域相关的问题，但是现在多线程都烂大街了，我可能不太会去在这里面和面试官博弈太长时间。因为就算你回答的滴水不漏，面试官大多也会认为这只是需要掌握的基本技能而已，用的熟练，不足为奇，没有闪光点。

总之一句话吧：如果你向往技术的深度这方面去回答，一定要言之有物，最终定位到的问题可以是一个很小的问题，比如配置的原因、网络的原因、框架的 bug，但是重点得体现出排查的过程。而排查问题的过程，有一定的方法论，提炼出来就好了。

对于这个问题，上策是加工一下自己的亲身经历，实实在在的有解决问题的经验，只是如何把它包装的高大上而已。

下策是包装别人的经历，要包的惟妙惟肖，以假乱真。

如果你真的很无奈要选下策，那么我只能再送你一句话了：加入一些细节的描述，可以是点击工具的什么按钮、翻看了什么类的源码、参照了某个大牛的博客一类的。

能不能过，就看你的造化了。

主观能动性

主观能动性这方面其实我没有什么特别想要说的。

核心思想就是前面说的：主人翁意识。

你所负责的任务，是别人分配给你的。但是你就是这个任务的主人翁，你要想着怎么去积极主动的去完成它。

举个例子：

你本来只是一个写着 crud 的快乐的程序员，每天等着领导分配任务，然后领任务写代码。

突然有一天，领导给你说：小王啊，这边有一个项目很着急，但是我这边有更加紧急的事情要做，所以我把这个任务分配给你，你去全权负责一下吧。

你当时就懵逼了，敲键盘的手一下就不快乐了。

这意味着你不再是一个只写代码的程序员了，你还是一个项目的负责人。

一个项目的负责人得统筹帷幄，去协调需求、产品、开发、测试、运维等各方面的资源。

而这事儿，你之前从来没干过。要命的是，这事还挺着急。

怎么办？

这不就是你在工作中遇到的印象深刻的困难吗？

场景框架都给你了，你就按照你们公司的流程往里面填内容就行了。

你是怎么拆分任务的，怎么组织评审会的，最后项目成功上线自己的收获是什么。

可以多讲点从程序员视野看不到的东西。着重体现自己协调资源和跨部门合作时遇到的困难和自己的解决方案。

什么，你说你没有这个方面的经历？

你就不能假设吗？

你就不能观察你们公司的一个项目周期的全过程吗？

得发挥你的主观能动性呀。

然后再说一下，如果你往这个方向去回答，大概率会遇到一个追问的问题：

如果让你再来一次，你会怎么处理的更好。

这玩意考的又是什么？

考的就是你的复盘的能力，考的就是有没有对于项目进行复盘。

如果你回答说：由于是我第一次负责一个项目，并跟进了它一期需求的全过程，所以对我来说是一次非常宝贵的经历，于是在项目上线之后我对其进行了一次复盘，发现了其中还有一二三四点可以优化的地方...

我觉得基本上朝着这个方法回答就十拿九稳了。

你要说你不会复盘，好的，没救了，回去等通知吧。

总结

面试的时候对于这类开放性题目，其实并不是想象中的那么好回答，处处都是暗流涌动。

所以一定要在面试前做好这类题目的准备，临场发挥肯定是效果很一般的。

就拿我个人作为面试官的经历来说，特别是三到五年工作经验的朋友容易遇到这个问题。

校招生我肯定是不问这个问题的。三年以下的经验还不够丰富，回答起来也很难有什么满意的答案，所以我也不问。问这个还不如多问几个技术问题，考察他的技术是否扎实。

还有，前面说的两个方向，都得准备一下。

如果是前两轮面试问题了，可以往技术的方法回答，因为这个时候一般都是在一线编码的程序员充当技术面试官，他更愿意在技术方面和你切磋。

如果是后几轮面试，可以往主人翁意识的方向去回答，因为到后面的面试大多都是部门负责人一类的管理人员，已经很少在一线编码了，他们更愿意看到你除了技术之外的软实力。

本文参与了 SegmentFault 思否征文「如何“反杀”面试官？」，欢迎正在阅读的你也加入。