面试/笔试

CPU 飙高排查我一般分三步：第一：确认是用户态还是系统态高，用 top 看 us/sy/wa第二：定位具体进程，再定位线程第三：结合线程栈分析是死循环、锁竞争、GC 频繁还是线程过多1）us 高、sy 低、wa 低含义：纯用户态计算，无阻塞、无系统调用、无 IO典型原因死循环复杂计算 / 递归JSON / 序列化疯狂正则回溯爆炸GC 线程疯狂（VM Thread、GC task）栈特征：大量 RUNNABLE，一直占 CPU 不释放一句话：us 高 sy 低 = 业务代码死循环 / 计算密集 / GC 频繁，直接 jstack 找 RUNNABLE 栈。2）sy 高、us 低 / 一般含义：...

如果在面试中遇到不会的问题，我不会直接说“不会”然后结束，而是采取一种结构化的应对方式来体现自己的分析能力和工程思维：首先我会先复述问题，确认自己理解是否正确，同时尝试从已知知识出发进行拆解，比如这个问题属于哪个领域（并发、数据库、系统设计等），有没有相似的问题或模型可以类比；如果能想到部分思路，我会把自己的推理过程说出来，即使不能给出完整答案，也尽量展示“我是如何逼近答案的”，例如先给出一个基础方案，再分析它的不足和可能的优化方向；如果确实完全没有思路，我会坦诚说明这一点，但不会停在这里，而是会补充我会如何在实际工作中解决，比如查官方文档、阅读源码、定位关键模块、或者通过日志与实验验证问题，并且可以简单给出一个可能的学习路径；最后我通常会主动做一个收束，比如总结这个问题背后考察的核心能力（例如并发控制、系统设计权衡等），表明自己虽然当前没有完全掌握，但具备快速补齐的能力，这样可以把“不会”转化为“有潜力、有方法论”的信号。

入职第一周，我在任务系统里刷到了一条没人动过的 issue。 标注是这样的：[低优先级] 某业务链路在特定场景下偶发超时，待排查。创建时间是两个月前。没有负责人，没有截止日期，没有任何回复记录。 我问了旁边的师兄，他抬头看了一眼，说："那条老问题了，偶发的，流量不高的时候基本感知不到，先放着吧。" 我在心里记下了它。 那天晚上我把相关的几个模块代码翻了一遍，没找到什么明显的逻辑错误。但有一段处理逻辑让我觉得不太对劲——在高并发的情况下，如果上游请求的时序出现轻微错乱，这段代码的处理顺序可能会走到一个边缘分支，而那个分支的错误处理是不完整的。 我没有急着去问任何人。我把自己的...

上周开始陆续投了很多部门，但是简历一直被锁，上周被aidp部门锁，这周被推荐架构部门锁，这俩部门我印象都没有投过，但是今天刚解锁就又被锁住了，下周五才能解锁。这样既不解锁，也不约面，就一直耽误着，感觉自己要活活被拖死啊，路过的hr同学能不能大发慈悲帮帮忙沟通解锁一下，感激不尽了目前是被后端开发 推荐架构这个部门锁住了