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

Posted 2023-03-31 清朝程序猿

你好呀，我是老猿。

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

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

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

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

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

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

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

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

考的是什么

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

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

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

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

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

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

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

说一下你最熟悉的项目。

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

不是的。

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

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

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

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

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

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

再说这个问题：

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

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

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

怎么能答的闪亮一点呢？

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

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

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

技术的深度

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

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

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

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

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

面试官是察觉不出来的。

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

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

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

这个案例从最开始 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 的快乐的程序员，每天等着领导分配任务，然后领任务写代码。

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

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

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

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

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

怎么办？

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

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

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

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

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

你就不能假设吗？

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

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

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

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

这玩意考的又是什么？

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

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

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

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

总结

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

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

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

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

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

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

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

最后说一句

好了，看到了这里了，转发、在看、点赞随便安排一个吧，要是你都安排上我也不介意。写文章很累的，需要一点正反馈。

给各位读者朋友们磕一个了：

面试题: 你在工作/学习过程中遇到过什么深刻问题吗？怎么克服？

最近面试高频问题，回答的一脸懵逼

因为面试官，基本都是先问项目中相关知识点以及延申问题，然后询问擅长的技术栈并深挖，最后来一个问题: 你遇到的最深刻问题是什么？怎么解决？

卧槽, 前面两个部分已经将项目中问题，及知识点说完了，现在又问这个是啥意思？突然一下不知道说什么了。怎么感觉没有遇到啥问题？

离线： 数据倾斜
实时： 程序稳定性及数据一致性，数据恢复
数据治理：

到底怎么回答才合适？

被问到这样的问题时，不妨先站住面试官的角度换位思考。
面试官是想了解你是怎么发现问题？怎么解决问题？恐怕不仅仅这么简单的的，这是一个考察你综合能力的题。

面试官想考察的内容有几个方面：

• 你的沟通能力，表达能力
• 技术能力（业务难题，技术难题）
• 领导能力 （团队资源协调，总结，分享，成长）

这是一个送分题，基本逢面试必问，面试前一定要准备好，能体现你技术能力、沟通能力、领导能力的任何方面都可以融汇进去，难题不仅仅指程序出现的 bug，也包括代码的设计、优化、重构，哪怕你没遇到过难题也要虚拟难题，表现你在不同方面的特长；

在设计的时候为什么没有多考虑一些，从架构或者业务层面避免解决不了的问题发生；要是bug为什么开发的时候遗漏了测试的时候没有发现；

• 确定存在难点，那么是技术上的问题，还是跨部门跨团队沟通协调的问题亦或其他各个方面的问题，这时候就是重点了，你解决的任何问题都可能是难题，在面试的时候把握些尽量往自己驾轻就熟的点上靠，详述问题如何解决的，到这里是不是够了；

• 问题有方案解决了，那么后续对于难点有没有复盘，有没有优化方案，有没有在团队做分享；

• 要回答这类的问题，重在平时的积累和反思；不管是自己遇到的还是团队中其他同事遇到的问题，只要是自己不会的，都要留心；好记性不如烂笔头，一定要笔记，等积累的多了，就要进行整理，标记出一些经典的问题；

• 最后的最后，你的总结你的思路有没有形成套路，当下一次遇到问题的时，是否有自己的解决问题的思路；

1、发现问题
某日通过azkaban调度监控，邮件告知某个任务运行时间超过正常运行时间30%，仍然卡死，通过spark history server web ui 界面，发现卡死在某个task, 查看这个task的数据量是其他完成的task 的 两个数量级
2、猜测 是 数据倾斜
通过查看源数据数据分布，的确有部分key数据量比较大

3、解决数据倾斜，数据倾斜，怎么办？

我们可以采用一些解决数据倾斜的办法，老刘大致讲一下关于数据倾斜的几个解决方案：

• 1、如果发现导致数据倾斜的key就几个，而且对计算本身的影响并不大的话，就可以采用过滤少数导致倾斜的key

• 2、两阶段聚合，将原本相同的key通过附加随机前缀的方式，变成多个不同的key，就可以让原本被一个task处理的数据分散到多个task上去做局部聚合，进而解决单个task处理数据量过多的问题。接着去除掉随机前缀，再次进行全局聚合，就可以得到最终的结果。但是这个方法只适用于聚合类的shuffle操作，不适合join类的shuffle操作。

• 3、对于join导致的数据倾斜，如果只是某几个key导致了倾斜，可以将少数几个key分拆成独立RDD，并附加随机前缀打散成n份去进行join，此时这几个key对应的数据就不会集中在少数几个task上，而是分散到多个task进行join了。适用于两个数据量比较大的表进行join。

• 4、如果在进行join操作时，RDD中有大量的key导致数据倾斜，那么进行分拆key也没什么意义，此时就只能使用这一种方案来解决问题了。将原先一样的key通过附加随机前缀变成不一样的key，然后就可以将这些处理后的“不同key”分散到多个task中去处理，而不是让一个task处理大量的相同key。