第2351篇：AI工程师的面试复盘——那些让我印象深刻的好问题和坏问题
第2351篇：AI工程师的面试复盘——那些让我印象深刻的好问题和坏问题
适读人群：正在求职或即将求职的AI工程师 | 阅读时长：约12分钟 | 核心价值：从面试官和候选人双重视角，识别真正有价值的面试问题
去年我连续参加了七家公司的技术面试，同时自己也在公司面试了二十多个候选人。这种双重身份让我对"面试问题"有了一些不一样的认识。
有一家公司，面试官问我："请手写一个Transformer的注意力机制实现。"我当场写了，写完面试官说："很好，下一题。"整场面试像是在刷题，两个小时过去了，我对这家公司的业务几乎一无所知，他们对我的实际工程经验也了解甚少。最后我拒了这家的offer。
还有一家，面试官一开始就说："我看了你简历上的RAG项目，你说检索延迟从800ms降到120ms，能讲讲你当时的定位过程吗？是先猜的embedding耗时，还是先看的向量数据库查询？"这个问题一下子让我精神起来——因为他问的是过程，不是结果，这说明他真的做过这类工作，知道坑在哪里。
这两种问题的差别，就是我今天想聊的核心。
什么是"坏问题"——它暴露了什么
我见过的坏问题大概分几类。
第一类：纯记忆型问题
"说说BERT和GPT的区别。" "Attention is All You Need发表于哪一年？" "Transformer里的位置编码是什么公式？"
这类问题的问题不在于考了什么，而在于它考的是候选人有没有刷过某份资料。一个真正做过工程的人，不一定能背出公式，但他一定能告诉你在什么场景下用BERT会踩坑，用GPT会更适合。
我面试过一个候选人，他背公式背得滚瓜烂熟，但当我问他"你在生产环境里有没有遇到过embedding模型输出不稳定的情况"，他愣了。他没有做过生产环境的项目。
第二类：刁难型问题
"你说你用过LangChain，那你知道它内部的LCEL是怎么实现链式调用的吗？给我讲讲源码。"
我不反对深挖源码，但这种问题的问法有一个问题：它是在验证候选人对某个框架的了解深度，而不是他解决问题的能力。很多工程师用一个框架用得很熟，但不会去读源码——这不代表他工程能力差，这代表他把时间花在了更重要的地方。
这类问题背后，往往是面试官在用自己的知识盲区来筛人，而不是在评估候选人的实际价值。
第三类：假大空场景题
"如果让你设计一个支持10亿用户的AI推荐系统，你会怎么做？"
这类问题没有上下文，没有约束条件，没有业务目标，只有一个让人望而生畏的数字。候选人能做的只有背一遍教科书式的架构——分层缓存、消息队列、微服务拆分——说了等于没说。
我参加过一家公司，整场面试就是这种大而无当的设计题，一道接一道。面完我就知道，这家公司自己也不清楚自己要什么。
什么是"好问题"——它背后的逻辑
好问题有一个共同特征：它在还原真实工作场景。
好问题的三个维度
├── 验证真实经历（候选人有没有真的做过）
├── 考察思维过程（候选人遇到问题时怎么想）
└── 评估工程判断（候选人在取舍中如何决策）案例一：还原经历的好问题
"你简历上写了用LLM做文档摘要，生产上用的是什么模型？为什么选这个？当时有没有评估过其他的？"
这个问题能一眼分辨出候选人是真的做过还是简历水分。真做过的人，会告诉你：当时GPT-4太贵，用了Claude Haiku；做了一轮评估，Haiku在中文长文档上的摘要质量比Mistral好一些；后来业务量上来了又切回了本地部署的Qwen。这些细节是背不出来的。
案例二：考察思维的好问题
"你有没有遇到过RAG项目里，明明文档里有答案，但LLM就是回答不对的情况？你当时怎么排查的？"
这个问题有趣的地方是，它没有标准答案。候选人的回答会暴露他的排查框架：是先检查检索结果，还是先检查prompt构造，还是先看模型输出？有没有建立系统的评估集？有没有引入tracing工具？排查思路的清晰度，比知识点本身更能说明工程能力。
案例三：评估判断的好问题
"如果你的团队需要在两周内上线一个AI功能，但你发现模型效果比预期差20%，你会怎么决定？"
这是一道没有正确答案的决策题。面试官想看的是：候选人有没有业务意识？他知不知道"AI效果"和"业务目标"不是同一件事？他是不是那种会为了指标死扛而延期发布的人，还是能灵活权衡的人？
工程里的大多数决策不是"最优解"，而是"在约束下的合理选择"。能理解这一点的候选人，是真正做过工程的。
候选人应该问的好问题
面试不是单向考察，候选人问问题的质量同样说明问题。
我见过候选人在面试结束时问："请问咱们公司有没有期权？"——这是在错误的时间问错误的问题。
我也见过候选人问："你们现在的AI功能，主要的工程挑战是什么？是在模型评估，还是在数据管道，还是在部署稳定性上？"——这个问题让我当时愣了一下，然后我们聊了二十分钟。因为他问到了真实痛点。
以下是几个我认为非常好的候选人提问：
关于技术实践
- "你们的AI功能上线前有没有系统的评估流程？评估集是怎么构建的？"
- "你们的LLM调用是有统一的网关还是各业务自己对接？"
- "现在遇到最多的模型问题是幻觉还是延迟还是成本？"
关于团队状态
- "AI工程师在你们公司里，和算法团队、业务团队是什么协作关系？"
- "最近半年，有没有因为AI工程出过比较大的线上故障？当时是怎么处理的？"
这类问题一方面展示了候选人的专业深度，另一方面能获取真实信息，帮助自己做决策。
面试官的自我反思
我在复盘自己的面试官经历时，发现我也犯过一些错误。
有一次我问了一个候选人："你说你熟悉向量数据库，那Milvus和Weaviate在倒排索引实现上的区别是什么？"候选人回答不上来，我当时给了他一个低分。后来这个候选人被另一个团队录用了，做了半年，我听说他的工程能力相当不错。
我问的那个问题，其实考的是他有没有读过特定的技术文档，而不是他能不能做好工程。这是我的失误。
好的面试是一个信息充分的双向评估，而不是一场知识点默写比赛。面试官的任务是找到那个能在真实工作中创造价值的人，而不是找到那个背了最多资料的人。
一个实用的面试题框架
无论是面试官还是候选人，以下这个框架都有参考价值：
面试评估四象限
高相关性
↑
│
背书式问题 │ 经历验证类问题
（低价值） │ （高价值）
低工程 ───────────────────────────── 高工程
实践感 │ 实践感
理论推演类 │ 判断决策类问题
问题 │ （高价值）
│
↓
低相关性最有价值的面试时间，应该花在右上角和右下角——经历验证和判断决策。
小结
面试复盘这件事，我建议每一个工程师都养成习惯。不只是复盘自己有没有回答好，更要复盘：这家公司的面试问题，反映了他们什么样的工程文化？他们在乎什么，不在乎什么？
一家公司问的问题，就是一面镜子。
那些只会考记忆和刷题的公司，往往技术文化也比较封闭，工程师在里面很难真正成长。那些问你真实经历、挑战你的决策思维的公司，往往工程氛围更好，是值得加入的地方。
选公司，从面试问题开始。