🕐面试时间：整个4月，一星期一面

🏢：主站

一面

智能分配时如何用数学模型优化的？

你在里面负责的东西是什么呢？为什么你们不用传统的算法工程来实现而是这样子实现，这里面有什么考量吗？详细说说你们方案设计上主要考虑的点

分配失败有降级处理方案吗？

你是如何保证分配效果最优的

为什么你说原有的逻辑是粗糙的？有没有详细的指标或者描述

详细介绍一下什么是模型的硬约束和软约束

GRPC改造中你遇到了什么样的问题？为什么GRPC改造提高了响应，你里面涉及了什么其他方面的链路优化吗？

缓存优化，反射优化，字节码增强，过滤链失效，部分自定义功能失效

你弄成Skill复用后有考虑通用情况和特殊情况吗？你选用的是什么样的模式？交互型还是工作流型？

介绍几个你在企业中遇到的OOM的问题，介绍一下分别是什么原因，你是如何去排查和解决的

HTTP123优化

你说QUIC协议解决了上面的问题？你能介绍一下为什么QUIC解决了上面的问题吗？QUIC的底层知道吗？QUIC协议是如何保证可靠性的？

知道什么是OSPF和BGP吗？说一下

你该怎么排查接口变慢或者部分服务响应变慢的问题呢？说一下你的排查思路和可能的原因

你该如何通过linux命令，例如Top那种，详细定位到CPU飙升的那个Java线程然后进到他的线程里面定位到方法呢？说一下命令

free -h查出buff和cache的时候，你知道buff和cache是什么东西吗？这两个为什么不一致？

你知道什么是BIOS吗？介绍一下BIOS？

你知道什么是GPU吗？介绍一下GPU？

缓存一致性有什么样的方式可以保证？分别介绍一下

手撕-最长公共子序列

二面

手撕-斐波那契数

介绍一下你项目中应用的Agent-Skill，以及他们里面的几种模式，最后达到了什么样的效果

介绍一下你理解的数据库调优，底层一点的，你发散着来说

表层：

1.SQL优化

2.慢查询优化

3.缓存优化

4.字段优化

5.深度分页优化

6.范型设计优化

架构层：

1.主从集群

2.读写分离

3.分库分表

4.冷热分离

5.实时数仓与离线数仓

6.文件压缩

7.数据归档

8.集群同步监听监控

说一下你优雅关闭和运维那边是怎么沟通的？你们是怎么对接K8S那边的操作然后实现优雅关闭的

目前用大模型生成代码是非常简单的，这边的开发不仅做业务上的东西也开始做全栈以及平台侧的东西，你对于这个趋势是怎么看的？可能一部分自己的工作会被取代

你老家是广东的，对于来北京工作这个你怎么看呀

三面

你能介绍一下你这几段实习都是怎么找的吗？然后分别在里面学到了什么，你觉得分别对你带来了什么样的成长

你之前有在项目中做过什么算法方面的优化呢？

你说这个分配粗糙，它是怎么个粗糙法呢？能告诉我粗糙的原因和最新方案为什么就更加细致了

这个模型里面主要运用了什么样的算法来实现呢？

我大概了解了，我想问的是算法选型这方面你们是怎么考量的，就像你说的要价格最优，那为什么我不直接在代码中做各种判断然后价格分配就行了呢？我听你这样子说逻辑，好像贪心算法也能搞定，你们选择其他算法的时候有过对比和考量吗？测试的效果和性能那些

这个的话就介绍一下爬山算法以及类似算法对于业务场景的适配度，爬山算法其实本质上也是贪心算法的一种

你这种是代码方面你做的东西，像是一些单点故障的下降率，我想知道的是你们这东西给团队带来了什么收益，而不是代码上的指标，就是你们落地的时候给团队带来了多少收益，实现了怎样的效果，这方面你有关注吗？

你说的计算的并发度，以及在不同核心服务器压测，你能说一下这执行的细节吗？最后你们有什么样的考量？

我想知道，你们这个分单是怎么实现的？例如有些质检单很大批的发送给kafka，然后你们计算的时候单量特别大，这个时候内存占用和cpu占用就会很大，可能消耗很多的资源，这方面你有考虑吗？

我还有个问题，假如说和你们合作的实验室规定的产能启动要求是5k，但是你们这批货的总产能就是3k，你分配不过去，实验室不会开工，这方面你们有考虑过吗？实际中你们是怎么处理的？

你们是怎么判断这个的落地的效果的呢？我看你好像是把这个权重分配换成了智能求解，那么它的一个效果是怎么样的呢？给我你们最终落地的详细指标

三个场景题

Kafka消费者突然消费过慢，这方面你会如何去排查呢？你觉得这个慢会有什么因素在里面呢？

止血操作和扩容操作的选型，定位问题是error还是说cpu飙升，内存不足，下游设置不合理导致被其他服务拖垮，并发度设计问题，上面是通用场景，对于kafka的话还有个特殊场景，海量并发场景出现的重平衡风暴

Redis查询和操作过慢的话你觉得会是什么问题呢？你该如何排查和解决这个问题呢？

思路和上诉一致，但是对于Redis的话会有几个特殊场景，一种是hash结构频繁rehash拖慢了服务，还有一种是redis内存不够将固态硬盘sdd当成了内存使用，所以表面没问题实则还是慢了很多

我们的数据库集群的数据非常大，kafka将日志同步给CK的方式因为我们的数据非常大，导致消费还是很慢了，但是我们ck是实时数据库我们要求实时查询，我就是要保证这个业务数据查询的实时性，但是市面上的kafka发送落库的方案还是太慢了，你有什么更好的解决方案吗？

压缩算法，零拷贝，扩容，消费线程调优，缓存实现日志去重，咆哮位图实现日志去重。我说的可能太表层了，这个的话面试官说是可以但是没达到点上，面试完才想起来面试官问的应该是生态选型，我之前看过但是没想起来，面试完才发现问的是flinkcdc。传统的canal+kafka太慢的原因就是kafka的消费者太慢了，所以应该想到flink cdc，我没联想到.....

我看到你用过爬虫是吧？市面上的很多网站都有一些反爬机制，我想问你该如何设计一个高可用的爬虫，保证我们爬虫爬取信息的质量以及让我们爬取的性能更高？

我们现在的运维平台那边有很多的指标和日志，但是线上可能会有很多问题，你知道我们如何利用AI去实现更高效的排查或者是自动排查定位问题吗？介绍一下你实战中的AI排查，以及你觉得这个排查的形态应该是怎么样的？

你说一下RAG和MCP他们的区别吧，然后说一下他们分别适用什么不同的场景

你知道什么是多MCP架构吗？为什么Skill的存在优化甚至说解决了之前的多MCP结构，这个你知道吗？

你觉得Skill的存在能优化或者实现和改变刚刚上面说的多个MCP的方式吗？优点和好处是什么？

三面反馈都很好，而且面试推进很快都是第二天秒约面，我每次面试完就知道自己技术面过不过了，最后的三面我真的是拼尽全力了，上面问的我基本都说出来了，除了个flink cdc我没答好，但是基本的日志去重和表层优化都说了，最后排序13天，横向对比挂，前面的人接了，我流程结束，而且运开也会要求运开经验的，不然那么大流量一个平台没啥这方面基础的人进去弄崩了咋交代？

已经习惯了，反正每次都终面都是排序挂的，只能说技术面过了就是对得起自己了，我也不care最后过不过了，技术面挂了是自己的问题，技术面都过了然后横向挂了我也没啥波澜了，毕竟人那么多，大佬也挺多的，我认识很多很强的人也都是技术面全过最后横向2星期挂的，只要技术面过了对得起自己就行了，最后横向也没办法了，横向是肯定躲不过的一关

只能说还需点努力，还需点运气