- Authors
- Name
- Youngju Kim
- @fjvbn20031
引言 — 面试是与实力不同的技能
有实力却在面试中屡屡败北的人存在，实力平平却能顺利通过面试的人也存在。看起来不公平，但这背后有结构性的原因。面试是衡量实力的不完美代理，而这个代理本身就是一项可以练习的技能。
本文讨论如何在面试现场证明第1篇中描绘的岗位知识地图。内容围绕面试的四种类型 — 编程、系统设计、领域深挖、行为面试 — 各自的评价信号与准备方法、各岗位的常见问题，以及8周倒推计划展开。
面试官到底在看什么
在讲准备方法之前，得先理解评分者的评分标准。面试官收集的不是答案是否正确，而是信号（signal）。
- 解决问题的过程：如何把一个模糊的问题结构化。是否会提出确认需求的问题。
- 沟通：是否会把想法说出来（think aloud）。卡壳时是保持沉默，还是分享当前状态。
- 权衡取舍的意识：是否会说出类似"这个方法更快，但会占用更多内存"这样的句子。
- 协作的可能性：得到提示时，是变得有防御性，还是能吸收采纳。
只要换一个这样的视角，准备的方向就会改变。目标不是背下完美的答案，而是养成持续发出好信号的习惯。
编程面试 — 学的不是题目，而是模式
编程面试准备中最常见的错误，是刷几百道题。题目是无限的，但模式是有限的 — 高频模式大致不超过十五个。
- 双指针 / 滑动窗口 — 数组、字符串的区间问题
- 哈希表 — 频率、去重、两数之和系列
- BFS/DFS — 图、树的遍历，岛屿数量系列
- 二分查找 — 有序空间中的查找，"最小化最大值"系列
- 堆 — 前K个、流式中位数
- 动态规划 — 定义子问题是关键（背包、最长子序列）
- 栈 — 括号匹配、单调栈
- 回溯 — 排列组合的生成
高效的学习顺序是这样的：①选定一个模式 ②解该模式的3~5道代表题 ③每解完一题，就把"这道题的什么特征在呼唤这个模式"用语言表达出来。这种语言化，会在面试现场转化为一个强有力的信号 — "我想到滑动窗口，是因为这是一个连续区间上的优化问题"。
练习时必须遵守两件事。掐表计时（实战是20~35分钟），并且一边说出来一边解题。安静地解题的能力和边说边解题的能力，是不同的肌肉。复杂度分析（时间、空间）不要等代码写完才说，养成在讲解思路时就先说出来的习惯。
系统设计面试 — 5步框架
在"设计一个URL缩短服务"这类问题前僵住，往往不是因为知识不足，而是因为缺少推进的顺序。以下这个5步框架是标准做法。
- 明确需求（5分钟） — 把功能需求（做什么）和非功能需求（规模、延迟、可用性）分开来问。"读多还是写多？"几乎总是一个好问题。
- 粗略估算（5分钟） — 把日活用户、QPS、存储量估算到数量级。目的不是精确的数字，而是得出"这个规模下单一数据库撑不住"这样的判断。
- API与数据模型（5分钟） — 勾勒三四个核心接口和表/键的结构。
- 高层设计（10~15分钟） — 画出客户端 → 负载均衡器 → 服务 → 存储的大图，并说明每个箭头上发生了什么。
- 深挖与权衡（10~15分钟） — 深入面试官戳的那个点（瓶颈、故障、扩展）。缓存失效、分片键的选择、一致性级别是常见主题。
这里拉开差距的不是知识的罗列，而是权衡取舍的语言。要练习"加缓存能降低读延迟，但会带来失效的复杂性；这个服务读远多于写，所以这个代价值得付"这样的说法 — 每个选择都要点明代价，并用需求来证明其合理性。重试与幂等性这类分布式系统的常见主题，本博客的支付幂等性一文是不错的预习材料。
各岗位的常见问题
以第1篇的五个岗位为基准，整理了领域深挖面试的常见问题。
AI/LLM工程师
- RAG和微调分别在什么情况下选择？（依据知识更新频率、成本、数据量）
- 生产环境中如何降低幻觉（hallucination）？（强制给出依据、引用、评估集）
- 如何对LLM功能的质量做回归测试？
平台/DevOps/SRE
- 部署后p99延迟飙升。如何诊断？（回滚判断 → 指标 → 追踪的思考顺序）
- Pod处于CrashLoopBackOff状态。最先执行的三条命令是什么？（
kubectl describe、logs --previous、检查事件） - 如何设定SLO，错误预算耗尽后要做什么？
安全工程师
- JWT该存在哪里，为什么？（比较localStorage与cookie的攻击面）
- OAuth 2.0的authorization code流程为什么需要PKCE？
- 画出登录功能的威胁模型。（撞库攻击、会话固定、枚举攻击）
数据工程师
- 大规模join很慢。攻克顺序是什么？（执行计划 → 分区/分桶 → 广播join的判断）
- 流式聚合中如何处理迟到的事件？（水位线、允许的迟到窗口）
- 如何设计幂等的回填（backfill）？
前端
- 在浏览器中输入URL后会发生什么？（可以调节深度的万能问题）
- 如何诊断并改善LCP不佳的页面？
- 如何在React中找出并减少不必要的重渲染？
比起死记硬背每个问题的答案，用这个网站的工具 — Kubernetes 演练场、SQL 演练场、认证与安全实验室、Linux 命令测验 — 亲自动手实验，把它们变成"亲身经历过的故事"，会有力得多。
行为面试 — STAR与故事库
即兴应对行为面试（behavioral interview），就像第一次见到编程题就要当场解出来一样。需要准备的是故事库。
STAR结构 — 用情境（Situation）、任务（Task）、行动（Action）、结果（Result）来组织故事。两个常见的错误：情境说明超过一半的时间（应在30秒内讲完），以及行动的主语是"我们"（面试官想知道的是你做了什么）。
准备六个故事 — ①解决过的一个困难技术问题 ②与同事发生意见冲突的经历 ③失败或犯错的经历 ④主动改善了某件事的经历 ⑤在截止日期压力下做优先级决策的经历 ⑥说服失败但有所收获的经历。给每个故事配上数字（延迟降低40%，值班警报从每周30件降到5件），可信度会大幅提升。
在意见冲突的故事中，面试官关注的不是输赢，而是把自我和想法分开的能力 — 这个主题在大多数争论争的不是想法，而是自我一文中有深入探讨。比起"我是对的，最终我说服了大家"，"我理解了对方的制约条件，一起找到了第三个方案"才是资深的信号。
8周倒推计划
从面试日倒推的标准计划。以每周10小时为基准，请根据情况伸缩调整。
- 第8~7周：核查目标岗位的知识地图，补上有缺口的基础。修改简历，让STAR素材显现出来。
- 第6~5周：编程模式集中期 — 每天1~2道题，按模式练习。用3道题演练系统设计框架。
- 第4~3周：岗位深挖问题 + 撰写故事库。至少进行2次模拟面试（同事或AI面试官 — 第3篇介绍了提示词）。
- 第2周：只重复薄弱模式。研究目标公司的技术博客和架构（作为反问的素材）。
- 第1周：禁止做新题，只复习。调整睡眠节律 — 正如记忆力的秘密所示，睡眠是巩固记忆的时间。
- 面试当天：早上用一道轻松的题热身。为每场面试结束时的反问准备2~3个问题（"这个团队的值班是什么样的？"在哪里都适用）。
落选之后
最后是最重要的一点。面试落选不是对实力的判定，而是一次抽样。同样的实力，也会因为题目运气、面试官风格、当天的状态而结果不同。落选之后要做的只有三件事 — 立刻记下还记得的问题，把卡壳的地方反馈进故事库和模式清单，然后继续投递下一份申请。正如自信从何而来一文所说，自信来自尝试的积累。面试也正是如此。