这是一个创建于 34 天前的主题，其中的信息可能已经有所发展或是发生改变。
java 面试中，经常碰到这样的问题，但是业务基本都是增删改查，也没有什么很复杂的问题，用过多线程，项目部署也不难，jvm 调优这种更难碰到，所以，大佬们都是怎么回答的呢？ 求参考！
39 条回复 • 2024-11-05 20:43:33 +08:00
 |
1
Foxalone 34 天前  2
通过谈判, 基本都是老板的业务恶心人比较多. 所以能沟通不做的尽量去沟通...
|
 |
2
wanniwa 34 天前 1
比如我们的公司难点就是税表算税的优化。一步步拆解优化的点，我会各种细讲，现象是怎么，怎么分析的这个问题，怎么找到优化点，然后做了什么措施。
分析问题本身就是在探索一个个难点。只是最后落实到实现上，可能优化的代码没几行，问题找到了又觉得不难了。但是这个过程就是克服难点的过程。 俗话说难这不会，会者不难，所以不要看小看你日常解决的问题。 还有就是项目重构什么的，怎么做项目的规划，怎么不影响原有业务基础上改造…… 我觉得能说的一大堆。。。。。。 |
 |
3
exmario 34 天前
纯为面试的话，网上翻个案例研究一下美化成自己的就好
|
 |
4
ZhuWenJian 34 天前
我是客户端开发，说一个上周解决的：
背景：进入漫画阅读页面要进行 180 张图片的加载。（当前章、上一章、下一章） 如果用户这时候进行章节切换，就要等前面的图片加载完，因此极端情况要等待很长时间（起码 10 秒以上）。 优化： 因此设计了一套机制，使得进入页面只需要加载 6 张图片，实现秒切换的效果。 |
 |
5
beryl 34 天前 3
面试官视角：
我一般也会必问这个问题，但是预期的并不是说这个问题多难，而且期望通过这个观察候选人： 1. 是否对业务对技术了解和沉淀思考 2. 对自己认为难的问题，如何解决的、思路是什么 3. 回答的角度是偏向技术还是业务，还是两者都有 4. 最后才是问题难的具体是多复杂 |
 |
6
c3de3f21 34 天前
把 gitlab 更崩了。。。
|
 |
7
nice2cu 34 天前 1
主要说下自己遇到 bug 的定位排查过程吧，
|
 |
8
seaswalker 34 天前 via Android
JDK 8 升级到 17 因为 jdk 本身变化导致；另一种是可能发生概率千分之一的多线程 bug 。这两种很难查。
|
 |
12
tppttw 34 天前
感觉更侧重考察如何解决问题，而不是考察问题有多困难
|
 |
14
Avafly 34 天前
优化 GEMM.
后来直接上 openblas 了... |
 |
15
wuxi889 34 天前
问这个问题的时候，面试官是想知道两个点：
1. 你的解决问题的能力； 2. 你的是否是一个“合格”的开发人员（面对问题时有自己的思考）； |
 |
16
sampeng 34 天前 1
我也必问这个问题，你自己解决的和随便编的一耳朵就能听出来。这种开发性的问题基本没标准答案。
但还是会去抓几个点。 1.你会不会主动的去发现问题 2.你看待问题的层次。 3.语言表达逻辑性。因为解决问题过程一定是有自己思路在里面的。 4.利用多少资源来解决问题，可以是自己的也可以是别人的 |
 |
17
Gress 34 天前
工作是改开源项目代码，二次开发，无数的坑，简直不要太恶心
|
 |
19
cooltechbs 33 天前 via Android
@levelworm 我第一份工作就是开源二次开发，理论上应该有趣，但实际上老板的期待远远超过我和我们团队当时能做的。到最后成了上班如上坟
|
|
20
cooltechbs 33 天前 via Android
@beryl 我想给自己立一个技术导向的人设，然而之前做的复杂项目恰恰都是业务复杂... 所以每次被问到这类问题就很不爽
|
 |
21
kjstart 33 天前
尽量之前想, 你面试呢? 进来一看还真是....
网上别人吹 nb 的你挑几个研究明白了用就得了. 如果你想问找多 nb 的合适, 那就是越 nb 越好. |
 |
22
coldear 33 天前
真正到了写代码的时候，已经没有什么难度了，
难点在分析需求和设计， 之前有个需求，流程图有 100 多个可能的分支，怎么抽象出可重用可扩展的类来实现就比较有难度。 |
 |
23
kenwa 33 天前 1
能解决的都不难
|
 |
24
guiys 33 天前 via iPhone
没意义，省了几百 w 的成本，奖金 200
|
 |
25
Cola98 33 天前
中间件连接问题: 之前 redis 会经常出现一下可以连接，一下不可以，集群本身没有问题，换到业务 Pod 里面用 cli 工具也没有问题，后来排查是 jredis 问题。
主从备份问题: 这是最近的，也不算很困难。就是在细节方面考量的比较多，比如代理，主从之间的选举。 |
 |
26
NoKey 33 天前
大部分搞应用开发，不涉及架构，jvm 等基础设施的，好像也没啥太大的问题
大部分问题，网上都能搜到，剩下一部分找不到答案，一群组织里面的大佬都不好解决的问题，大概率有办法绕过去 |
 |
27
murmur 33 天前
js 我记得我调过一个 ios safari 的 bug ，某个事件的参数原本是数值，结果某些时候会出现 1e-23 这样的科学计数法，导致解析出错程序卡死
|
 |
28
darkengine 33 天前
你们的项目一直没有遇到离奇的 bug ？
没有就讲个新技术的调研咯 |
 |
29
S4msara 33 天前
这个问题我也必问，更多是想考察应试者面对问题时的心态和解题思路是否清晰，期待的回答是能把场景描述清楚，业务现状和局限是怎样的，观察到了哪些现象，做了哪些方面的尝试和考量，最终以什么样的方式解决了问题。哪怕是借助外部力量解决也好，因为重点不是解决问题，而是解决问题的过程。至于应试者讲出来的东西，是不是真的困难，不要代入自己去评估，没有意义，最重要的是，困难不可能永远都是困难。
有时候应试者的回答更偏向业务，对技术层面的讲的比较少，我还会补一个问题：最近有关注哪些技术？这个问题就是来考察应试者对技术是否有一定的热情，哪怕是被迫的热情都好，回答可以无限宽泛，随便对方讲。 （有感而发，回复会比较乱） |
 |
30
xuanbg 32 天前
我遇到的最困难的问题就是：没有蛋孵不出鸡，孵不出鸡也就下不出蛋。。。怎么解决？解决个蛋蛋！这哪是我的问题啊，这是老板的问题好不好。
所以，我就没遇到什么困难的问题。 |
 |
31
lyxxxh2 31 天前
我也被问过
我一时也想不起自己遇到那些难题。 a: 没有啊,都挺简单。 |
 |
33
travelcc OP 懂了 解决方案也算 不一定非得是代码里面特别复杂的东西
|
|
34
travelcc OP @sampeng 懂了 我平时解决问题还是比较多的 主要是思维陷入了一个怪圈 总以为必须是代码层面很高深的东西 才能算作难，其实有时候需求问题的解决，bug 的修复也算
|
 |
36
dododada 31 天前
IM 系统丢消息和消息数据放大的问题。放大的问题相对好解决，丢消息真的是要老命了。
|
 |
39
jiaqily 22 天前
可以来我司来面试一下。。
|
Select Language