技术面试会做但讲不顺？总结了10种英文表达模板，附回答骨架

最近开始面试，发现一个很气的事情：有些题自己写明明会，一开始用英语讲，连会的东西都能讲错。脑子里想的是一个意思，嘴里出来已经是另一个意思了，越着急越解释不清……
痛定思痛，决定从软实力入手，补一补英语口语和面试表达。和一起找工作的小伙伴练了挺久，总结出下面这些常用的回答骨架。个人感觉实战有帮助，面试通过率也有提升，不过也不能把功劳全算在口语上。
准备的时候翻了地里的老帖，也看了一些中文的个人求职、远程工作总结，链接放在最后。这篇主要整理 coding 和 system design 里容易卡壳的场景，英文例句是按场景写的练习示例。
1. 先确认题意，别急着证明自己会
“So we're given …, and we need to return …. Is that correct?”
比如 two sum：
“So we're given an array of integers and a target. We need to return the indices of two distinct elements that add up to the target. Is that correct?”
不用把题目逐字念一遍，抓住输入、输出和关键限制就行。尤其是返回 index 还是 value，同一个元素能不能用两次，这些先说清楚，后面少返工。
2. 问限制的时候，把两种情况说出来
“Can I assume …, or should the solution also handle …?”
比如：
“Can I assume the input is sorted, or should the solution also handle unsorted input?”
直接说 “Any constraints?” 有点太空了。问具体一点，对方更好回答，自己也能顺着往下想。
不用背一长串问题挨个问，挑会改变解法的：有没有重复值、能不能改原数组、数据大概多大。
3. 想到朴素解法，就先交代清楚
“A straightforward approach would be …. That would take …. We could improve it by ….”
比如：
“A straightforward approach would be to check every pair. That would take O(n squared) time. We could improve it by storing the values we've already seen.”
先有一个双方都理解的起点，再讲优化，通常比突然蹦出一个算法名字好跟。
当然，已经有清晰的最优解就直接讲，不用为了套模板故意绕路。
4. 别只报数据结构名字，要说它帮你解决什么
“I'd use … because we need to …. The trade-off is ….”
比如：
“I'd use a hash map because we need to look up previously seen values quickly. The trade-off is the extra memory.”
“I'll use a hash map” 只是告诉对方你选了什么。加上后面两句，对方才知道你为什么选，以及有没有考虑代价。
这句也很好迁移到缓存、队列、数据库选型。
5. 复杂度别只报答案，补一句怎么算出来的
“We process each … once. Each … takes … on average, so the total is ….”
比如：
“We process each element once. Each hash map lookup and insertion takes constant time on average, so the expected running time is O(n). The map uses O(n) extra space.”
O(n) 可以念 “big O of n”，O(n²) 念 “big O of n squared”。
注意这里的 on average，哈希表操作不是所有情况下都保证常数时间。多说一句推导，也更容易发现自己是不是漏算了排序、复制或者递归栈。
6. 卡住的时候，说清楚卡在哪里
“I have … figured out. What I'm still working out is ….”
或者：
“Let me take a moment to check whether ….”
比如：
“I have the basic approach figured out. What I'm still working out is how to handle duplicates without returning the same index twice.”
比一直重复 “Let me think” 更有信息量。对方知道你已经走到哪一步，也更容易给有用的提示。
不用为了避免沉默，一边想一边把所有零碎念头都倒出来。先说自己要检查什么，再安静想一下就行。
7. 发现 bug，按“问题—影响—修复”讲
“I missed …. That means …. I'll fix it by …, then test ….”
比如：
“I missed the empty-input case. That means this line could access an element that doesn't exist. I'll add a guard clause, then test both empty and single-element inputs.”
发现错误的时候容易开始疯狂 sorry。其实把错误定位清楚、改对、补测试，比反复道歉有用。
这里还能顺便展示你怎么 debug。
8. 收到提示，讲出它怎么改变你的思路
“That helps. If we …, then we can …. Let me check that with an example.”
比如：
“That helps. If we store the values we've already seen, we can look up the complement instead of scanning the array again. Let me check that with a small example.”
不要只说 “Oh yes, I know”，然后突然开始敲代码。把提示和新方案之间的关系补出来，对方才知道你确实理解了。
9. 不熟悉的东西，把知道和不确定的部分分开
“I haven't used … directly. My understanding is …. I'd want to verify ….”
比如：
“I haven't used this database directly. My understanding is that it supports transactions, but I'd want to verify its isolation guarantees before relying on it here.”
这句话的前提是，后面那部分你确实有了解。完全不知道就直接承认，再说你会怎么查证。
尤其 system design，很容易为了让回答听起来完整，把自己也没把握的细节越说越实。
10. 讲取舍，把“什么情况下我会改主意”也带上
“Given …, I'd choose … because …. If … changed, I'd reconsider ….”
比如：
“Given the need for multi-row transactions and the current scale, I'd start with a relational database. If write throughput became a bottleneck, I'd revisit the partitioning strategy.”
单独说 “it depends” 没什么用，后面要接 depends on what。
当前需求是什么、为什么现在这样选、哪个条件变化后需要重看方案，这三个点讲出来，回答就具体很多。
最后，把它们串起来，其实就是一个很普通的骨架：
“So the goal is …
Before I start, can I clarify …?
My initial approach is … because …
The main trade-off is …
Let me walk through an example.
I'll implement it now.
To check correctness, I'd test …
. 1point3acresThe time complexity is …, and the extra space is ….”
不用每道题都完整念一遍，挑当下需要的部分就行。
练习的时候也可以省点事：拿一道已经会的题，先不写代码，只用英语讲两分钟，让小伙伴复述一下他听到的解法。对方复述不出来的地方，就是值得回头检查的地方。是逻辑跳步了，还是代词太多，还是自己其实也没想明白？
还有一点个人感受。coding agent 盛行以后，会不会把代码做出来，好像已经没以前那么能拉开差距了。反而是能不能说清楚为什么这样做、哪里可能错、怎么验证，越来越能看出一个人的理解深度。
所以现在觉得，“会不会说”正在成为区分人和人之间实力的一个重要标准。基础当然还是要会，但自己的判断如果一直停在脑子里，别人真的没办法替你看见。
文末也放了上一篇 AI 公司面试练习题的链接。准备 RE/MLE 的朋友，可以从里面挑一道 attention、KV cache 或 sampling，试着套上面的骨架讲一遍。题会做之后，再检查一下自己能不能把 shape、边界情况和取舍说清楚。
希望对同样“脑子会了、嘴还没会”的朋友有用。有帮助的话求点米，也欢迎补充自己面试时觉得好用的表达～
参考和延伸阅读：
[1] 地里一篇挺值得翻的老帖：聊聊技术面试中的沟通和交流。里面讲到留意对方反馈、准确描述卡点，以及给出不同方案的利弊。很有启发的一点是：面试交流要有来有回，别变成自己一个人讲课。
[2] 地里的口语讨论帖：New Grad即将入职，如何提高口语沟通水平。链接是第4页回帖，有人分享听播客时积累“怎么描述一件事、怎么回应问题”的表达，减少开口时临时造句的负担。
[3] 个人整理的中文资源库：程序员海外工作/英文面试手册。覆盖海外求职和英文面试准备，适合当目录查漏补缺，不用一口气从头刷到底。
[4] 一篇从实际远程工作出发的个人分享：一些个人为美国公司远程工作的经验分享——英语部分（转载存档）。讨论了读技术资料、听会议、解释项目经历和澄清需求这些具体场景。比笼统地给自己定一个“提高英语”的目标更容易下手。
[5] 我上一篇：整理了25道AI公司面试练习题，偏RE/MLE，附免费资料。这篇练怎么讲，那篇可以拿来挑题，两篇配合着用。

补充内容 (2026-09-29 01:53 +08:00):
. ----如果发现内容对你有用，麻烦给我加点米，祝大家都早日拿到理想的offer

收藏

收藏