快手 C++ 一面

✋️客户端开发一面- 自我介绍- 介绍agent项目的工作流，有没有用到节点- 这个产品在手机上的业务编排是怎么样的（没有设计app，仅pc端，汗-_-||）- MCP是什么- 项目里的skill.md有哪些，是怎么设计的- 混合检索是怎么做的，和rag检索的区别- 怎么减少上下文过长的问题- 讲一下多线程，多线程复用- 连接池/线程池怎么做的- 怎么维护线程安全，知道的锁有哪些- tcp和udp区别- 怎么优化tcp面向连接带来的问题- 手撕：合并两个有序链表- 问是否在校- 反问✋️客户端开发二面- 自我介绍- 用的什么模型，有什么好处- 场景怎么想的，有落地吗- 整体的工作流是什么，详细讲讲，怎么从0到1搭建的- 上下文幻觉有遇到吗，怎么解决- 上下文压缩怎么做的，是对全部内容压缩吗- 大模型怎么匹配到skill的- skill怎么写，有遇到没有匹配上的问题吗，那怎么写好/检索更精准- 平常从哪里了解大模型相关讯息- 上下文包含哪些内容- 长期记忆有没有检索到的情况吗，怎么解决？面试官解释了claude是怎么解决的- 意识识别/查询优化怎么做的- 知识库混合检索怎么做的- 课题组方向是什么，具体讲讲，自己的论文方向是什么- 对于今后的职业规划，问了下简历上的求职意向- 手撕：k个链表合并，5分钟用大模型完成，解释提示词怎么写的，还能怎么优化- 反问总结：主ai、一点多线程/网络问题都不难，主要是偏ai应用的，所以问ai方面的比较多，对于使用ai的能力很看重。c++八股拷打较少。

1. 自我介绍2. TCP 三次握手过程是什么，为什么一定要三次答案：TCP 三次握手主要是为了建立可靠连接，并同步双方的初始序列号。第一次，客户端发送 SYN 给服务端，表示自己想建立连接，并带上客户端初始序列号。第二次，服务端收到后回复 SYN + ACK，既确认客户端的 SYN，也发送自己的初始序列号。第三次，客户端再回复 ACK，确认服务端的 SYN，双方进入 established 状态。为什么不是两次，主要是为了确认双方的收发能力都正常。如果只有两次，服务端只能确认客户端能发、自己能收，但不能确认客户端能收、自己能发。另外三次握手也能避免历史重复连接请求导致服务端误建立连接。3. ...

攒人品中 1.项目拷打2.实习拷打3.用什么AI产品解决问题?用Claude学东西+各种拷打自己..用codex和claude code做pj4.场景题,给你一个场景如何节省token开销来解决这个问题5.场景题,还是围绕开销,具体忘了6.你项目的数据集多大7.能实习多久

攒人品ing~（一天三面我燃尽了）个人背景介绍一、 项目深挖：高并发博客系统架构面试官提问：你的并发控制和API限流是怎么做的？面试官追问：点赞的接口限流具体怎么实现的？面试官追问：数据最终怎么落库？MQ消息丢了怎么办？二、 场景题：使用Redis实现QPS/QPM/QPD限流面试官提问：如果要用Redis限制一个接口在滚动窗口下的QPS、QPM、QPD，怎么做？第一版思路：将时间单位拼接到Redis Key中。面试官指出：这会导致Key数量爆炸式增长。第二版思路：使用Hash结构，记录用户在特定时间窗口内的访问次数。面试官指出：这种方式只能记录自然时间（如自然天、自然秒），无法满足滑动窗口的需求。第三版思路：使用ZSet实现滑动窗口，Score设为时间戳，Value设为唯一标识。每次请求进来先移除时间窗口之前的数据，再使用 `ZCARD` 统计当前元素个数来判断是否限流。面试官指出：在QPD（每天调用量）极大且高频的场景下，ZSet会导致元素过多，产生大Key问题。第四版思路（最终被认可）：针对精度要求没那么高的QPM/QPD，采用“分桶计数”思想。将一天24小时分为1440个分钟桶，使用String存计数值。每次判断时只需将最近时间段内的桶数据相加即可，旧桶设置自动过期销毁。表示该方案可行。三、 项目深挖：缓存三大问题解决方案面试官提问：你在项目中提到的“布隆过滤器 + 互斥锁 + 逻辑过期”是怎么协同工作的？四、 手撕算法题目：LeetCode 124. 二叉树中的最大路径和。五、 反问环节问：入职后实习生的主要工作内容是什么？问：团队内部对于AI写代码的认可度如何？问：对我今天面试表现的评价和建议？