哔哩哔哩--后端开发一面（实习）面经

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

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

继续来分享下最近的面经~1、讲一讲你现在公司做的这个agent是怎么样的？2、既然是科研类的agent，整个流程是怎么设计的？3、你有提到文献检索，我可以理解为deep research吗？具体讲一讲代码层面怎么实现的？4、主agent和子agent共用同一个上下文吗？5、讲一讲tool calling的具体实现6、知道渐进式披露吗？解释一下7、你觉得你使用LangGraph遇到最大的困难是什么？无手撕

攒人品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写代码的认可度如何？问：对我今天面试表现的评价和建议？