Anthropic 软件工程师面试题汇总 | 84 道真实面经

💡 核心要点 (Key Takeaways)

• Anthropic 电面是 55 分钟纯编程题，官方明说「不靠背标准算法就能赢」，只允许 Python 标准库
• 高频题不是 LeetCode 原题，而是工程型问题：分布式 Mode/Median、图片处理、Model Downloader、Stack Trace 事件解析
• Design 轮的真实形式之一是 review 并改进一份有问题的 design doc，不是白板设计新系统
• Performance 岗位走 take-home：2 小时优化 mock 系统的 kernel 函数，允许用 AI
• AI Safety 是 culture 硬门槛：要能结合自身经历 argue for safety，信号不够会加面一轮 culture interview
• 流程末端还有 HM 轮和两道 Coworker Reference，背景与团队方向不匹配会在最后被拒
• 整体 bar 高，候选人反馈「bar 真的蛮高的」，Performance 轮会给你不少提示但仍然卡人

一、Anthropic SWE 面试流程 — 和传统大厂的不同

Anthropic 的 SWE 流程整体节奏快，但和 Meta、Google 这类传统大厂有三个明显区别。第一，电面是纯工程型编程：55 分钟，Google Meet 上进行，官方 prompt 原话是「a pure programming problem solving interview which doesn't benefit from memorizing standard algorithms or data structures」，只用 core Python（no ML or libraries needed），可以自己选语言。第二，Design 轮经常是 design doc review：不是给你一张白板设计新系统，而是 review 并改进一份已经存在问题的 design doc。第三，culture 有独立门槛：有候选人 VO 结束后被 recruiter 告知「culture 方面的 signal 不够强」，额外加面了一轮 culture interview，之后才进入 HM 轮。 一条完整的候选人路径大致是：Recruiter call →（部分岗位有 OA）→ 55 分钟电面 coding → take-home assignment → 5 轮 onsite →（可能的额外 culture 面）→ HM 轮 → Offer。注意 Anthropic 的雇佣流程要求两个 Coworker Reference，这是和其他大厂不同的环节，提前想好推荐人。 岗位差异值得注意：Performance Engineer 这类岗位没有店面、只有 take-home exam，工作内容是在 GPU、TPU、AWS Neuron 等加速芯片上做性能优化。不同岗位的流程形状不一样，收到 offer 流程前先问清自己的轮次结构。 整体体验上候选人反馈很一致：面试官友好、沟通效率高，「bar 真的蛮高的」——一位 Performance 候选人提到 Performance Round 拿了不少提示，其他轮次发挥不错，最终仍然在流程末端被拒。

• 电面 55 分钟：Google Meet + Python 标准库 + 工程型编程题
• Take-home：2 小时 kernel 优化，允许使用 AI 工具
• Onsite 常见 5 轮，design 轮可能是 design doc review
• Culture signal 不足会触发额外 culture interview
• HM 轮之后还有两道 Coworker Reference
• Performance Engineer 岗位无店面，仅 take-home

二、Coding 轮：高频题清单

汇总 2026 年候选人反馈的 SWE 岗位 coding 题目（含电面、onsite 与 OA），按出现频率和信号强度排序。整体特征是「题目都不是算法特别深奥，但是偏工程类型」——有候选人总结：面 AI 公司要把 concurrency 和 system design 复习好。 电面提示词最常见的方向是 concurrency（有候选人收到的电面提示词就是 concurrency），但因为这道题面过的人太多，Anthropic 已经在换题，近期出现过 LRU cache 和 file dedup 等替代题，所以这几个方向都要准备。

• Web Crawler — 电面经典提示词，近年换题频繁，仍是最常见方向
• Stack: get / put / min 全部 O(1) — 有候选人面试时忘了解法，现场重新推导后通过
• 分布式 Mode/Median — 10 个节点、send/recv/barrier，考迭代优化而非一次做对
• 图片批量处理 — 4 个 folder、6 种 transformation，大图片有 target time，考并行化
• Model Downloader — chunk + pipeline 下载，follow-up 是不用 coordinator 怎么做 recovery
• 1-1 Chat System — queue vs Pub/Sub，面试官反复追问怎么 scale
• Stack Trace / Generate Function Profiling Events — 带 timestamp 的 stack sample 转成 start/end event
• File Dedup、LRU Cache — 电面换题后的常见替代
• Tokenize — longest match 分词，考两个轮次优化
• OA 方向：lists / dictionaries / sets、sorting、hashing、binary search、bisect 与 collections

三、三道真题详解 — 考察点拆解

1. 分布式 Mode/Median（10 节点） 给 10 个 nodes，有 send / recv / barrier 三个函数，read data 花 10 bytes/sec，send / recv 各花 1 byte/sec，要求在这套通信模型上找 mode 或 median。这道题最关键的信号来自一位候选人的复盘：「面了才发现这题考查的不是正确性，而是端出了一个 workable solution 后，能不能持续 iterate 让 solution 变得更有效率」。这位候选人端出了 3 个 solutions，最后竟然是最 naive 的方案（每个节点算 local counter，聚合到 node 0）跑得最快，但显然 naive solution 不是最佳解，所以面试评价一般。应对方式：先 10 分钟内给出能跑通的第一版，之后每一轮迭代都要明确说出「这一版把哪个瓶颈降了、代价是什么」，最后主动讨论理论最优解（比如两阶段聚合减少跨节点传输量）。 2. 图片批量处理（4 folders × 6 transformations） 题目给 small images、big images、out、transformations 四个 folder，以及所有文件的完整 path（基本不用自己做 os path 处理）。要做的事：先用一个 Python 库（scikit-image 或 Pillow）处理 6 种 transformation——grayscale、flip horizontally、flip vertically 无参数，scale、blur、rotate 有参数；第一个考点是快速查 docs 确认库能力，面试时要展现你搜索和确认 library 的过程，建议事先熟悉其中至少一个库。然后先用 small images 做测试，把每个 json 配置里的多个 transformation 依次应用到每张图片并保存到 out folder。结果正确后进入大图片阶段，有一个 target time，需要并行化——一位候选人选了 ProcessPoolExecutor（图像处理吃 CPU 且进程间不需要共享内存），但时间不够没能在 target time 内 debug 完。高概率 follow-up 是 Python thread 和 process 的对比（GIL、IO bound vs CPU bound），要提前准备。 3. Model Downloader（chunk + pipeline） 设计一个模型下载器，核心方案是 chunk 切分 + pipeline 并发。一位候选人一开始用 coordinator 去 assign chunks 和做 recovery，follow-up 直接问如果不用 coordinator 怎么做 recovery——这是去中心化设计的经典追问（比如每个 worker 上报进度到共享存储、chunk 级别的幂等重试、心跳检测超时）。另外注意一个工程细节：当 chunk size 很小时，pipeline 和 tree 两种拓扑差别不大，能说出这个 trade-off 会加分。

• 分布式题的评分重点是迭代过程：workable v1 → 明确瓶颈 → 逐版优化 → 讨论理论最优
• 图片题第一考点是查 docs 确认库能力，第二考点是并行化 + thread vs process
• Model Downloader 的 follow-up 是去 coordinator 的 recovery 设计
• 所有工程题都要主动报复杂度、报瓶颈，不要等面试官追问

四、Design 轮：Design Review 与 System Metrics

Anthropic 的 design 轮有两种常见形态。 形态一：Design Doc Review。真实发生的形式是「review 并改进一个存在问题的 design doc」，有候选人猜测甚至可能是拿团队日常真实的 design doc 改改拿出来。这一轮考的不是你能不能画出一张漂亮的架构图，而是你能不能指出文档里的具体缺陷：容量估算缺失、单点故障、没有失败恢复路径、指标定义不清、扩展路径没讨论。准备方式：找 2-3 份公开的 design doc（公司内部文档、开源项目的 RFC 都可以），练习 30 分钟写出「缺陷清单 + 改进方案」。 形态二：System Metrics Design。官方 prompt 原文：「we will evaluate how you would scale, monitor and optimize an existing system in production. The focus will be on aspects of a ML driven system outside the model architecture itself」。注意两个限定：一是 existing system（不是从零设计），二是 model architecture 之外——也就是 serving、基础设施、监控这一层。Performance 岗位的这一轮会深入到性能指标定义：TTFT、端到端 latency 的中间步骤、GPU 的 Streaming Multiprocessor 和 AWS Neuron 的 NeuronCore 的底层设计思想异同、在 TPU / GPU / Neuron 之间怎么选、看哪些指标。有候选人还被追问了还在面哪些公司、offer package 大小和 timeline——metrics 轮会同时收集 comp 信息。 回答框架建议：先 clarify（规模、QPS、延迟目标）→ 现有系统的数据模型和 API → 核心数据流 → 瓶颈定位 → 监控与失败恢复 → 扩展路径。metrics 轮开头先花 2 分钟定义你要优化的指标，再谈优化手段。

• Design Doc Review：考找缺陷的能力，准备「缺陷清单 + 改进方案」的练习模板
• System Metrics：existing system + ML 驱动系统 + model architecture 之外
• Performance 岗位要懂 TTFT / 端到端 latency 拆解，以及 GPU（SM）/ TPU / Neuron（NeuronCore）的取舍
• 回答框架：clarify → 数据模型 → 核心流 → 瓶颈 → 监控与恢复 → 扩展

五、Take Home 怎么准备 — 2 小时 Kernel 优化

Take-home exam 是 2 小时，明确允许使用 AI。真实题目：「optimize 一个 mocked system 的 core kernel function」，本质和 GPU Kernel Optimization 很像——unrolling、memory coalescing、ops fusion 这些手段。一位候选人的结果是 6XX/1000 分、improve 大概 8.x 倍，拿到了 VO。 这个分数结构传递的信息是：不需要做到极致，需要做出可信的改进。600 多分 + 8 倍提升就能过线，说明评分看的是优化方法的正确性、profiling 证据和迭代记录，而不是最终倍数。准备要点： 第一，熟悉 profiling 工具链（Nsight、VTune 或 perf），能在 15 分钟内定位 kernel 的瓶颈（访存不合并、寄存器溢出、同步开销）。第二，把 unrolling / memory coalescing / ops fusion 三类优化的适用条件和典型收益背下来，能对着 profile 结果说出「为什么选这个手段」。第三，留 15 分钟写 results 记录：before/after 的耗时表格 + 每一步优化对应的 profile 证据。Performance Engineer 岗位的 take-home 就是这个形态，而且该岗位没有店面，take-home 基本是唯一的 technical 关卡——值得投入 2-3 个完整的 2 小时做模拟。

• 2 小时 + 允许 AI，题目是 mock 系统 core kernel 优化
• 参考线：6XX/1000 分、约 8x 提升即可通过 VO
• 评分看 profiling 证据和迭代记录，不是最终倍数
• 三类核心手段：unrolling、memory coalescing、ops fusion
• 最后 15 分钟固定留给 before/after 结果记录

六、Behavioral 与 Culture — AI Safety 是硬门槛

Anthropic 的 BQ 和一般大厂最大的区别是价值观问题不是客套，会追问到你能不能给出具体行动证据。 高频 culture 问题（真实出现过的问法）： - 「你认不认同 AI safety？从工程师和研究者的角度，实现 AI safety 的步骤是什么？」 - 「如果 Anthropic 做什么项目，因为不认同价值观，你会马上辞职吗？」 - 「你在 Anthropic 工作若干年后，你最骄傲和最后悔的工作都会是什么？」 - 「你工作中最不喜欢做什么事？」——follow-up 很 tricky：「如果我也不喜欢做这件事，让我想出一个理由说服我去做它」 - 「有没有做过什么 morally incorrect 的事？」 候选人总结的核心要求：重点要相信 AGI，并相信 Safety 很重要，更重要的是结合自身经历（工作上、非工作上）argue or fight for AI Safety。纯表态没有用，要能拿出「我为了 safety 和质量 push back 过一次」的具体故事，包括和 collaborator 在哲学问题（非技术问题）上的冲突以及怎么 resolve。 另一个被反复强调的文化信号是 humility：不喜欢「hero engineer」叙事，非常看重对风险的敬畏。讲 project 时多讲团队分工和你的 role，少讲个人英雄主义。 HM 轮的 BQ 相对常规：project go through、你在每个项目里的 role（not deep dive）。但要注意 HM 轮同时也是背景匹配检查——有候选人走完全流程在 HM 后被拒，复盘原因可能是「背景和 HM 当前团队的方向不完全匹配」，也可能是 culture 没达到预期。HR 首轮筛选则被描述为「经历过的最 technical 的 HR 首轮筛选」，30 分钟能聊成 50 分钟，不要当作走过场。

• AI Safety 要能结合自身经历 argue，纯表态会被追问穿
• 准备 2-3 个「为质量/safety push back」的具体冲突故事
• Humility 是文化信号：讲团队分工，避免 hero engineer 叙事
• Culture signal 不足 → 加面一轮 culture interview，再进 HM
• HM 轮兼做背景匹配检查，方向不匹配会在末端被拒

七、常见挂因复盘

从 2026 年 Anthropic SWE/Performance 候选人的失败案例里，可以归纳出四类高频挂因。 1. 末端被拒（最遗憾的类型）。走到 HM 轮之后才收到拒信。常见原因：背景和 HM 团队当前方向不匹配、culture 信号在累计过程中没有达到预期、前面某轮只是「过关」而不是「出彩」。启示：每一轮都要有明确的 signal 输出（一个讲透的 story、一个有深度的 trade-off 讨论），不要留到 HM 轮才补。 2. 工程题只做到「能跑」。分布式 Mode/Median 这类题，端出正确解只是及格线，「持续 iterate 让 solution 更高效」才是考察主体。拿到 v1 之后不主动迭代、等面试官提示的候选人，评价普遍偏低。 3. Culture 问题答不出具体证据。「morally incorrect 的事」「怎么说服我接受不喜欢的工作」这类问题答不上来，会直接削弱 culture signal——而 culture 不足会触发加面，加面仍然是风险点。 4. Take-home 时间管理。2 小时窗口里没留出结果记录时间，或者 profiling 环节耗时过长，导致优化迭代次数不够。参考线 6XX/1000 分说明「完成度」比「极致优化」重要。

• 末端被拒：每轮都要有明确 signal，不要指望 HM 轮翻盘
• 工程题 v1 之后必须主动迭代，报瓶颈、报收益
• Culture 问题要有具体行动证据，不能只有价值观表态
• Take-home 固定留 15 分钟写结果记录

八、4 周训练计划

按 Anthropic 实际流程的权重排优先级：coding 工程能力 > take-home > design review > culture 故事库。 Week 1 — 工程型 Coding 打底。每天 2 道工程型题（concurrency、pipeline、distributed basic patterns），用 Python 标准库完成。重点刷：stack 变体（O(1) get/put/min）、LRU cache、file dedup、web crawler。同时把 thread vs process、CPU bound vs IO bound、GIL 这三组概念整理成一页纸，面试能直接讲。 Week 2 — AI 公司专项 + 分布式迭代。每天 1 道分布式/系统型题（Model Downloader、分布式 Mode/Median 这类），强制自己练「v1 → 迭代 → 理论最优」的完整表达。补 LLM 基础设施常识：KV cache、batching、token streaming、prompt injection 防御——design 和 follow-up 都会碰到。 Week 3 — Design Review 与性能指标。找 2 份真实 design doc / RFC，各做一次 30 分钟「缺陷清单 + 改进方案」练习。背下 TTFT、prefill/decode、端到端 latency 的拆解方式；了解 GPU（SM）、TPU、Neuron（NeuronCore）的基本取舍逻辑。Performance 方向再加：profiling 工具实操一次。 Week 4 — Culture 故事库 + 模拟。写 3 个故事：为 quality/safety push back 的冲突、道德上不舒服但做了的决定、你如何 argue 一个非技术分歧。每个故事按「背景 → 冲突 → 我的具体行动 → 结果 → 现在回头看」展开。最后两天做 2 次完整模拟（55 分钟 coding + 30 分钟 design review），请人按 Anthropic 的风格追问。

• Week 1：工程型 coding + concurrency 概念一页纸
• Week 2：分布式迭代表达 + LLM 基础设施常识
• Week 3：design doc review 练习 + 性能指标拆解
• Week 4：3 个 culture 故事 + 2 次全流程模拟

九、如果时间紧迫

如果距面试不足两周，优先级排序是：先保电面（工程型 coding + 迭代表达），再保 take-home（完整做 1-2 次 kernel 优化模拟），culture 故事库压缩到 2 个最强的故事。Anthropic 的流程末端（culture 加面、HM、双 Reference）周期不短，时间紧的时候不要同时开太多公司流程，把 signal 集中在一两家上。 如果希望有人帮你按 Anthropic 的真实题型做一轮模拟（55 分钟工程型 coding + design review 追问 + culture 压力问），可以预约 30 分钟免费咨询，我们会评估你当前距离各轮 bar 的差距，再决定投入哪个环节。也可以看看我们针对 Anthropic 的完整备考指南： 相关文章：
Anthropic 面试备考指南 · Anthropic 机器学习工程师面试题汇总 | 147 道真实面经 · SWE 面试全解析 · 面试辅助服务

• 时间不足两周：电面 coding > take-home 模拟 > culture 故事
• 不要同时开太多流程，末端环节周期长
• 30 分钟免费咨询可评估你距离各轮 bar 的差距