自我介绍 我看你这跟计算机专业不是很相关啊，为什么想从事这个native渲染方向呢?(我晕啊，是你们业务人员打电话捞我起来的啊，光是大学专业问题就讨论了好一段时间，大学学的专业有那么重要吗)共享屏幕看看项目:为什么不能用专门的3d模型直接内部渲染生成，为什么要经过代码实现?(说了一堆设备像素比还有底层渲染逻辑，画质拉伸会导致像素强制变大模糊，面试官明显不感兴趣，然后终止话题)然后就是很偏门的东西:说说cpu底层二进制的按位计算实现原理(啊这让我从哪里说起啊...开始瞎掰，在底层就是二极管电路)为什么tcp不能失去第三次握手?(会导致服务器数据传输不开始，继续追问，为什么呢？(我晕啊让我从哪里说起))我们部门可没有这种跟你一样做3d的哦(截止这里才过去二十几分钟，我知道自己要挂了hhhh)那来写两道题吧(hhhh简历上的东西一个都没问，真的有种满腹经纶无人赏识的感觉，都是问些犄角旮旯特别偏门偏离部门技术栈的东西)然后面试官美美闭麦隐身，甚至跟别人聊天去了写第二道算法题的时候其实已经崩溃了,手开始抖，说话都带着哭腔，没写出来，感觉就算写出来了面试官也不想要我，明明前面的面试官都说我跟岗位很匹配。。。反问环节已经要哭了，所以没问多少就匆匆下播(面试完就开始哭，蜀黍心理素质太差了)咱就说如果真招到合适的候选人了能不能直接取消面试啊😭😭直接拒绝我比什么都爽快大厂梦，何时了。。。落后大家这么多了希望被字节善待吧

一面：自我介绍拷打项目项目1 MongoDB相对于MySQL的优势 RAG流程 如果提问的与知识库不相关怎么办 市面上成熟的聊天记录的管理方案项目2 session共享的问题 优惠券秒杀的流程 Lua脚本里干了什么八股 redis中zset的底层 zset插入和查询的时间复杂度 redis为什么快 redis io多路复用如何实现 redis的性能瓶颈在哪里：面试官让在内存、cpu、网络io中选 MySQL中的索引实现 B+树比B树好在哪里？为什么B+树更矮 事务隔离级别 mysql的默认级别 可重复读是如何实现的：回答了读视图，面试官纠正说了读视图的专业名词 HTTPS和HTTP的区别 加密...

美团二战一面(核心本地商业-业务研发平台-美团app业务)承接了3000多的 QPS,服务端的机器有几台？这个接口(订单接口)的性能是?(响应多少毫秒) 返回哪些信息？订单列表只能看到一个商品，还是说是有个商品列表呢？分页的 每一页返回多少商品数据啊？Redis 里面主要存哪些东西本地缓存里面主要存在哪些东西 为什么固定的放在内存里面Redis 是多久更新一次吗？假设我在服务端，变更了一个库存，然后变更在那个接口发现超时了，就是你变更的时候发现返回了一个报错，但是后台其实是已经变更成功了，这种情况下怎么处理？(换了种说法 结合场景)用户下单，然后下单我调接口的时候，接下单接口超时了。但是这只是因为网络问题超时了，但是它内部其实扣减库存啊什么的都已经成功了。这种情况下怎么处理？这个 token(防重) 是在什么过程中去生成的?乐观锁解决超卖怎么解决的？为什么要用乐观锁呢？你的个性化推荐,高峰期不是会有很多很多用户会下单失败吗？JWT 的令牌认证具体是怎么做的？JWT 的三次校验（三型校验）ai封装那些订单查询、配送咨询这些问题，这个具体是怎么去做的？你是直接用用户提问的，然后直接调用大模型去询问的？你怎么知道配送状态的？因为你的那些配送不是都是兼职吗？用户下完单之后，你怎么给订单分配给兼职呢？智能客服是实现 7×24 小时智能回复。需要做到 7×24 小时吗？你还实现了那个性化菜品推荐，这具体是怎么去做的？你的那个订单数据表跟用户表，这两张表是怎么去设计的？问一个 AI 的吧，你做了一个客服问答，对吧？但是你是去调用自己封装了几个tool，然后让大模型去调用嘛，那我也想做一个智能客服，但是我的智能客服可能是基于一些，比如说我是医院，医院需要做一个智能客服，然后我会把一些那个患者常问的一些医疗上面的一些事情作为一个知识库，然后作为一个回答。那我应该怎么设计这个客户问答系统？把它给放到知识库里面，比如说我怎么切片？然后你刚讲到那个用户提问，敏感词过滤，这些我怎么去给它分词？怎么去做增强等等。按照你的那个分片，假设我按照你的那个分片形式去分片，然后我发现我检索出来的内容好像相关性并不是很强，我怎么去解决？检索相关性的算法与方案那个 Spring 框架里面有用到哪些设计模式啊？Autowired 跟 Resource 有什么区别？synchronized 跟 lock 有什么区别啊？Synchronized 底层。索引分哪几个索引？联合索引怎么创建？(具体到sql写法)不在创建表的时候创建这个索引，表已经创建完了，然后我要再创建这个索引,怎么做?like会不会走索引？MySQL 里边有哪几个日志啊？

有一个问题：Multi-Agent 架构到底适合什么场景？ 很多人第一反应是：“任务复杂的时候就用多 Agent。” 然后面试官就会继续追问：什么叫复杂？复杂体现在哪？引入多 Agent 的代价是什么？有没有明确不该用的场景？ 如果这些问题答不清楚，这道题基本就丢分了。 真正成熟的回答，不是“复杂任务适合拆分”，而是要给出一套可操作的判断框架。结合 Claude Code、Codex 类产品的实战经验，可以把这个问题归结为一句话： 默认先用单 Agent，只有在单 Agent 已经暴露出明显瓶颈时，才引入 Multi-Agent。 好像也是很扯。 为什么不能默认上 Multi-Agent？ 很...