首页 > 春招-快手一二三面
头像
无面如何呢
编辑于 今天 18:36 广东
+ 关注

春招-快手一二三面

🕐面试时间:整个4月,一星期一面

🏢:主站

💻岗位:SRE运维开发

一面

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

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

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

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

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

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

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

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

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

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

HTTP123优化

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

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

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

说一下你该怎么排查CPU飙升?说一下思路和可能的原因。你该如何通过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发送落库的方案还是太慢了,你有什么更好的解决方案吗?我们要保证CK更强的实时性,性能卡点不在于CK因为CK本身查询就很快,我们发现卡点在canal+kafka同步这一块,我想要进一步优化这个同步的速度,有没有其他东西或者说一下你了解的处理方式优化原生的canal+kafka落库的生态

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

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

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

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

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

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

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

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

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

全部评论

(3) 回帖
加载中...
话题 回帖

近期热帖

热门推荐