题目整理共 8 题，参考答案基于简历与项目材料准备。 第 5 题的数据量口径需要本人补真实数字（见文末准备缺口）。

一面

1. 自我介绍

参考答案：后端岗定稿版，见 自我介绍——注意以定位句收尾（消息队列、幂等一致性、并发编排是基本功；AI 是多走的一步）。

2. 「有考虑过公司做什么吗？对工作内容有什么预期？」

答题框架（面试前必须做调研，这题考诚意）：

调研部分（一分钟内说清）：「我了解 KOOK 是围绕语音和社区的实时互动平台——频道、语音房、社区动态这些核心场景。后端的挑战我理解主要在实时性（语音房消息、状态同步）和社区内容的高并发读写。」

预期部分（具体、不空泛）：「对工作内容的预期是校招生从一条业务线的模块开发做起，在导师带教下先吃透现有系统的设计，再独立负责小模块。我个人更希望往消息投递、社区内容这类高并发读写方向深入——实习做的数据链路和两个个人项目练的都是高吞吐写入和一致性，希望能在业务里用上。」

要点：调研要说到产品功能层（说明真去用过/查过），预期要落到模块（说明知道校招生怎么成长），不说薪资加班。

3. 「实习这个 MySQL2Hive 具体做了什么工作？」

参考答案：职责边界 60 秒版，见 Binlog2Hive链路设计「标准答案」——四段既有能力编排成可配置链路；三块工作：12 阶段发布流程、全量增量衔接（wholeLoadBatchTime 锚点 + Snap2Binlog 三种迁移）、联调排查；结尾「原理我也掌握到设计级」。

必答纪律：三档动词（我打通的 / 我参与对接的 / 原理我掌握），不把采集内核和 Spark jar 说成自己写的。

4. 「本来是 T+1，时效性变成小时级，是怎么做到的？」

参考答案：

先说清结构：T+1 的瓶颈不在采集——Canal 到 Kafka 到 HDFS 原始层这一段本来就是准实时的，变更发生后分钟级就落在原始层分区里。瓶颈在 Spark 增量任务的调度周期：原来按天调度，每天合并一次写入天分区，所以是 T+1。改成小时级，就是把增量任务的调度周期从天调到小时，下游按更细的粒度合并增量、更新分区——平台本身支持小时 / 天两级调度，这是配置层的调整，但要把配套做齐。

配套三件事：一是分区粒度和调度周期要匹配，小时级调度后小文件问题会放大（调度频率 × 分区粒度相乘），要配合并小文件或调整分区策略；二是补跑粒度跟着变——历史批次补跑从按天补变成按小时补，Gap Batch 的时间范围和依赖检查粒度同步调整；三是监控阈值收紧——延迟告警基线从天级改成小时级口径。

边界主动交代：再往下到分钟级就不是调参能解决的了——批处理模型下小文件和调度压力会先爆，那时该换的是流式写入（Flink 加 Hudi/Iceberg 这类支持 ACID 的湖表格式），代价是 checkpoint、事务性 sink、小文件治理这一整套。知道什么时候该换方案，比坚持调参更重要。

5. 「每天会同步多大的数据？」 需要本人补真实数字

答题框架（数字必须真实，说不出口径等于没做过）：

按四个口径组织：① 接入规模——同步了多少张表、覆盖哪些业务库；② 日增量——每天同步多少条记录、原始 JSON 大概多少 GB；③ 峰值——Binlog 峰值 QPS 或每小时事件数（洪峰时段）；④ 全量——单张最大表的历史全量规模。可以再补一句感受：「洪峰主要来自批量写入，我们的告警阈值就是按这个水位设的。」

** 待补真实数字**——这道题面试官问的是对系统的掌控感，数字说不出等于没做过。参考实习笔记 Q11 的限流口径一起准备。

6. 「CodeAgent CLI 是什么背景？具体怎么做的？」

参考答案：

背景：「27 届找 AI 应用方向时，市面的 Agent 产品很多，但对我来说是黑盒——上下文怎么管、工具怎么路由、改坏了怎么退回，这些内部机制没人讲。所以我选择完整自研一个终端 Agent，把机制趟一遍，场景选终端本地是因为代码不出机器、且和我的 Java 技术栈契合。」

做法（简历四条 bullet 各一句 + 深挖入口）：① 执行引擎——ReAct 循环加 Function Calling，16 个本地工具和 MCP 工具统一注册、描述即路由，代码检索封装 ripgrep，10 万行级仓库 P95 < 200ms；② 任务编排——Plan-and-Execute 把目标拆成带依赖的 DAG，拓扑排序查环、分批并行、失败按进度决定重规划；③ 记忆与上下文——短期会话、长期事实、项目规则分层，动态阈值压缩解决长上下文超限，失败跳过保留原历史；④ 安全——人工审批、路径围栏、命令黑名单、审计日志四层防线，Side-Git 快照按任务回滚且不碰用户 Git 历史。

深挖必来，入口见 CodeAgent-专项题库（14 题）。

7. 「RAG 项目又是怎么做的？」

参考答案：

一句话定位：「企业内部知识库问答平台——用户上传文档，提问时基于私有知识回答，且每个回答可溯源到原文。」

按五条链路讲：① 上传——大文件分片加断点续传，分片三方校验幂等、合并乐观锁防重，1GB 从 15s 到 3s；② 流水线——Kafka 解耦解析、切块、向量化，确定性 ID 加重跑前清理保证重复消费不重复数据；③ 检索——向量 KNN 召回加 BM25 重排，权限过滤放查询层 filter 子句，recall@5 从 63% 到 85%（控制变量评测，基线是纯 BM25 降级路径）；④ 问答——WebSocket 流式，ReAct 让模型自主决定查不查（两层预算加强制收尾当笼子），编号即索引的引用溯源防伪造出处；⑤ 可用性——组织标签多级权限隔离，大模型依赖四层稳定性设计。

深挖入口见 RAG-专项题库（10 题）。

8. 场景题：「关注系统和动态系统该怎么设计？」（含表设计与细节）

参考答案（答题顺序：澄清需求 → 表设计 → 核心矛盾 → 三方案 → 细节）：

第一步，澄清需求：「先确认读写特征——feed 场景读远大于写，读写比可能在百比一这个量级；再确认关注规模上限，是否有百万粉的大 V，这决定写扩散的代价。」

第二步，核心表：

-- 关注关系：两个查询方向都要快，冗余两张表或双向索引
relation(follower_id, followee_id) -- 我关注了谁
follower(followee_id, follower_id) -- 谁关注了我
-- 各建联合索引，联合唯一约束防重复关注

-- 动态表：作者维度，一人一条链
post(id, user_id, content, status, created_at)
-- 索引 (user_id, created_at) 支撑"某人的动态"按时间翻页

-- 收件箱（推模式才有）：粉丝维度
inbox(user_id, post_id, created_at) -- Redis 用 zset，score 存时间戳

第三步，核心矛盾与三种方案：

核心矛盾是发布和浏览的成本放谁身上。拉模式（读扩散）：刷 feed 时查关注列表，把每个关注对象的 post 按时间多路归并取最新一页。发布只写一行 post，写便宜；取关天然生效；但读放大严重——关注 500 人一次刷新要归并 500 路数据。推模式（写扩散）：发布时把 post_id 写进所有粉丝的 inbox，读只需查自己的收件箱按时间倒序。读极快；但写放大恐怖——百万粉的大 V 发一条要写一百万个收件箱，且不在线的粉丝也要写。推拉结合（生产主流）：大 V 发动态不推（粉丝刷到时实时去拉他的 post），普通用户推；或按活跃度——在线粉丝推、离线粉丝等拉。读的时候自己的 inbox 和关注的大 V post 做归并。

第四步，细节追问：

• 取关：拉模式天然解决；推模式要删 inbox 里该作者的历史内容，或读时关联关系表过滤（推荐后者，异步清理兜底）。
• 分页：游标分页（last_time + last_id 做游标），不用 offset——深分页既慢又会在新动态插入时翻重。
• 大 V 发布：写扩散用 MQ 异步分批扩散，削峰、失败重试；扩散延迟对粉丝无感（晚几秒收到是 feed 常态）。
• 缓存：关注关系缓存（Redis set）、inbox 用 zset 天然按时间排序、热门作者的 post 缓存。
• 动态删除：post 软删（status 标记），inbox 里的引用读时过滤或异步清理。

收尾：「方案没有绝对优劣，是读写成本在作者和粉丝之间的分配问题——核心变量是大 V 的存在，推拉结合就是为了不对所有人一视同仁地扩散。」

复盘与准备缺口

面试官反馈：面试后端开发，就要会设计数据库——本场场景题（关注 + 动态）的表设计与细节正是考察点。

• [ ] Q5 数据量口径必须补真实数字——表数、日增条数、日增 GB、峰值 QPS。面试官问数据量是问你对系统的掌控感，这是实习深挖的最后一块裸奔的口径（和之前 98%、40+ 同类）。
• [ ] Q2 类公司调研题：面试前必做——产品功能、技术博客、招聘 JD 各过一遍。
• [ ] Q8 场景题：把表结构和三种方案亲手画一遍，练到白板能写。
• [ ] 数据库设计专项：按高频场景逐个练表设计——关注 feed（本题已做）、点赞、短链、评论、秒杀，每个练到「表结构 + 索引 + 容量估算 + 核心矛盾」四件套脱口而出。