腾讯 WXG 后端开发一面面经

《面试题目》

1. 请做一个简单的自我介绍。
2. 如果来实习，什么时候可以到岗？可以实习多久？
3. 【算法题】IP 加端口转成 uint64。
4. 【算法题】对折链表。
5. 【算法题】均匀抽样：已知 rand16() 是 0 到 65535 范围的随机数生成器，写一个函数，能随机从编号 0 到 30 万减 1 的员工中均匀抽出 1 万人。
6. 你现在还在字节那边实习吗？
7. 你所在的团队主要做什么？你个人主要负责什么？
8. 你们团队的研发流程是怎样的？
9. 你们团队平时的研发节奏怎么样？
10. 整体系统架构是什么样的？
11. 你提到的这个平台主要解决什么问题？它的作用是什么？
12. 你提到优化了某类资源的创建耗时，一般做这种性能优化时，你的思路是什么？
13. 回到这个创建耗时优化案例，目前还有没有进一步的优化空间？
14. 最有挑战的事情是什么？
15. 你提到凭证托管比较复杂，复杂性具体体现在哪里？
16. 你简历中提到一个转人工的 Agent 案例。如果要搭建一个 Agent，需要重点考虑哪些问题？需要做哪些事情？
17. Agent 中的这些 Skill 应该怎么构建？
18. 你们日常开发过程中会使用哪些 AI 产品、AI 工具？
19. 你们平时写代码主要使用哪些 AI Coding 工具？
20. 你自己平时主要使用什么 AI Coding 工具？
21. 公司不会统一提供这些 AI Coding 工具吗？需要自己购买吗？
22. 你平常主要使用什么大模型？
23. 使用大模型时，你会关注它的使用成本、Token 成本吗？
24. 你了解大模型的幻觉问题吗？
25. 大模型的幻觉是怎么产生的？为什么会产生幻觉？
26. 一般大模型的训练过程了解吗？
27. 你做过知识库、RAG，它的基本原理是什么？
28. 你刚才提到了一些向量检索算法、索引，这些算法的具体原理清楚吗？
29. 传统的搜索引擎是怎么实现搜索的？
30. 协同过滤的原理是什么？
31. 如果真的要实现一个协同过滤推荐功能，具体应该怎么实现？
32. 假设让你设计一个 12306 购票系统，你会怎么设计它的整体架构？
33. 消息队列除了你刚才说的用途，还有什么作用？
34. 你的简历主要写 Java 和 Go，你在字节这段实习也是用 Go 开发吗？
35. 为什么你笔试写代码的时候使用的是 Java，而不是 Go？
36. 你学过 C++ 吗？
37. C++ 中的 & 符号有什么作用？
38. C++ 中的 && 是什么？还记得吗？
39. C++ 的智能指针了解吗？
40. Redis 的基础数据类型以及底层实现原理了解吗？
41. Redis 的 String 底层是怎么实现的？
42. Redis 的 Set 底层是怎么实现的？
43. MySQL 这块你了解吗？
44. 简历上写了 B+ 树，能简单介绍一下 B+ 树吗？
45. B+ 树执行增、删、查、改的时间复杂度分别是多少？
46. 为什么 MySQL、InnoDB 使用 B+ 树作为索引结构，而不是其他数据结构？
47. 为什么不用哈希表作为主要索引结构？
48. 为什么不用 B 树，而选择 B+ 树？
49. 为什么不用红黑树作为 MySQL 索引？
50. MySQL 并发访问时，B+ 树会不会产生并发冲突？
51. 在 B+ 树正常执行增删查改过程中，MySQL 的锁具体是怎么应用的？
52. 大数据处理组件了解哪些？
53. 你了解哪些常用设计模式？
54. 能举一个你实际使用设计模式的例子吗？
55. 实习过程中学到了什么？
56. 反问。

《参考解析》

1. IP 加端口转 uint64：把 IPv4 的四个字节按位拼成一个 32 位整数，端口再占低 16 位，总共 48 位，放在 uint64 里绰绰有余。写法上先解析字符串，避免用 inet_aton 之外的隐式转换；如果要求可逆，就约定好布局（高 32 位 IP、低 16 位端口）并写成一对编解码函数，别让两端各自拼。
2. rand16 均匀抽 1 万人：核心是拒绝采样，把 30 万映射到 16 位随机数能均匀覆盖的区间。30 万向上取到 2 的幂是 524288，超出 30 万的那部分直接重抽，保证映射均匀；再用 Floyd 或部分 Fisher-Yates 洗牌，在 O(k) 时间内选出 1 万人，避免生成 30 万个下标再打乱。
3. 搭建 Agent 要考虑什么：先定边界——它能做哪些事、哪些动作必须人来确认；再定工具层，把每个工具的入参出参和失败语义定义清楚，让模型能判断何时调用；然后定状态与记忆，多轮任务要有可恢复的上下文；最后是可观测与兜底，记录每步的输入输出、设最大步数与超时、失败要能降级到人工。Skill 的构建同理，一个 Skill 应该是一个边界清晰、可独立验证的能力单元，而不是把所有提示词堆在一个大 prompt 里。
4. RAG 的基本原理：离线把文档切块、做 embedding 建索引；在线把问题向量化，召回 Top-K 片段，再拼进提示词让模型基于片段作答。效果差通常出在两处：切块把语义切碎、召回不准，所以要调块大小与重叠、加混合检索和重排；还有引用要可追溯，答案里带上原文出处，否则幻觉看不出来。
5. 为什么用 B+ 树做索引：B+ 树是矮胖多叉树，几层就能覆盖千万级数据，一次查询的磁盘 IO 次数等于树高，而且叶子节点用链表串起来，范围扫描和排序非常自然；非叶子节点只存键，扇出大、树更矮。哈希表只支持等值查询，范围查询和排序都要全扫；B 树把数据分散在所有节点上，范围扫描要反复回溯，且非叶节点存数据会降低扇出；红黑树是二叉的，树高随数据量线性增长到几十层，磁盘 IO 次数不可接受，它更适合内存里的有序结构。
6. 12306 的架构怎么答：先拆核心链路——查票、下单、支付、库存扣减，明确瓶颈是余票查询的读放大和票额扣减的强一致。分层上是接入层限流防刷、查询走缓存（车次余票按区间分桶）、库存用 Redis 加 Lua 做原子扣减并异步落库，下单排队削峰用 MQ，超时未支付回滚库存。要主动提两个坑：区间票的库存模型不能按整列车存，否则会出现中途站卖不出去；以及候补与退票要能复用同一套库存释放逻辑。