刚结束 NVIDIA SDE 的全流程面试，从投递到最后一轮大概花了五周。整个过程给我最深的印象是——NVIDIA 不是在考你会不会刷题，而是在考你能不能在真实的性能和资源约束下做工程决策。NVIDIA interview questions 这和大多数互联网大厂的 SDE 面试差别很大。Google、Meta 会问”你能不能解决这个算法问题”，NVIDIA 问的是”你能不能讲清楚为什么选这个架构、瓶颈在哪、用什么工具验证、怎么优化”。
Recruiter Call（20-30 分钟）
这轮看起来像软性筛选，实际上已经开始考察深度了。
HR 问了我做过哪些系统和性能相关的项目、用什么语言、有没有分布式系统或并行计算的经验。我提到了之前做的一个推理优化项目，简单说了一下最后达到的吞吐量数字。
然后对方接了一句：”那 latency 当时卡在哪一层？是 compute bottleneck 还是 IO？有没有做过 batching 或者 async processing？”
这一刻我才意识到——他们默认候选人会接触 AI workload，而且会主动想到这些优化方向。如果我只会说”我优化了这个系统”而说不清楚”具体怎么优化、为什么能起作用”，这轮就已经掉分了。
这轮的关键：不要照着简历读，而是准备好对每个项目里的性能数字和技术取舍说得清清楚楚。同时要准备一句具体的”为什么 NVIDIA”——不是空泛的”我对 GPU 很感兴趣”，而是”我想在推理系统的批处理和显存优化上做得更深入”这样有针对性的回答。
Technical Screen（45-60 分钟）
这轮强度明显上来，也是我感觉最吃亏的一轮，因为准备不足。
Coding 部分
题目是”设计一个任务执行引擎，支持带依赖的任务并行执行”——有点像 Airflow 里 DAG 的调度逻辑。给定任务之间的依赖关系，要保证依赖的任务先执行、可以并行的任务尽量并行、同时不能让 worker 空闲。
我的做法是用 topological sort + 优先队列的思路，维护每个任务的入度，当入度变成 0 就丢进队列里，然后分配给 worker。代码本身不难，但面试官的追问才是真题：
- “假设数据量放大 10 倍、task 数从 100 变成 1000，这个设计还能扛吗？”
- “什么情况下 worker 会空闲？怎么最小化空闲？”
- “能不能改成无锁的？”
这些追问我都没有想得特别深。”放大 10 倍”这个假设很常见，但大多数候选人（包括我）通常只是说”复杂度是 O(V+E)，应该还好”，没有真的想过”如果 task 很多、依赖关系很复杂，调度本身成不成瓶颈”。
Project Deep Dive
然后面试官问我讲一讲之前做过的推理优化项目。我开始说的时候还挺顺的——”我们的 latency 是 X 毫秒、吞吐量是 Y”。但接下来对方追问：
“throughput 怎么测的？用了什么指标？”
我说用了并发请求数和 RPS。对方继续：”那有没有考虑 p99 延迟？有没有做过 profiling？”
这就扎心了。我能说出结果，但说不清楚”怎么发现的瓶颈、用什么工具验证、为什么选了这个方案而不是别的”。面试官接着问：
“cache miss 出现在哪里？” “显存占用怎么观测的？” “为什么不用 async queue？”
每一个问题我都能给出一个答案，但都不够深。那一刻我特别后悔没有在简历里把”perf 分析”、”profiling 工具”、”具体的瓶颈类型”这些写进去。
这轮最重要的准备：选 1-2 个项目，按”背景 → 怎么发现瓶颈 → 用什么工具 → 方案选择和 trade-off → 最终数据 → 如果重来会怎么做”这个框架讲。能讲到具体用过 perf、gprof、vtune 这样的工具，以及”cache miss 率从多少降到多少”这样的数据，会显得完全不一样。
VO四轮
投过来的 Team Match 反馈说是 inference 方向，所以我知道面试会偏 GPU 和系统。VO 背靠背四轮，每轮 50 分钟左右。
Round 1：Algorithms & Problem Solving
题目是”时钟指针最小夹角”。听起来简单，但面试官的要求是：讲清楚公式怎么来的，不能只写结论。
我先推导了分钟指针和小时指针的位置公式——分钟指针是 6 * minute 度，小时指针是 30 * hour + 0.5 * minute 度。然后算夹角。
但面试官问：”为什么是 6？为什么是 30？”
我才反应过来——他要的是你理解”一圈 360 度、60 分钟、所以每分钟 6 度”这个逻辑，而不是死记硬背公式。这个细节听起来小，但这就是 NVIDIA 和其他公司的区别——不是”能解题”，而是”能讲清楚为什么”。
写完代码以后他还追问了”能不能改成 online 版本，即给你一个实时的时刻流，返回最小夹角流”。这时候我意识到——NVIDIA 喜欢考察”实现质量和边界覆盖”。
Round 2：System Design（这轮是核心）
题目是”设计一个分布式推理服务，支持多租户、需要处理流量尖峰、要平衡延迟和吞吐”。
这和”设计 Twitter”或”设计短链”完全不一样。我的架构框架是：
User Request
↓
Request Queue (优先级队列，支持多租户隔离)
↓
Dynamic Batching (根据 batch size 或超时时间)
↓
GPU Memory Management (切分、优先级、驱逐策略)
↓
Model Server (多卡分布式推理)
↓
Response
然后面试官就开始往下挖：
- “什么时候队列会成为瓶颈？”
- “batch size 怎么选？太大延迟高、太小吞吐低，怎么平衡？”
- “显存不够怎么办？”
- “hot 模型和 cold 模型怎么加载？”
- “多卡怎么用 NCCL 通信？”
- “p99 延迟怎么控制？”
每个追问都需要你拿出具体的数字和 trade-off 理由。不能只说”用缓存解决”或”加 load balancer”，而要说”假设单个 batch 的推理时间是 50ms、显存占用是 2GB、我们的 GPU 显存是 16GB，那么最多支持 8 个 batch 并行，考虑到排队延迟和上下文切换开销，我们的动态 batching window 应该设成…”这样的粒度。
我在这一轮讲得最好的是”如何处理热门模型显存爆满”的问题。我说可以用优先级队列，把 SLA 更高的请求优先级提上来，对于 SLA 较低的请求可以选择等待或返回缓存结果。面试官对这个答案点了点头。
Round 3：Computer Systems / OS（这是拉开差距的一轮）
这是 NVIDIA 和大多数互联网厂差别最大的地方。问题涉及 process vs thread、虚拟内存、CPU cache、NUMA、锁与条件变量。
面试官问了一个场景：”假设你的推理服务跑在一个有多个 NUMA node 的服务器上，你发现某个 NUMA node 的延迟比其他的高 30%，可能是什么原因？怎么定位？”
这是一个典型的”系统基础+实战场景”的问题。答案涉及 NUMA locality、远程内存访问的延迟、CPU cache 的亲和性等。正确的思路是：
- 用
numactl查看当前进程绑定在哪个 node - 用
perf检查 cache miss 率 - 检查内存分配是否和任务 affinity 对齐
- 如果 thread 被调度到了别的 node，虽然逻辑上没错，但物理 latency 会很高
我当时答得不够好，只说到了”可能是 NUMA 的 remote access”，没有深入到”怎么用工具验证、怎么修复”。
后面他又问了”设计一个 OS scheduler，对于实时场景（比如自动驾驶）和通用场景，用 FIFO、Round Robin 还是 priority-based 比较合适”。我的答案是优先级抢占式（priority with preemption），但没有讲清楚”优先级反转”这个问题的具体场景和解决办法。
Round 4：Behavioral & Collaboration
这轮问题特别绑定在技术决策上，而不是空泛的”讲一个遇到困难时怎么合作”。
问题是：”讲一讲你做过最难的一次优化。不要只报百分比提升，要讲细节。”
我讲的是一个推理延迟优化的项目。原来 p99 延迟是 200ms，优化后降到 50ms。但面试官接着问：”你怎么知道瓶颈是什么？用了什么工具？”
我说用了 timeline profiling，发现 GPU 计算只占 30%，剩下的时间都在等待。进一步发现是因为 batch 里有些请求特别大，拖累了整个 batch 的完成时间。
“那你怎么解决的？”
我说改成了”dynamic batching with size-aware scheduling”，即小请求和大请求分开处理，这样可以让小请求不必等待大请求。结果 p99 从 200ms 降到了 50ms。
“成本是什么？”
这个追问我没有完全想清楚，但说了”代价是增加了调度逻辑的复杂度，需要维护多个队列”。他继续追问”那你怎么和团队说服他们接受这个方案？有没有数据支持？”
我说做了 A/B test，用实际流量验证了效果，同时监控了调度逻辑本身的开销（< 1%）。
这一轮的关键是：不要只报成果数字，要讲清楚发现问题、分析瓶颈、设计方案、验证效果的完整过程。
和其他大厂的差别
| 方面 | NVIDIA | Google / Meta |
|---|---|---|
| 算法难度 | Medium 为主，更看实现质量 | Hard 题比例高 |
| 项目深挖 | 到 profiling/瓶颈层 | 关注系统设计和规模 |
| System Design | GPU serving、调度、batching | 通用业务 SD 模板 |
| OS 考察 | 真考，结合场景 | 很少涉及 |
| 语言工程 | C++ 底层、内存、并发 | 语言无关 |
| 团队差异 | 极大，同”SDE”完全不同 | 相对一致 |
最关键的区别：NVIDIA 问的是”你能在什么约束下做工程决策”，而不是”你能不能想到聪明的算法”。
我的准备建议
项目口述
不要说”我优化了 X，提升了 Y%”。要准备：背景是什么、怎么发现瓶颈（用了什么工具）、为什么选这个方案（trade-off 是什么）、最终结果是多少、如果重来会怎么改。
Coding
图、堆、滑动窗口、并发题都要练。写完主动讲复杂度和边界。如果目标是 systems team，可以额外练”无锁队列”或”简单调度器”的思路。
System Design
以”GPU 推理服务 + 任务调度”为主线，补充 dynamic batching、显存管理、多租户隔离、监控和降级。千万别只会套”网关 + 缓存 + DB”的模板。
OS 基础
进程线程、虚拟内存、CPU cache、NUMA、锁与条件变量，这些都要能讲。最好准备一个”因为 cache miss 导致变慢”或”因为 NUMA remote access 导致延迟高”的具体例子。
Behavioral
准备 4-6 个技术向故事：大的优化、架构分歧、线上事故、跨团队协作、项目延期。每个都要能被追问两层细节。
最后的感受
NVIDIA 的面试风格和面试题本身不算特别难，拉开差距的是”你对自己做过的东西理解有多深”。如果你能讲到 profiling 工具、具体的瓶颈类型、为什么那样选择而不是别的，面试官会对你的印象完全不一样。
不同团队风格差异很大。我的 inference team 面试特别看系统设计和性能优化，但听说有的 autonomous 团队更看 embedded systems 和实时约束，driver team 更看底层 C++ 和硬件理解。投之前一定要搞清楚目标组在做什么。
如果你最近也在准备 NVIDIA 或其他北美科技公司的技术岗位面试，除了刷题之外，提前了解真实的面试流程和不同公司的考察重点其实也很重要。
InterviewShow 主要整理技术求职和面试相关的内容，从 OA、Coding Interview，到 System Design、Virtual Onsite 等不同阶段都有涉及。
祝顺利拿到 offer。