Transformer 细节

Transformer 是 LLM 面试 100% 命中的考点。不需要会推导, 但每个组件都要能讲 3 分钟。

Self-Attention 计算公式

Attention(Q, K, V) = softmax(Q·Kᵀ / √d_k) · V

# Q, K, V 分别由输入 X 经过 3 个线性变换得到
Q = X · W_q   # [seq, d_model] · [d_model, d_k] → [seq, d_k]
K = X · W_k
V = X · W_v

每个变量的物理意义

• Q (Query): 「我要找什么」 —— 当前 token 的查询向量。
• K (Key): 「我的标识」 —— 每个 token 的关键字, 用于被匹配。
• V (Value): 「我的内容」 —— 每个 token 实际的信息载体。
• QK^T: 相似度矩阵, 维度 [seq, seq], 第 i 行 j 列 = 第 i 个 token 对第 j 个 token 的关注度。
• /√d_k: 缩放, 防止 softmax 进入梯度消失区域。
• softmax: 归一化, 把相似度变成概率分布。
• ·V: 用注意力权重加权求和 V, 得到聚合后的表示。

Multi-Head Attention

用 h 个并行的 Attention 头, 每个头学不同的「关注模式」, 最后 concat 起来再线性变换:

MultiHead(Q, K, V) = Concat(head_1, ..., head_h) · W_o
其中 head_i = Attention(Q · W_q^i, K · W_k^i, V · W_v^i)

关键: 每个头的 d_k = d_model / h, 总参数量和 single-head 相同, 但表达能力更强 (能同时关注「语法关系」、「语义关系」、「位置关系」等不同模式)。

位置编码演进

常见追问 (10 个)

1. Self-Attention 和 RNN 比, 优缺点是什么?
   → 优: 并行计算 + 长距依赖。缺: O(n²) 内存。
2. Multi-Head 为什么比 single-head 好?
   → 同时学习多种关注模式 (语法/语义/位置)。
3. 为什么要 LayerNorm 而不是 BatchNorm?
   → Transformer 的 batch 内序列长度不一, LN 在 feature 维度更稳定。
4. Pre-LN 和 Post-LN 区别?
   → Pre-LN 更稳定 (梯度直通), Post-LN 收敛快但需要 warmup。当前 LLM 都用 Pre-LN。
5. FFN 为什么用两层 + 中间放大 4 倍?
   → 升维让模型有更强的非线性能力, 4 倍是经验值。
6. Encoder-only / Decoder-only / Encoder-Decoder 区别?
   → BERT / GPT / T5; 现在 LLM 都是 Decoder-only。
7. KV Cache 是什么?
   → 推理时缓存历史 K,V, 避免重复计算, 大幅加速 generation。
8. FlashAttention 解决什么问题?
   → 用分块计算 + 重计算, 把 attention 内存复杂度从 O(n²) 降到 O(n)。
9. MoE (Mixture of Experts) 原理?
   → 每个 token 只激活一部分专家, 大幅扩参不增加推理成本。
10. GQA (Grouped Query Attention) 是什么?
    → 多 Q 头共享 K,V 头, 推理时减少 KV cache 内存。

预训练与微调

从「预训练 (Pretrain)」到「微调 (Fine-tune)」是当前 LLM 训练的两大阶段。理解每个阶段的目标、数据、方法, 才能讲清 LoRA / QLoRA / SFT 这些高频名词。

训练阶段全景

Pretrain 数据 & 算力

• 数据规模: GPT-4 估计 ~10T+ tokens, LLaMA-3 训练 15T tokens。
• 数据组成: Web (CommonCrawl) + 书籍 + 论文 + 代码 + 多语言。
• 数据清洗: 去重 + 质量过滤 + 安全过滤 + 编程数据加权。
• 算力: LLaMA-2 70B 训练用了 ~2000 张 A100, 约 30 万 GPU 小时。
• Scaling Law: 参数量、数据量、算力大致按 N^α 关系 scaling, Chinchilla 论文给出最优配比。

SFT 详解

Supervised Fine-Tuning, 用「指令 + 答案」对教模型按指令回答。

# SFT 数据示例 (JSONL 格式)
{"instruction": "解释什么是 RAG?",
 "input": "",
 "output": "RAG 全称 Retrieval-Augmented Generation, ..."}

# 训练 loss = next token cross entropy
# 关键: 只对 output 部分计算 loss, instruction 部分 mask 掉

SFT 数据质量 > 数量

Meta LIMA 论文证明: 1000 条高质量 SFT 数据 + 65B 预训练模型, 效果就能接近 ChatGPT。质量比数量重要 10 倍。

微调方法对比

LoRA 原理

低秩分解: 原 W 矩阵 [d, d], 不直接更新, 而是加上一个小矩阵 ΔW = A · B, 其中 A: [d, r], B: [r, d], r << d。

W' = W + A · B   # A,B 是新加的小矩阵, 只更新这两个

# 参数量从 d² 降到 2dr, 当 r=8, d=4096 时减少 256 倍

QLoRA 原理

QLoRA = LoRA + 4bit 量化:

1. 把预训练模型量化到 NF4 (4-bit Normal Float), 显存 ÷ 4。
2. 在量化模型上做 LoRA 微调, 反向传播时反量化。
3. 实际效果: 65B 模型可以在单卡 48GB GPU 上微调。

常见追问 (8 个)

1. 什么时候做 SFT, 什么时候做 LoRA?
   → SFT = 通用方法名, LoRA = SFT 的一种参数高效实现。一般 SFT 默认指 LoRA。
2. LoRA 的 r 怎么选?
   → 一般 8-64, 任务简单 r=8, 复杂任务 r=32 或 64。
3. QLoRA 比 LoRA 慢多少?
   → 慢 20-30% (4bit 反量化开销), 但显存省 4 倍, 性价比极高。
4. SFT 数据量该多少?
   → 1k-100k 都行, 关键看质量。LIMA 证明 1k 高质量已足够。
5. 怎么判断 SFT 是否过拟合?
   → 验证集 loss 上升 / 输出重复模板化 / 失去通用能力。
6. SFT 后会丢失原模型能力吗?
   → 会, 叫「灾难性遗忘」。解决: 加少量原始数据混训 / 用 LoRA 限制改动。
7. 什么是 Continual Pretrain?
   → 在预训练模型上继续用领域语料 next-token 训练, 注入领域知识。
8. LoRA + SFT 的训练 loss 是什么?
   → Cross entropy on next token, 只对 output 部分计算。

RLHF / DPO 对齐

SFT 让模型「会答」, 对齐让模型「答得好」。这部分是 LLM 高频考点中的高频。

三种主流对齐方法

RLHF 详解

3 阶段流程:

Stage 1: SFT
   输入: 指令-答案对
   输出: SFT 模型 π_SFT

Stage 2: Reward Model
   输入: 「指令 + 答案A + 答案B + 偏好 (A好/B好)」
   训练: 学一个 R(x, y) 给答案打分
   输出: 奖励模型 RM

Stage 3: PPO
   输入: 指令 x
   过程: π 生成 y → RM 打分 → PPO 更新 π
   关键 loss = R(x, y) - β · KL(π || π_SFT)
              ← 防止 π 跑太远

RLHF 三大痛点

1. 训练不稳: 4 个模型同时跑 (π, π_old, RM, ref), 任何一个炸都重来。
2. 资源密集: 需要 4 倍显存 + 复杂调度。
3. RM 难训: 奖励模型本身可能被「过拟合」, 导致 reward hacking。

DPO 详解

核心思想: 跳过 RM, 直接用偏好对优化策略。

DPO 数学原理 (简化)

# 偏好对: (x, y_w, y_l) - x 是输入, y_w 是更好的答案, y_l 是较差的

DPO loss = -log σ(β · [log(π(y_w|x) / π_ref(y_w|x))
                       - log(π(y_l|x) / π_ref(y_l|x))])

# 直觉: 让 π 给 y_w 的概率提高、给 y_l 的概率降低
# 同时不让 π 离 π_ref 太远 (隐式 KL 约束)

DPO 优势

• 稳定: 只有 2 个模型 (π 和 π_ref), 不需要 RM 和 PPO。
• 高效: 训练成本 ≈ SFT 的 1.5 倍, RLHF 的 1/5。
• 效果接近: 在主流 benchmark 上和 RLHF 持平甚至略好。

GRPO 详解 (DeepSeek 用)

Group Relative Policy Optimization, PPO 的简化版:

• 核心改动: 不用 critic 模型, 直接用「同一组答案的相对分数」作为 advantage。
• 训练流程:
  1. 对每个 prompt 采样 G 个答案 (典型 G=8)。
  2. 用 RM 给 G 个答案分别打分。
  3. 计算「组内归一化分数」: (R_i - mean) / std。
  4. 用这个归一化分数作为 advantage, 跑 PPO 更新。
• 优势: 比 PPO 少一个 critic 模型, 训练成本降 1/3。

常见追问 (10 个)

1. RM 为什么用 Bradley-Terry 模型?
   → 经典偏好建模方法, log loss 形式简单。
2. KL 约束作用是什么?
   → 防止 RLHF 后的模型偏离 SFT 太远, 失去多样性。
3. 什么是 reward hacking?
   → 模型学会「骗」RM 拿高分, 而不是真正变好。比如说话变啰嗦但答案空洞。
4. DPO 和 SFT 区别?
   → SFT 只学正例, DPO 同时学正例 + 负例, 信号更强。
5. 偏好数据怎么标?
   → 人工标 (贵) / RM 标 (快) / 模型自标 (RLAIF)。
6. DPO 的 β 怎么选?
   → 一般 0.1-0.5, 越大越保守 (接近 π_ref)。
7. RLAIF 是什么?
   → Reinforcement Learning from AI Feedback, 用 LLM 代替人标偏好。
8. 怎么评测对齐效果?
   → MT-Bench / AlpacaEval / Arena 人工对战 / LLM-as-Judge。
9. 对齐后模型能力会下降吗?
   → 会, 叫「alignment tax」, 通常用更多 SFT 数据缓解。
10. DPO 后能再接 PPO 吗?
    → 可以, 但收益小, 业界一般 SFT → DPO 就够了。

系统设计 · 5 步答题法

系统设计题最怕「上来就画架构」。5 步法是通用框架, 用熟了 25 分钟内能稳稳答完 RAG / Agent / 推理系统这些经典题。

5 步法概览

Step 1: 澄清需求    (3-5 min)
Step 2: 整体架构    (5-7 min)
Step 3: 关键决策    (8-10 min) ← 拉开差距的部分
Step 4: 工程考虑    (3-5 min)
Step 5: 瓶颈与扩展  (2-3 min)

Step 1 · 澄清需求

不澄清就开做是最大忌。主动问 5 个问题:

1. 用户规模: DAU 多少? QPS 多少?
2. 数据规模: 文档量 / 知识库大小?
3. 延迟要求: 用户能接受的响应时间?
4. 多模态: 纯文本 / 含图片 / 含表格?
5. 核心场景: 主要 use case 是什么?

面试官的回答会大幅决定后面的设计方向。面试官没说的 = 你自己定个合理假设, 大声说出来。

Step 2 · 整体架构

用「数据流向」画图, 上下游清晰:

用户 → API Gateway → 应用服务 → [核心组件 1, 2, 3] → 数据层
                          ↓
                       缓存 / 队列

• 每个模块用方框 + 1 句话功能, 不写代码。
• 箭头标明数据流向 + 数据格式 (JSON / Embedding / Token)。
• 不画细节: 类似 OS 课, 先把「图书馆借书流程」画清楚, 别上来就讲「书架第几层」。

Step 3 · 关键决策（拉开差距）

这一步是平庸答案和优秀答案的分水岭。每个关键决策都要回答「为什么 A 而非 B」:

关键决策模板

决策点 1: 选 X 还是 Y?
   候选: X (优势 / 劣势)
        Y (优势 / 劣势)
   选择: X, 因为 [本场景的具体权衡]
   # 比如: 选 Milvus 而非 ES, 因为 100w+ 向量量级时 Milvus 检索快 5 倍

每个项目 / 系统设计题, 至少准备 3 个关键决策。

Step 4 · 工程考虑

展示「能落地」的能力, 不是纸上谈兵:

• 权限 & 安全: 数据隔离 / 接口鉴权 / 敏感词过滤。
• 监控 & 告警: QPS / 延迟 / 错误率 / token 消耗。
• 降级 & 限流: 大模型超时 → 切小模型 / 缓存兜底。
• 评测 & A/B: 在线效果监控 + 离线评测集。
• 增量更新: 知识库新增 / 删除 / 更新怎么处理。

Step 5 · 瓶颈与扩展

面试官常追问的几个方向:

• QPS 翻 10 倍: 怎么扩? 缓存层 + 异步队列 + 模型分级。
• 文档量翻 100 倍: 切片策略调整 / 分片检索 / 用 RAG-Fusion。
• 多语言: Embedding 模型换成多语模型 (mE5, BGE-M3)。
• 多模态: 图片用 CLIP / 表格用 LayoutLM。

常见追问准备

1. 「你这个方案的瓶颈在哪?」 → 永远要先回答「LLM 调用是单点瓶颈」。
2. 「如果延迟降到 100ms 怎么办?」 → 缓存 + 提示词压缩 + 模型蒸馏。
3. 「数据脱敏怎么做?」 → 输入前过滤 PII + Output 后置过滤。
4. 「成本怎么控制?」 → token 缓存 + 模型分级 + batch processing。

系统设计 · 设计一个 RAG 系统

面试官最爱让你 30 分钟设计一个企业 RAG 系统。按 5 步法走, 关键在 Step 3 的「关键决策」秀出深度。

Step 1 · 澄清需求

主动问 5 个问题, 假设面试官给出:

用户规模: 100w 用户 / 日活 30w / QPS 峰值 100
文档规模: 10w 篇文档 / 平均 5k token
延迟要求: P95 < 5s
多模态:   主要文本, 少量 PDF 带表格
核心场景: 企业内部知识库问答 (客服 / IT / HR)

Step 2 · 整体架构

用户 ──→ API Gateway ──→ 应用服务
                              │
            ┌─────────────────┼─────────────────┐
            ↓                 ↓                 ↓
        [Query 重写]      [混合检索]        [Rerank]
            │                 │                 │
            └─────────────────┴─────────────────┘
                              ↓
                        [LLM 生成]
                              ↓
                         返回答案

数据入库流水线 (离线):
  文档 → 解析 → 切片 → Embedding → 入向量库 + 全文索引
                                  ↓
                              Milvus + ES

Step 3 · 关键决策（5 个）

① 切片策略

• 固定长度 (500 token + 50 重叠) 简单但可能切断语义。
• 语义切片 (按段落 / 标题) 更准但慢。
• 选: 混合策略 - 段落优先, 超过 max 长度再固定切。

② Embedding 模型

选 BGE-Large-zh, 因为内部部署 + 中文场景效果好 + 可微调。

③ 检索策略

单路语义召回 → 在多义词 / 罕见词上准确率约 68%。

选混合检索:

BGE 召回 top50 (语义)
+ BM25 召回 top50 (关键字)
+ Reranker 精排 top10 (BCE-Reranker)

实测准确率从 68% → 91%。

④ Reranker

初步召回的 100 条候选, 用专用 Reranker 模型重排 top 10:

• Cross-Encoder (vs Bi-Encoder) 准确率更高, 但慢。
• 因为候选已减到 100 条, Cross-Encoder 延迟可控 (~200ms)。

⑤ LLM 生成

• 模型选型: Qwen2-72B (本地部署 vLLM) + GPT-4o (复杂问题降级)。
• Prompt 设计: 严格限制「仅基于上下文回答」, 防止幻觉。
• 引用标注: 答案中标注来源文档, 用户可追溯。

Step 4 · 工程考虑

• 评测回路: LLM-as-Judge + 人工抽检 500 题, 每周回归。
• 权限: 文档级 ACL, 用户只能检索有权限的文档。
• 监控: 召回率 / 准确率 / token 消耗 / 用户反馈。
• 增量更新: 监听文档变更事件 → 异步 re-embed → 增量入库。
• 降级: LLM 超时 → 直接返回 top-3 切片让用户自己看。

Step 5 · 瓶颈与扩展

• QPS 翻 10 倍: Embedding 缓存 + Rerank 异步化 + LLM 流式输出。
• 文档量翻 100 倍 (1000w): 分片向量库 + 路由检索 + 索引压缩。
• 多语言: 换 BGE-M3 (多语 SOTA), 或对每个语种独立索引。
• 多模态: 图片用 CLIP / 表格用 LayoutLM 单独 embedding。

常见追问 (8 个)

1. 幻觉怎么解?
   → 严格 prompt + 召回 + 引用标注 + Reranker 提质量。
2. 切片长度怎么选?
   → 200-800 token 都行, 太短上下文不够, 太长检索粒度粗。
3. BGE 怎么微调?
   → 用 (query, positive, negative) 三元组, 对比学习 loss。
4. 怎么处理长文档?
   → 父子分片: 切小段做检索, 召回时返回父段落给 LLM。
5. 引用标注怎么实现?
   → Prompt 强制 LLM 输出 [doc_id] 格式, 后置解析。
6. 评测准确率怎么定义?
   → 答案正确率 + 召回 hit@K + 用户点击/反馈率。
7. 如果文档每天更新 10 万?
   → 增量入库 + 异步 embedding + 监听数据库 binlog。
8. 怎么防止 prompt injection?
   → 输入清洗 + 严格 system prompt + 输出过滤。

系统设计 · 设计一个 Agent 平台

2025 年起 Agent 平台成了系统设计高频题。考点不再是「Prompt 怎么写」, 而是多业务方接入、稳定性、可观测性。

Step 1 · 澄清需求

业务方: 公司内部 10+ 业务线 (客服 / IT / HR / 运维 / 数据 ...)
规模: 月调用 100w+, 峰值 QPS 200
延迟: 简单查询 ≤ 3s, 复杂任务异步执行
工具数: 50+ 内部 API + 外部 API
稳定性要求: 工具调用成功率 ≥ 95%

Step 2 · 整体架构

业务方 ──→ Agent API ──→ 编排引擎 (LangGraph)
                            │
        ┌───────────────────┼───────────────────┐
        ↓                   ↓                   ↓
   [理解节点]          [工具调用层]         [记忆系统]
                            │                   │
                            ↓                   ↓
                      [工具注册中心]      [向量库 + Redis]
                       (MCP 协议)
                            ↓
                    内部 API + 外部 API
                            │
                            ↓
        ┌───────────────────┼───────────────────┐
        ↓                   ↓                   ↓
   [观测平台]          [安全沙箱]           [评测回路]

Step 3 · 关键决策（6 个）

① 编排引擎选型

选 LangGraph: 状态机模型最适合 Agent 多步推理, 状态可序列化便于持久化和重放。

② 工具注册中心

50+ 内部 API + 各种外部 API 怎么管?

• 用 MCP (Model Context Protocol) 协议统一接入。
• 每个工具发布到中心化「工具市场」, 业务方自取。
• 工具元信息包含: 描述、参数 schema、权限、限流配置。
• LLM 通过 function calling 调用, 通过工具网关 dispatch。

③ 记忆系统

短期记忆: Redis 存对话上下文 (1 小时 TTL)
长期记忆: 向量库存用户偏好 / 历史问答
工作记忆: 当前任务的中间结果 (DAG 节点产物)

④ 工具调用稳定性

「工具调用成功率 ≥ 95%」是关键 SLA, 提升手段:

1. 参数校验: LLM 输出的参数先经 schema 校验, 失败立即重试。
2. 智能重试: 5xx 重试, 4xx 让 LLM 重新生成参数。
3. 降级: 工具 timeout → 用缓存数据 / 默认值。
4. 限流: 每个工具单独限流配置, 防止下游打挂。
5. 幂等: 写操作类工具必须支持 idempotency key。

⑤ 观测平台

Agent 失败时, 必须能完整 replay 整个执行链路:

• 每步执行: 节点名 / 输入 / 输出 / 耗时 / 错误。
• LLM 调用: 完整 prompt / response / token 数 / 模型版本。
• 工具调用: 请求体 / 响应 / 状态码。
• UI: trace 树形展示, 一键 replay。
• 推荐: LangSmith / Phoenix / 自研。

⑥ 安全沙箱

• 权限边界: 每个用户 / 业务方有工具白名单, RBAC 控制。
• 代码执行隔离: 如果支持代码 interpretator, 必须容器 + 网络隔离。
• 敏感数据过滤: 输入 PII 检测, 输出敏感词过滤。
• 调用配额: 每个业务方有 token / API 调用配额。

Step 4 · 工程考虑

• 评测回路: 自动评测集 (固定 100 个典型任务) + 在线随机抽样人工评测。
• A/B 测试: 不同 prompt / 不同模型 / 不同工具组合的对比。
• 异步执行: 长任务用消息队列异步, 用户轮询或 webhook 通知。
• 成本控制: token 缓存 + 模型分级 (简单任务用小模型) + batch 处理。

Step 5 · 瓶颈与扩展

• QPS 翻 10 倍: 异步化 + 缓存 + 多副本部署。
• 工具翻 10 倍 (500+): 工具检索机制 (按 description 召回 top10 给 LLM 选)。
• 多租户隔离: 按租户独立队列 + 配额 + 监控。
• 新业务接入: SDK + 自助门户, 不需要平台开发介入。

算法必刷题清单

面试常考的 7 大题型, 每类至少刷 5 题。Hot 100 + 这 35 题, 大厂校招 + 社招笔试 90% 不出范围。

7 大题型概览

详细题单（每类 5 题）

① 数组 / 双指针

1. 15. 三数之和 - 排序 + 固定一个数 + 双指针
2. 42. 接雨水 - 左右双指针 / 单调栈
3. 56. 合并区间 - 排序 + 模拟
4. 75. 颜色分类 - 三指针荷兰国旗
5. 11. 盛最多水的容器 - 双指针

② 哈希 / 滑窗

1. 1. 两数之和 - 哈希表 O(n)
2. 3. 无重复字符最长子串 - 滑窗 + 哈希
3. 76. 最小覆盖子串 - 滑窗
4. 128. 最长连续序列 - 哈希
5. 49. 字母异位词分组 - 哈希 + 排序

③ BFS / DFS

1. 200. 岛屿数量 - 模板 DFS
2. 102. 二叉树层序遍历 - BFS
3. 124. 二叉树最大路径和 - 后序 DFS
4. 101. 对称二叉树 - 递归 DFS
5. 127. 单词接龙 - BFS

④ 动态规划

1. 70. 爬楼梯 - DP 入门
2. 300. 最长递增子序列 - DP O(n²) / 二分 O(nlogn)
3. 5. 最长回文子串 - 中心扩展 / DP
4. 72. 编辑距离 - 二维 DP
5. 121. 买卖股票最佳时机 - DP 经典

⑤ 堆 / 优先队列

1. 347. 前 K 高频元素 - 堆
2. 23. 合并 K 升序链表 - 堆
3. 295. 数据流的中位数 - 大小堆
4. 215. 数组第 K 大元素 - 堆 / 快选
5. 239. 滑窗最大值 - 单调队列

⑥ 回溯

1. 78. 子集 - 模板
2. 46. 全排列 - 模板
3. 51. N 皇后 - 经典回溯
4. 39. 组合总和 - 回溯
5. 79. 单词搜索 - DFS + 回溯

⑦ 图 / 并查集

1. 207. 课程表 - 拓扑排序
2. 743. 网络延迟 - Dijkstra
3. 547. 省份数量 - 并查集
4. 133. 克隆图 - DFS / BFS
5. 684. 冗余连接 - 并查集

算法应试策略

同样会一道题, 不同人面试表现能差 30%。应试技巧本身就是分数的一部分。

面试现场 5 步法

Step 1 · 主动澄清边界（30 秒）

读完题不要立刻动手, 主动问 2-3 个问题:

• 输入范围: 数组长度? 数值范围? 有负数 / 0 吗?
• 边界情况: 空输入怎么办? 重复元素?
• 输出要求: 多解返回哪个? 顺序要求?

加分项: 主动澄清显示「严谨思考」, 这点几乎所有面试官都会单独打分。

Step 2 · 讲思路（2-3 分钟）

你: 这题我的思路是 [简述]. 整体思路 [大概几步].
    最直接的解法是 [暴力解], 时间复杂度 O(?).
    我能想到的优化是 [优化解], 时间 O(?).
    我用 [优化解] 来写, 您看可以吗?

• 先暴力再优化: 哪怕 O(n²) 也比 0 提交强, 且通常面试官会接受。
• 不要硬想最优解: 5 分钟想不出来就先写暴力, 边写边想优化。
• 得到面试官 OK 再动手: 避免方向错了浪费时间。

Step 3 · 边写边讲（10-15 分钟）

让面试官跟上你的节奏:

你: 我先定义两个指针 left, right ...
   接下来用 while 循环 ...
   这里 if 条件是为了 [意图] ...
   注意这个 +1 / -1 是因为 [边界] ...

• 边写边讲意图, 不是读代码。
• 命名规范: 不要用 a, b, c, 用 left, right, count, freq_map。
• 变量名英文, 不要中文拼音。

Step 4 · 主动 dry run（2-3 分钟）

写完后不要等面试官说, 主动跑一组小用例:

你: 我用一个简单用例 dry run 一下 ——
   输入 [3, 1, 4, 1, 5], 期望输出 [4]
   第一步: ... 第二步: ... 结果 [4] ✓

• 能 90% 概率自己发现 bug, 比面试官指出来强。
• 面试官看到你「自带 debugger」会大幅加分。

Step 5 · 复杂度分析（30 秒）

你: 时间复杂度 O(n), 因为只遍历一次.
   空间复杂度 O(k), 哈希表最多存 k 个 key.

遇到不会的题

1. 不要沉默: 「这题我没见过, 让我想 1 分钟」>> 沉默 5 分钟。
2. 说出你的思考过程: 哪怕想错也比不说强, 面试官能给提示。
3. 主动求提示: 「我想到 X 方向, 不知道您觉得对不对?」
4. 写出退化解: 哪怕 O(n³) 也写出来, 比不交白卷强。

面试官常见提示信号

常见雷区

1. 不澄清就动手: 写错方向后撤回成本极高。
2. 边写边想: 写一半发现错了, 大量返工。
3. 变量名 a/b/c: 看起来像新手。
4. 不写注释: 复杂逻辑面试官读起来累。
5. 写完不验证: 等面试官指 bug 比自己发现失分多。
6. 不讲复杂度: 即便最后说错, 也比不说强。