今天去一家互联网公司面后端，技术官一上来就让我白板写个“高并发分布式锁”，我脑子嗡的一下，只会最基础的Redis setnx那套，他追问“那网络抖动下幂等怎么保证”“RedLock你敢用吗”，我直接卡壳…后面又问我JVM调优参数，我平时就用过Xmx/Xms，结果被怼“太表面”。 我不是纯小白，平时业务做得还行，但这种高压追问一紧张就乱了，说话也打结。想问下：这种技术官明显想压节奏的时候，怎么破局？是该承认不会往回引导到做过的项目，还是要硬编思路？有没有比较实用的“脱身”话术或...
今天去一家互联网公司面后端，技术官一上来就让我白板写个“高并发分布式锁”，我脑子嗡的一下，只会最基础的Redis setnx那套，他追问“那网络抖动下幂等怎么保证”“RedLock你敢用吗”，我直接卡壳…后面又问我JVM调优参数，我平时就用过Xmx/Xms，结果被怼“太表面”。
我不是纯小白，平时业务做得还行，但这种高压追问一紧张就乱了，说话也打结。想问下：这种技术官明显想压节奏的时候，怎么破局？是该承认不会往回引导到做过的项目，还是要硬编思路？有没有比较实用的“脱身”话术或者答题框架，能别被一路带着打。下周还有二面，在线等，真有点怂了…先谢。
你遇到的不是技术问题，是面试节奏控制问题——技术官在用「连环追问」测你的抗压反应和知识边界，这时候硬编答案反而死得更快。
我自己之前也被这么压过，后来发现关键在于：主动承认边界，然后立刻把球踢回自己擅长的场。比如你被问RedLock不会，正确姿势是「RedLock我没在生产环境用过，但我们项目里用Redis分布式锁时遇到过网络抖动导致的重复扣款，当时是通过业务层唯一键+数据库事务兜底解决的，这个方案在我们日均XX万订单的场景下跑了半年没出过问题」——你看，承认不会，但马上转到真实业务场景，把主动权拿回来。
第一步是立刻承认，但要带上限定词。别说「不会」，要说「这块我实际项目里没深入用过」或「我了解基本原理但没调优经验」。这能让面试官知道你有自知之明，不是那种不懂装懂的人。
第二步是快速关联到你做过的东西。公式是：「但我在XX项目里遇到过类似问题，当时的解决方案是……」。比如他问JVM调优参数，你可以说「G1的具体参数我确实没系统调过，但我们线上服务出现过频繁FullGC导致接口超时，当时通过jstat监控发现是老年代增长过快，后来调整了对象晋升阈值和堆内存比例解决的，具体数值我可以翻当时的工单记录」——注意，你承认了不会高级调优，但展示了排查问题的完整思路。
第三步是反问确认需求。如果对方继续追问你不熟的领域，可以礼貌地问「您这边是因为业务场景需要用到RedLock这类方案吗？我想了解下具体的并发量级和一致性要求，这样我能更准确地判断自己的经验是否匹配」。这招有两个好处：一是把压力转化成需求讨论，二是暗示对方「我关心的是能不能解决实际问题，而不是背八股文」。
当被问到完全陌生的技术点：
「这个技术我目前还没实际用过，但我知道它主要解决XX问题。如果后续工作需要，我会先看官方文档和社区最佳实践，然后在测试环境验证后再上生产——之前学习XX技术时我就是这么做的。」
当对方质疑你的方案「太基础」：
「确实我们现在的方案相对传统，但在我们业务体量下（日活XX/并发XX）是够用的。我理解更复杂的方案能覆盖更极端的场景，想请教下贵司这边的并发量级大概在什么水平？这样我能评估下是否需要提前补这块知识。」
当脑子卡壳说不出话：
「不好意思让我理一下思路（停顿2-3秒）……这个问题我需要从XX和XX两个角度考虑」——主动要停顿时间比结结巴巴强一百倍，面试官能接受你思考，但受不了你慌乱。
别去狂背面经八股文，来不及也记不住。重点做三件事：
梳理简历里每个项目的STAR（情境-任务-行动-结果）。把「做了什么」改写成「遇到XX问题-尝试了XX方案-最终效果是XX」。比如你简历上写「负责订单系统开发」，要能随时展开成「高峰期出现过订单重复提交，排查后发现是前端重复请求+后端没做幂等，我加了Redis分布式锁+数据库唯一索引双保险，上线后重复率从0.3%降到0」。
准备2-3个「失败案例」。面试官问「遇到过最大的技术难题」时，别只说成功的，说一个「当时方案没选好走了弯路，后来怎么调整的」更真实。比如「一开始用了XX方案结果发现XX问题，后来改成XX虽然代码量增加了但稳定性提升了」。
提前准备3个反问问题，而且要和你的短板相关。比如「如果入职后需要快速补充分布式相关知识，团队这边有没有内部分享或者导师机制」——这既表明你知道自己的不足，又展示了学习意愿。
不是所有问题都能承认不会。岗位JD里明确要求的技能点，以及你简历上写的技术栈，这些被问到必须答上来。如果JD写了「熟悉分布式锁」你投了简历，那Redis锁的基本实现、过期时间、可重入这些就是必答题，答不上就是能力不匹配。
但如果对方问的是JD没提、你简历也没写的（比如JD只要求「熟悉Redis」，结果问你RedLock源码），这种就可以大方承认「没深入研究过」，然后转到你用Redis解决过的实际问题。
还有一类问题是「开放性架构题」，比如「设计一个秒杀系统」。这种千万别说不会，要按「限流-缓存-异步-降级」这种通用思路往下说，哪怕细节不完美也比卡壳强。可以边说边问「这个场景下XX是不是核心瓶颈」，把单向提问变成双向讨论。
最后说一句：如果整场面试下来你发现对方就是想招个「什么都会的全栈+架构师+运维」，而给的只是普通开发薪资，那被压其实是好事——说明这公司预期和投入不匹配，早点暴露省得入职后天天救火。二面时注意观察技术官的反馈方式，如果他愿意在你承认不会后给提示或者讨论方案，说明是正常考察；如果只是冷笑着继续追问更偏的知识点，那这种团队氛围你也要考虑下是否适合自己。
之前面过一家做支付的，二面技术官上来就问“你们项目里分布式事务怎么做的”，我当时也是脑子一空，老实说我们那个业务量根本没到那一步，就讲了讲基于本地消息表的方案，还说了下哪些场景我们没用上、为啥没上。他反而顺着这个话题多问了几句，最后聊到一致性权衡的时候他明显满意了。后来我总结了一下，这种高压追问就是想看你在压力下会不会乱编，你越硬撑越完蛋。直接承认“这块我确实了解不深，我讲下我做过的类似场景”就行，把话题往你准备好的项目上带，前提是你得真做过，临时编的经不起追三句。还有个小心得，答的时候语速放慢点，给自己争取思考时间，你一快就显得慌。仅供参考。
我上次面一家做支付的公司，技术官也死磕分布式锁，我直接说setnx这套我只知道原理，实际项目里压根没用过Redis锁，而是用的数据库行锁加版本号。那哥们儿反而追问我怎么防重试的，我把当时那个订单系统的bug讲了十分钟，后来就聊项目了。
我去年面那家本地互联网公司也遇过这茬，技术官一上来就死磕RedLock和幂等，我直接说“我项目里用的是zk的临时节点加watch，网络抖动那块没踩过坑就没深究”，他愣了下就转问我怎么处理业务幂等了。后来我才知道他其实想听实际场景，不是背公式。那次我硬着头皮把话题扯回自己做过的那块，第二轮就过了。
