问一个问题，你们在工作中都解决过什么比较困难的问题呢

[travelcc]

java 面试中，经常碰到这样的问题，但是业务基本都是增删改查，也没有什么很复杂的问题，用过多线程，项目部署也不难，jvm 调优这种更难碰到，所以，大佬们都是怎么回答的呢？ 求参考！

[Foxalone]

通过谈判, 基本都是老板的业务恶心人比较多. 所以能沟通不做的尽量去沟通...

[wanniwa]

比如我们的公司难点就是税表算税的优化。一步步拆解优化的点，我会各种细讲，现象是怎么，怎么分析的这个问题，怎么找到优化点，然后做了什么措施。
分析问题本身就是在探索一个个难点。只是最后落实到实现上，可能优化的代码没几行，问题找到了又觉得不难了。但是这个过程就是克服难点的过程。
俗话说难这不会，会者不难，所以不要看小看你日常解决的问题。
还有就是项目重构什么的，怎么做项目的规划，怎么不影响原有业务基础上改造……
我觉得能说的一大堆。。。。。。

[exmario]

纯为面试的话，网上翻个案例研究一下美化成自己的就好

[ZhuWenJian]

我是客户端开发，说一个上周解决的：
背景：进入漫画阅读页面要进行 180 张图片的加载。（当前章、上一章、下一章）
如果用户这时候进行章节切换，就要等前面的图片加载完，因此极端情况要等待很长时间（起码 10 秒以上）。

优化：
因此设计了一套机制，使得进入页面只需要加载 6 张图片，实现秒切换的效果。

[beryl]

面试官视角：

我一般也会必问这个问题，但是预期的并不是说这个问题多难，而且期望通过这个观察候选人：
1. 是否对业务对技术了解和沉淀思考
2. 对自己认为难的问题，如何解决的、思路是什么
3. 回答的角度是偏向技术还是业务，还是两者都有
4. 最后才是问题难的具体是多复杂

[c3de3f21]

把 gitlab 更崩了。。。

[nice2cu]

主要说下自己遇到 bug 的定位排查过程吧，

[seaswalker]

JDK 8 升级到 17 因为 jdk 本身变化导致；另一种是可能发生概率千分之一的多线程 bug 。这两种很难查。

[travelcc]

@beryl okok 明白了

[travelcc]

@c3de3f21 这有点厉害

[travelcc]

@wanniwa okok 明白了 可以结合业务 具体拆解、分析

[tppttw]

感觉更侧重考察如何解决问题，而不是考察问题有多困难

[skyrim61]

@c3de3f21 哈哈哈

[Avafly]

优化 GEMM.
后来直接上 openblas 了...

[wuxi889]

问这个问题的时候，面试官是想知道两个点：
1. 你的解决问题的能力；
2. 你的是否是一个“合格”的开发人员（面对问题时有自己的思考）；

[sampeng]

我也必问这个问题，你自己解决的和随便编的一耳朵就能听出来。这种开发性的问题基本没标准答案。
但还是会去抓几个点。
1.你会不会主动的去发现问题
2.你看待问题的层次。
3.语言表达逻辑性。因为解决问题过程一定是有自己思路在里面的。
4.利用多少资源来解决问题，可以是自己的也可以是别人的

[Gress]

工作是改开源项目代码，二次开发，无数的坑，简直不要太恶心

[levelworm]

@Gress 这要是底层那还蛮有趣的。

[cooltechbs]

@levelworm 我第一份工作就是开源二次开发，理论上应该有趣，但实际上老板的期待远远超过我和我们团队当时能做的。到最后成了上班如上坟

[cooltechbs]

@beryl 我想给自己立一个技术导向的人设，然而之前做的复杂项目恰恰都是业务复杂... 所以每次被问到这类问题就很不爽

[kjstart]

尽量之前想, 你面试呢? 进来一看还真是....
网上别人吹 nb 的你挑几个研究明白了用就得了.
如果你想问找多 nb 的合适, 那就是越 nb 越好.

[coldear]

真正到了写代码的时候，已经没有什么难度了，
难点在分析需求和设计，
之前有个需求，流程图有 100 多个可能的分支，怎么抽象出可重用可扩展的类来实现就比较有难度。

[kenwa]

能解决的都不难

[guiys]

没意义，省了几百 w 的成本，奖金 200

[Cola98]

中间件连接问题: 之前 redis 会经常出现一下可以连接，一下不可以，集群本身没有问题，换到业务 Pod 里面用 cli 工具也没有问题，后来排查是 jredis 问题。
主从备份问题: 这是最近的，也不算很困难。就是在细节方面考量的比较多，比如代理，主从之间的选举。

[NoKey]

大部分搞应用开发，不涉及架构，jvm 等基础设施的，好像也没啥太大的问题
大部分问题，网上都能搜到，剩下一部分找不到答案，一群组织里面的大佬都不好解决的问题，大概率有办法绕过去

[murmur]

js 我记得我调过一个 ios safari 的 bug ，某个事件的参数原本是数值，结果某些时候会出现 1e-23 这样的科学计数法，导致解析出错程序卡死

[darkengine]

你们的项目一直没有遇到离奇的 bug ？

没有就讲个新技术的调研咯

[S4msara]

这个问题我也必问，更多是想考察应试者面对问题时的心态和解题思路是否清晰，期待的回答是能把场景描述清楚，业务现状和局限是怎样的，观察到了哪些现象，做了哪些方面的尝试和考量，最终以什么样的方式解决了问题。哪怕是借助外部力量解决也好，因为重点不是解决问题，而是解决问题的过程。至于应试者讲出来的东西，是不是真的困难，不要代入自己去评估，没有意义，最重要的是，困难不可能永远都是困难。
有时候应试者的回答更偏向业务，对技术层面的讲的比较少，我还会补一个问题：最近有关注哪些技术？这个问题就是来考察应试者对技术是否有一定的热情，哪怕是被迫的热情都好，回答可以无限宽泛，随便对方讲。
（有感而发，回复会比较乱）

[xuanbg]

我遇到的最困难的问题就是：没有蛋孵不出鸡，孵不出鸡也就下不出蛋。。。怎么解决？解决个蛋蛋！这哪是我的问题啊，这是老板的问题好不好。

所以，我就没遇到什么困难的问题。

[lyxxxh2]

我也被问过
我一时也想不起自己遇到那些难题。
a: 没有啊,都挺简单。

[travelcc]

@Foxalone 哈哈哈 有道理

[travelcc]

懂了 解决方案也算 不一定非得是代码里面特别复杂的东西

[travelcc]

@sampeng 懂了 我平时解决问题还是比较多的 主要是思维陷入了一个怪圈 总以为必须是代码层面很高深的东西 才能算作难，其实有时候需求问题的解决，bug 的修复也算

[travelcc]

@coldear 对对对 感觉难得就是设计的过程

[dododada]

IM 系统丢消息和消息数据放大的问题。放大的问题相对好解决，丢消息真的是要老命了。

[travelcc]

@S4msara 嗯嗯 明白了 感谢大佬详解

[travelcc]

@lyxxxh2 对啊 平时工作中还是得记录和积累啊 不然解决过的难题 后续就忘了

[jiaqily]

可以来我司来面试一下。。