前言
时间过得很快，眨眼就到了大二暑假，下学期就是大三了。
7 月 13 号考完试，按计划开始海投。前面几天基本没人理：Boss 上投了、聊了大概四五百份，很多已读不回，交换简历也没下文。直到 7 月 16 号，在实习僧上约到第一家——初创小厂 FOSHO，岗位是 AI 应用开发。一面 7.16，二面 7.20；写到这篇的时候已经 7.26 了，还没结果，估计大概率挂了。但两场下来还是能复盘出一些东西。
接着 7 月 22 号收到深信服 Go 后端开发的面试邀请。23 号一面，24 号二面——差不多 24 小时内把两轮技术面赶完。到现在 HR 也还没回音，二面过没过不知道；就算过了，HR 面会不会被横向，也还说不准。
总之先把这四场记下来，当后面复习的参照。补充一句：四场都大概半小时左右，节奏都偏快。
先交代一下我的项目背景，后面读题会更清楚。两个项目都是 Go 写的：
- 偏业务 + AI 的后端：长音视频上传、异步转写/摘要、问答这类链路
- Coding Agent：更偏纯 Agent 能力（工具调用、上下文、安全策略等）
这几场下来，有几个很明显的共同点：
- 几乎零八股、零算法——基本都围着项目挖，再往外扩场景题。我猜和还没到大三暑期实习那一档有关，面试官更想确认「你是不是真做过」。
- Agent 的上下文管理几乎必问，而且会追问。
- 技术选型也常问：Go / TypeScript / Python 怎么选、为什么 Agent 也用 Go。
同一套项目，FOSHO 更抠「AI 应用是不是说圆了」，深信服更抠「后端工程判断靠不靠谱」——对比着写一篇，反而比拆成两篇更有意思。
FOSHO 两轮技术面
我猜一面偏 MT，二面偏 leader。一面面试官比较年轻，整体氛围也还行；二面感觉是个老登，估计就是 leader 了，压力也更大，会多问一些情景题和个人情况。
一面印象
流程很常规：自我介绍 → 围着第一个项目追问。两面其实都会先问：
- 项目要解决什么问题、面向什么场景
- 简历上的具体点（比如文件分片上传）
- 外延一点：目前瓶颈是什么、打算怎么优化
- Agent 为什么用这个语言、怎么选型
整体还是「简历深挖 + 轻量扩展」，没有特别刁钻的压测感。
一面题单截图：
二面印象
二面更「实际」：面试官会盯业务里模型是不是真符合需求，以及你的系统是不是真能理解用户意图。项目包装一旦和真实能力有缝，这里很容易被戳到。
二面题单截图：
想记下来的问题（先挂题，不急着在这篇里写完整答案）
下面这些问题，暂时只当「回头要补的作业」。本篇不展开标准答，之后复习时再查、再整理。
- 当用户对话零碎、跨轮次、意图还在跳跃时，怎么结合上下文判断当前意图？
- 编程场景里，如何把用户跨多轮的修改要求、函数信息、当前任务串起来？
- 为什么选这个模型？选型依据是什么？
- 过去一个月，你学了哪些新的 AI 相关知识？
（完整题单我另有整理，需要的话后面可以再贴附录。）
深信服两轮技术面
一面印象
一面就是大量项目场景拷打，再往生产环境上扩：接口突然变慢怎么办、幂等怎么做、慢查询有没有概念……不太像背题考试，更像在看你有没有工程直觉。
一面题单截图：
一面想记录的问题
- 简历里的分片上传和断点续传，怎么保证文件是正确的？
- （追问）怎么保证所有分片组合起来一定正确？（不只是「没缺片」）
- AI 编程用过哪些 Skill？
- （追问）这些 Skill 不好用 的地方有哪些？
- 用 Kafka 做调度时，重试 和 失败恢复 是怎么做的？
- 设计异步任务创建接口时，如何避免 重复创建异步任务（幂等）？
- 生产上某接口原先几十毫秒，突然变成好几秒：怎么 排查？怎么 止损？
- （追问）如果发现是 版本更新之后 才变慢，一般从哪些方向找原因？
- （再追问）什么样的 代码改动 会让接口从几十毫秒飙到几秒？
- 主要用 MySQL 吗？有没有做过 慢查询优化？
二面印象
二面更像 leader 面：除了项目选型、要解决的问题，还问了不少协作场景——产品施压、同事质疑、时间不够时怎么取舍。
想吐槽一下：面试官那边网络真的不太好，有几次听得不是特别清楚，答起来也容易飘。
二面题单截图：
二面想记录的问题
项目 / 可靠性：
- 简历里的 Kafka 异步调度 主要在解决什么问题？做了什么？
- 视频处理链路里，任务阶段 / 状态 怎么区分、怎么表示？分片（或分段）状态怎么记？请拿 一次失败 走一遍。
- 假设 ASR 已成功返回，但消费者在 更新任务状态前崩溃；恢复后消息被再次消费，可能 重复调模型产生费用——你怎么处理？
- 长任务里 部分片段转写失败（比如两段 ASR 挂了），摘要 / 后续阶段怎么处理？
- Agent 的 命令安全 是怎么做的？
协作 / 取舍情景题（三道）：
- 产品认为「每次执行命令前都问用户」影响体验，要求 默认全放开自动执行；你不同意，会怎么 推动 / 变通？
- 资深同事认为 Multi-Agent 是过度设计，要求全部改成单 Agent；你仍觉得并行调研 / 代码走读有价值——你会怎么处理？
- 项目演示只剩 两天：视频问答能跑，但 失败恢复、权限隔离、引用评测 都没做完——你会怎么 取舍？
问题参考回答记录
上面那些题，完整「标准答」我还在慢慢补。这里先记深信服一面几道场景题的参考思路（2026-07-26），主要是和 AI 讨论之后整理的；后面有更新再往这篇里加。
1. 接口突然变慢：先止损，再排查
核心原则：生产环境第一，先止损再排查。
止损
- 刚发的新版本 → 优先考虑 回滚
- 下游 / 非核心依赖出问题 → 熔断、降级，必要时给用户明确提示（维护中 / 功能暂时不可用）
- 突发大流量打挂部分节点 → 限流，保住整体可用性
排查
- 监控指标：CPU、内存、IO、goroutine 数量有没有异常飙升
- APM / 链路追踪：看 trace 上哪一段相对基线明显变慢（MySQL、Redis、其他中间件、第三方 HTTP……）
- 日志：MySQL 慢日志、应用 error 日志；顺带看连接池、有没有死锁、是否频繁 GC 等
2. 若确认是「版本更新后」才变慢：从 diff 入手
可以围绕 Git diff 和变更面来拆：
- SQL / 数据访问变更
- 新 SQL 有没有漏索引、索引失效
- 循环里打 SQL 造成 N+1
- 代码逻辑与并发
- 全局大锁把并行打成串行
- goroutine 泄露、死循环、意外的 CPU 密集计算
- 配置与连接池
- DB / Redis 连接池参数
- HTTP client 最大连接数、超时时间
- 第三方 SDK / 依赖
- 默认重试变多、同步阻塞、已知 bug 等
3. 什么样的代码改动，容易把接口从几十毫秒打到几秒？
结合 diff 看，常见「经典雷」包括：
- 循环里调 RPC / SQL → N+1
- 锁范围放大，或在锁里做 I/O
- 第三方 HTTP 没有 context timeout
- 大对象频繁分配，触发明显 GC 压力
- SQL 隐式类型转换导致索引失效 → 全表扫描
4. MySQL 慢查询优化（三步走）
- 发现：慢日志、APM
- 分析：
EXPLAIN - 优化：索引、SQL 重写、必要时动架构
看 EXPLAIN 时我会重点盯：
| 字段 | 关注点 |
|---|---|
type |
尽量到 ref / range，避免 ALL 全表扫、以及过重的 index 全索引扫 |
key / key_len |
是否真的用上索引；组合索引有没有踩 最左前缀 |
Extra |
尽量少 Using filesort、Using temporary |
小案例：深分页大 offset
问题： 订单表数据量很大，后台翻页类似：
SELECT * FROM `order`
WHERE status = 1
ORDER BY id DESC
LIMIT 500000, 20;耗时可能到秒级。
原因： 即便 id 是主键，也要先扫过大量行再丢掉；SELECT * 还会带来大量回表。
优化思路（延迟关联）： 子查询只取 id（更容易走覆盖索引），再回表取 20 行完整数据，例如：
SELECT t1.*
FROM `order` t1
JOIN (
SELECT id FROM `order`
WHERE status = 1
ORDER BY id DESC
LIMIT 500000, 20
) t2 ON t1.id = t2.id;（具体能降多少取决于数据量和索引，这里只记思路，不当作绝对数字。）
5. 异步创建任务接口：怎么做幂等
一套比较稳妥的组合：
- 客户端 / 业务侧生成全局唯一 task key（幂等键）
- 服务端用 Redis
SETNX（或等价防重）占坑：已创建则直接返回已有任务 ID + 当前状态 - 兜底：DB 对 task key 建 唯一索引；极端并发下两人一起穿过 Redis，也能靠
Duplicate entry收敛，捕获后返回已有任务 - 再配合 状态机 / 状态查询：已是 processing / success，就返回当前态，保证多次调用结果语义一致
写在后面
目前两家都还停在技术面之后的等待期，结果怎样先不硬猜。这篇主要是把时间线、两家气质、想继续啃的题，以及已经整理出来的几道生产向答法记下来。
后面如果：
- FOSHO / 深信服有后续消息
- 其它场次也面完
- 上面那些「先挂着的题」补出了自己的答案
再继续往这篇（或下一篇）更新。
先这样。