京东后端AI研发一面分享

继续来分享下最近的面经~1. 实习拷打2. 你做的RAG知识库，具体业务场景是什么？整体是怎么搭建起来的？3. 项目一开始存在大事务问题，这个问题具体怎么优化的？4. 这个知识库支持什么内容形态？只有图文吗？图片是怎么处理的？5. 知识库面向的业务是什么？图文混合内容是怎么存储和还原的？6. 知识库更新怎么做？怎么保证内容实时保鲜？7. 这个项目里你遇到过哪些挑战和技术卡点？8. 向量库选型时考虑过哪些方案？为什么最终选择Milvus？抛开公司基建，会从哪些维度选型？9. 简历里提到吞吐、检索性能有提升，提升具体来自哪里？你做了哪些优化动作？10. 当前链路访问量、文档量级、线上运行情况如何？灰度切量到什么程度了？11. 线上有没有完整监控？链路出问题如何及时发现告警？12. 灰度切流过程中实际暴露过哪些线上问题？怎么解决的？13. 你最近参与的个人用户向、AI Coding 相关产品，目前做到什么阶段？你负责哪部分？14. 在这些项目中，你个人最大的技术收获是什么？15. 你理解Milvus底层原理，这些原理在实际落地中怎么指导你的技术决策？16. ES深翻页问题有没有遇到过？背后原理和瓶颈怎么理解？17. 有没有做过高并发场景？大促、秒杀这类高并发场景一般怎么设计处理？18. 平时开发会用设计模式吗？在实际项目里是怎么落地使用的？

1. 自我介绍2. RocketMQ 里顺序消息、普通消息、事务消息分别适合什么场景，为什么不能混着用普通消息适合最终一致、无严格顺序约束的场景，比如日志分发、画像更新、通知投递。顺序消息适合同一业务键必须按时间线推进状态的链路，比如同一工单、同一订单、同一会话的状态演进，但顺序消息的吞吐和容错设计会受到队列粒度限制。事务消息适合本地事务与异步投递之间要建立“发送承诺”的场景，比如主库先落事实，再由 MQ 推动旁路索引或下游补偿。三者不能混着用，是因为它们解决的问题不同，消费模型、失败恢复方式和成本模型也完全不同。3. 如果 RocketMQ 出现消息积压，你会怎样定位，不要只说“扩容消费者”...

4.3 一面先拷打了半小时的项目之后问了写普通的八股，左值右值，虚拟内存，TCP等手撕三选一，俩hard一mid，鼠鼠果断选择了最简单的LRU4.7约二面，4.8开始二面开局唠嗑问项目问了下继承，面向对象结束，无手撕4.8晚二面过，4.9三面开局唠嗑问项目经历，困难点，出发点是什么无八股，写了半个小时的题目。。。折磨4.14hr面唠嗑局，与其他人怎么协作的等。之后秒云证4.17收到书面offer，本轮面试结束，总体来说越来越脱离八股了。

我问了一圈正在找工作的朋友，答案比我想象的真实。有人说在刷题，但打开leetcode又关掉，关掉又打开，一天下来做了两道easy还错了一道。有人说在投简历，但投完就盯着手机等回音，等到睡着，醒来发现石沉大海。还有人说在"调整状态"，调着调着一周过去了，什么都没动。我自己也经历过这段时间。说实话那种感觉很割裂——明明很焦虑，但就是动不了。不是懒，是那种悬在空中、落不了地的感觉让人很耗神。投了简历没回音，不知道是简历问题还是岗位问题，什么都不确定，什么都使不上劲。后来我给自己定了个笨办法：不管状态好不好，每天只做一件具体的事。改一个简历模块、学一个知识点、做一道算法题。不要求多...