忽然想起了我的第一份实习。事情是这样的：在我刚进公司第二天的时候，就要负责面试校招的同学，由我这边根据聊的情况来决定他是不是能进入到下一轮业务面试，不行的话就一键淘汰，说是掌握各位同学的生杀大权也不为过。本着对大家负责的态度（其实是因为自己当时也是本科应届很共情了），每一个人我都聊得很认真，时间也相对长一点。然而，随着手上的岗位从单一产品营销线的售前、销售、项目，慢慢扩展到覆盖各个产品线的产品经理、产品运营、市场运营、用户体验and前后端开发等等等等，要对接的部门负责人和工作量成倍增加。终于，有一天，我的mentor跟我说，我这里有几个人力岗的，你也来面一下。终于，我忍不住了，“我草？”脱口而出。她笑了，说：“我一直在等，你什么时候会说出这句话。”我：终究还是不负你的期待了。

1. 自我介绍2. 详细讲一下实习工作的内容3. 为什么一般说 RPC 性能优于 HTTP答案：严格来说，不能简单地说 RPC 一定优于 HTTP，更准确的说法是很多 RPC 框架在内部服务调用场景下通常比传统 HTTP/1.1 + 文本协议更高效。原因主要在于协议更轻、序列化更紧凑、连接复用更充分、接口定义更明确。很多 RPC 框架会使用 Protobuf 这类二进制序列化格式，相比 JSON 体积更小、解析更快；同时内部调用路径往往不需要那么多通用语义字段，报文开销更低。另外，RPC 框架通常把服务发现、负载均衡、超时控制、重试、熔断、链路追踪这些能力整合进去了，所以在工程上也更适合服务间...

我面的是Golang后端，结果上来基本上不问后端问题，全问的是AI方向的，也不问简历，什么Go协程，并发，GMP调度和大部分是数据结构底层八股全部都不问，还有后台常考的Mysql，Redis和MQ也不问。问了大模型落地训练微调量化，还有FunctionCalling，MCP，龙虾Skill。出了两个简单的计算题有一个结果还出错了，我推导半天结果有问题，最后拿编译器穷举发现根本没结果。最后问为什么不问后端题目而是问AI方向的，回答是因为我简历里面的项目全是保密项目，技术难点不可能达不到真实业务高并发需求，所有的实现都是基于标书的，所以问了等于没问，索性就不问了。面完之后感觉人都麻了，感觉就是不想面，还不如直接说出来拒接，浪费双方的时间。题目：abc+cba=1331，求解a+b+c=？我的解法是：100a+10b+c+100c+10b+a=1331101a+20b+101c=1331101(a+c)=1331-20b令a+c=x∈0-18,b=y∈0-9101x=1331-20y右边y的系数是20，所以不管怎么减右边个位数都是1，那么左边101只能乘个位数为1的数也就是x要么是1要么是11，但是1和11的时候y都不满足条件0-9然后我人麻木了陷入了怀疑，就拿编译器用穷举（三重for循环实现）package mainimport "fmt"func main() {for a := 0; a < 10; a++ {for b := 0; b < 10; b++ {for c := 0; c < 10; c++ {if 101*(a+c)+20*b == 1331 {fmt.Println(a + b + c)fmt.Printf("a: %d, b: %d, c: %d\n", a, b, c)}}}}}最后结果也是没有输出，最后面试官才反应过来是1131算了半天结果是题目有问题

1. 自我介绍2. 介绍一个你做得比较完整、个人成长最多的项目，背景、目标、方案和效果是什么？3. 做这个项目时具体用了哪些方案或手段达成目标？答案：最核心的是把问题拆开，没有直接把所有文档塞给大模型。文档侧先做结构化解析，保留标题层级、版本号、适用部门、发布时间和权限标签；检索侧用了 BM25 和向量召回融合，因为制度类问题经常包含专有名词、系统名和缩写，单纯向量召回容易漏；生成侧强制模型基于证据回答，不允许没有证据时编造。训练侧做了两类任务，一类是意图分类和工单类型预测，用历史工单标题、正文、处理队列作为弱标签，再人工抽检；另一类是指令微调样本，用高质量问答、证据片段和标准处理建议构造。线...