抖音电商裁员情况

实验室是做LLM的，研一做了一个LLM应用的项目，主要是负责RAG这块，做问答，无论文。研一暑期实习也是做的LLM应用，目前在第二段实习，也是多模态RAG方向，一直用的py写一些简单的后端。目前纠结是深入LLM，搞LLM开发+算法，还是兼顾java。求各位大佬给些意见。

timeline：一面 9/10自我介绍实习挖掘项目挖掘：Embedding时用到的向量数据库，文章解析和分块的功能等，ES的原理，召回的策略实习比较大的挑战和难点是什么项目关于Redis有用到哪些情景Redis是内存数据库，有什么机制去防止数据丢失（RDB，AOF）Redis如何处理过期的情况Redis有哪些具体的数据结构介绍一下BitMap介绍一下ZSet提到了ZSet用于排行榜，如果相同分数但是我想让先达到这个分数的人排在前面，如何设计（加时间戳的综合score）ZSet的底层实现是什么样的，讲解一下数据库中有比较大的表，如何进行分表，比较的依据有哪些数据库事务的特性ACID介绍一下索引，索引和事务的关联手撕：lc485，最大连续1的个数二面 9/19自我介绍问实习项目用kafka用在了哪里为什么选用kafka，不用其他的消息队列为什么文件上传这种轻量的要用kafka消息队列的丢失如何处理如何监控是否上传成功告警的频率以及如何设置的，是埋点还是别的是实时的数据吗还是离线的数据同步看板是利用了什么方式如果看板数据无穷无尽的话grafana搞不定怎么解决kafka发送一条消息到消费经历什么过程如果超过最大处理次数都没有成功会怎样手撕：lc109：有序链表转换二叉搜索树三面10/9自我介绍问实习提示词优化了什么，技术难点校验规则变化了怎么处理XXL-Job讲一下怎么用的XXL-Job的推和拉，有什么区别哪个好手撕：lc581：最短无序连续子数组hr面 10/14意向 10/21感谢字节收留

这是一个典型的“消息分发模型”设计问题，微博/社交平台在设计大V发博分发时，推模式（push） 和 拉模式（pull） 各有利弊。下面结合你提到的“大V发博客”场景详细分析：一、两种模式简介推模式（push）大V一发微博，系统立即将内容推送到每一个粉丝的时间线中（如写入粉丝的消息队列或Feed中）拉模式（pull）粉丝查看时间线时，实时去拉取他关注的人（如大V）最新发布的内容，再合并排序显示二、微博类应用场景选型✅ 小V/普通用户：使用 推模式粉丝数少，推送量小；内容分发量级低；直接推送到粉丝的 Feed 表中，读取快，体验好。⚠️ 大V用户（如百万粉丝）：不能用纯推模式，会有严重问题顺便吆喝...

今天得知秋招被毁意向，这下得从头再来了。😅