携程线下面过了还会筛多少人啊😦

部门：base北京，金融服务平台-技术平台。海面kpi，避雷！

依旧只写记得的部分一面：1.自我介绍+介绍个人博客2.看我个人博客，让我讲讲我写的博客的东西（有关线程池源码的，参考性并不是很大）2.5.在讲博客内容时穿插多线程八股3.看我多线程这块好像挺好的，手撕奖励一道多线程打印，一个打印A，一个打印B（还好上次回去恶补了一下）4.问实习相关，主要是自己做了啥事情，整个系统大概啥样，回答思路是首先大致介绍系统作用，然后聚焦个人做的模块，再补充上下游把全链路讲清楚大概这么多，一共45-50min，出来等了5min告知通过准备第二轮二面：1.看我项目用了限流的东西问了一下我对限流算法有无了解，回答了令牌桶和时间窗口2.初现端倪，开始问我TCP有无限流概念的体现（主播简历一点408计网没写），回答流量控制和拥塞控制3.接2，给了一个例子，比如通过TCP连接下载数据的时候的场景，让我画TCP数据传输速率时间图（v-t图）。直接给我干懵逼了，他说你们应该学过吧，我说我完全没听过，他说没事，你学过的知识里应该有体现（体现在哪），于是开始画图。这题我主要的考虑是作为发送方来发数据的速率，因为流量控制和拥塞控制实际上都是控制发送方的窗口大小，其中拥塞控制是发送方根据网络拥堵程度控制自己的窗口大小。所以主播在这里考虑拥塞避免的一些算法（慢开始、拥塞避免、快重传、快恢复），通过窗口变化来推算传输速率的变化。所以首先画了一个拥塞窗口随时间变化的图，然后根据这个图画出最终他要的v-t图。他当时没说对不对，下来之后我用claude给我模拟了一下，思路基本没啥问题，最后的v-t图实际上跟窗口变化是基本差不多的。4.继续问计网，让我讲讲TCP三次握手和四次挥手，主播已经不记得那些状态具体叫啥了，索性说那我继续画图吧，然后就直接开画，画的中间穿插一些细节问题，比如第二次挥手跟第三次挥手之间可能是谁给谁传数据（服务端给客户端传）之类的细节。5.画完开始问一些我觉得自己擅长的，我说线程池，然后开始吟唱一些普通线程池八股6.追问你看过一些Web容器的源码比如tomcat吗？回答没看过，说没事那你觉得像这种Web服务的容器用传统线程池合适吗？回答思路是不太合适，我是从用户响应这块考虑的，假设用传统线程池，那么请求只来了一部分，就到达核心线程数，只有等任务队列满之后才会继续创临时线程来处理，这样如果请求多一点的话，请求的平均响应时间可能就会慢，我的想法就是优先创建线程，实在没线程可创了再放进队列里可能会好一些。下来查发现tomcat也确实是这样设计。7.然后继续问我看过啥源码吗，我依然回答线程池。。。大哥看我这么喜欢线程池奖励了一道设计题，让我设计一个工业可用的线程池，我的大概思路就是1.线程池集中管理、2.线程池配置热更新（分成本地更新和远程更新，本地可以考虑WatchService，远程比如放配置中心Nacos这种，Nacos的SDK里有ConfigService可以注册监听器监听配置发布）、3.线程池监控、4.线程池告警8.然后说是给我一个拔高的问题，问我线程池中死锁如何产生的，这个一时没想出来，依然从死锁的四个必要条件开始推，1.互斥、2.请求保持、3.不可剥夺、4.循环等待，推断出应该是由于出现循环等待导致四个条件同时满足（死锁只有在四个条件同时成立时可能出现，注意是可能），但是推了一会依然没推出来，让下来再想想。9.剩下就问了一个Spring有哪些拓展点，BeanPostProcessor、InitializingBean、还有Aware系列比如AppilicationContextAware这种，当时只记得这三个了。大概就这些，貌似也30-40min左右，哥们看手机显示您今天的面试已结束，还以为凉透了，刚准备去抽奖然后hr喊我名字说我通过了，前脚刚迈出来后脚就过了属于是，有点懵逼，然后抽奖走人，抽了个水杯正好拿来泡茶。总结就是真的蛮看运气的，周末两天复习实际上他问我的东西一点没看，上周刚被拷打过JVM于是恶补了一下，结果两面都基本在问线程池和408，所以感觉还是平常心看待吧，面试官想问啥确实不是面试者能左右的。。。主播以面一次赚一次的态度来的，降低预期，反而没这么紧张了，反正还是那句话，找工作就是找屎，别让一坨屎影响生活吧，虽然该找还得找。。。而且线下面的好处就是流程快和好沟通，一言不合直接画图给面试官看感觉确实比线上用手比划爽多了。发出来让大火了解一下线下面大概是个啥强度，同时希望后续顺利一些吧。。

等美团内容运营岗二面第五天，一面聊了短视频内容策划，HR 说一周内给信，急急急

无手撕，30mins左右。【面试问题】1. 🧑‍💻 请先自我介绍一下。2. 🔍 做服务时为何选择 LlamaIndex？是否调研过其他技术？3. 📚 还了解哪些相关技术4. 🧠 对 RAG 有何深入认识？5. 📄 切片（chunking）的原理是什么？6. 🧰 技术栈用过哪些语言（C/C++、Python、Go）？7. 🚀 Go 的 goroutine 与传统线程的区别是什么？8. 🔄 goroutine 的并发控制怎么做？如何等待全部结束？9. 🐳 Docker 镜像三层叠加（A 层 1 MB → B 层改 1.5 MB → C 层删除文件）后最终镜像大小是多少？10. 🗂️ 容器启动后在 C 层还能否看到被删除的 A 层文件？底层是否仍存在？11. 🧹 有哪些手段可减小最终镜像体积？（multi-stage 了解吗？）12. ☸️ 对 Kubernetes 的核心概念与组件了解多少？16. 🤖 描述 LLM、Agent、MCP 之间的关系。17. 🛠️ 是否亲手写过 Agent 或 MCP？请举例说明实现过程。场景题：13. 🖥️ 1 万台机器偶发 IO 飙高，如何定位任意时间点、任意进程的 IO 贡献？最后反问业务，面试官人非常好，非常友善，很详细的介绍了部门的情况，分享给大家。部门主要分三大块：大数据，云计算，AI Coding。大数据不谈。云计算又分上层和底层：- 上层先做“应用交付”，也就是传统部署的升级版。最早用虚拟机，资源利用率太低，现在全面换成 Kubernetes + Docker 容器化。有了容器，交付模式就变了：需求管理：企业开发不能随手写代码，得先提需求、审批、测试，全流程我们管。代码仓库：GitHub 或内部 GitLab，也是我们维护。CI/CD：以前用虚拟机构建，现在容器化，任务跑完立即释放 Pod，一天并发十几万。装包→单测→API 测试→打镜像→安全扫描→发布，每一环都是 CI 的一部分。Code Review：合并前必须过评审。CD 交付：最核心。前面就算出错也不会让站点崩溃，CD 必须保证高可用、多集群、容灾、流量无损。我们用 Kubernetes Operator 做滚动发布：5 台机器先拉 1 台做灰度，人工验证没问题再逐步扩，数据中心级别也是逐点发布。- 说完上层，再说底层：资源利用率：让一台 Node 跑更多 Pod，省的就是真金白银。混部：CI 任务结束后立即销毁 Pod，把资源立刻让给别人，进一步提高利用率。调度、监控等组件。AI Coding 部门：目标是用户提需求 + MCP 框架 + 中间件 → 自动生成代码，大幅缩短交付周期AI Code Review：用大模型 + Agent 扫描漏洞、给出优化点智能排障：AI 自动定位、修复单测失败等问题