Harvey SWE / Frontend Coding 面经

💡 核心要点 (Key Takeaways)

• Harvey 的 Phone 面是一道多 part coding：Part 1 基础实现 + Part 2 错误处理 / 约束升级，公开评分口径是「不要求最优，只要 working code」——先把 Part 1 跑对，再留 20 分钟以上给 Part 2 和 corner case。
• 题库换新快：2026 年数周内公开信号先后出现 spreadsheet 旧题、句子高亮、内存文件目录（Vault）新题，旧题单会快速过期；准备按题型练（多 part 小系统、字符串处理、RAG 实现），不要按题单背。
• Onsite 主线是三轮：System Design（AI 产品向：按规则打分 / review agent，含多 agent 并行冲突追问）+ 项目 deep dive（考决策过程，「为什么时间紧」类追问高频）+ Coding（轻量 embedding / RAG 实现，收尾问 eval 优化 recall / hit rate）。
• AI 味 follow-up 是区分点：RAG / eval（recall / hit rate 怎么优化）和前端「launch to production 能改什么」是高频 follow-up，要准备成固定话术——指标能报数、改法能列 2-3 条、取舍能讲清。
• 反馈快是 Harvey 流程的显著特征：公开信号有 phone 当晚通知过、onsite 1 小时内到 1 天内出结果，整体 2-4 周常见，日程留空并主动跟 recruiter 推进（有 onsite 到场等不到面试官的公开信号，日程提前确认）。

这篇适合谁

这篇写给准备 Harvey（AI 法律科技，AI Legal）SWE / Frontend（AI 产品工程）岗位 2026 年面试的候选人，级别以社招为主（公开信号里在职跳槽为主线，应届也可参考），覆盖 recruiter screen、Phone（phone screen）、Onsite / superday 和 HM / offer 各轮结构。文章基于 2026 年公开面经信号（一亩三分地等社区）整理，各团队、地区、级别的轮次结构会有出入，以实际收到的邀请为准。

一句话定位：Harvey SWE / Frontend = 多 part Coding（phone 一道：基础实现 + 错误处理 follow-up）+ AI 产品 System Design（规则打分 / review agent）+ 轻量 RAG / embedding 实现（带 eval 优化 follow-up）+ 项目深挖 BQ。这四根轴决定整场面试的下限，和泛大厂 SWE 最大的区别是：评分强调 working code 优先于最优解，且题库换新快——旧题单会快速过期。

如果同时投其他 AI 公司：通用的 AI 味 coding 与 SD 准备方法可参照 OpenAI AI Infra 面经 2026 和 xAI SWE / AI Infra 面经 2026；本篇只覆盖 Harvey 岗位特有的信号。

• 适合准备 Harvey SWE / Frontend 岗位 2026 年面试的社招候选人（在职跳槽为主线），应届与 AI 法律 / RAG 产品方向求职者也可参考
• 四主轴：多 part Coding + AI 产品 System Design（规则打分 / review agent）+ 轻量 RAG / embedding（带 eval follow-up）+ 项目深挖 BQ
• 评分特征：working code 优先于最优解；题库换新快，准备按题型而不是按题单
• 反馈快：公开信号有 phone 当晚通知、onsite 1 小时内到 1 天内出结果，整体 2-4 周常见，以实际为准

面试流程：Phone / Onsite / HM 各轮是什么

按 2026 年公开面经信号，Harvey 的流程主线是：投递 / 内推 → recruiter screen → Phone（phone screen，一道 coding）→ Onsite / superday（公开信号为三轮）→ HM → offer。反馈速度快是 Harvey 流程的显著特征——公开信号里有 phone 当晚通知过、onsite 1 小时内到 1 天内出结果的案例。各轮侧重点：

• Recruiter Screen（30 分钟，不考技术）：聊动机、背景、级别、工作地点和「为什么 Harvey」。Harvey 的方向是 AI 法律（法律文档问答、引用、审查自动化），这轮能说清「我想做法律场景的文档 / 检索 / agent 产品」，会直接影响后面的团队匹配方向。
• Phone / Phone Screen（45-60 分钟，一道多 part coding）：在线编码环境（社区俗称「店面」），一道题分两部分：Part 1 基础实现，Part 2 错误处理 / 约束升级。公开信号的评分口径是「不要求最优，只要求 working code」——先把 Part 1 跑通跑对，再花时间做 Part 2。2026 年当前新题是内存文件目录系统（Vault）和句子高亮；旧题库包括 spreadsheet 操作和 RAG 引文检索（citation）。题库换新快，不要按旧题单准备。
• Onsite / superday（公开信号三轮，每轮约 60 分钟，通常一天面完）：Round 1 System Design（AI 产品向，不是通用大规模 web 系统）：设计一个按规则给文档打分的 review agent，输出合格 / 可接受 / 不合格并给出修改建议，高频追问是「多个 agent 并行时如何避免冲突」；Round 2 项目 deep dive：讲一个项目，追问决策过程（「为什么这个项目时间会紧」类问题在公开信号里出现）；Round 3 Coding：在云端 notebook（Google Colab 类环境）实现一个轻量 embedding / RAG，收尾追问 eval 优化（recall / hit rate 怎么提升）。
• HM / offer：公开信号对这轮细节较少，通常确认方向、级别、comp 后发 offer，不再考技术。公开信号有 onsite 到场后面试官缺席、在会议室等待的案例——日程有任何异常主动找 recruiter 确认，不要干等。
• 轮次结构因团队、级别、地区而异，以实际收到的邀请为准；部分岗位可能多一轮或调整轮次顺序。

题型雷达：Coding、System Design、RAG / ML、BQ 各占多少

按公开信号的出现频率给题型排个雷达，最能区分 Harvey 候选人的三根轴是多 part Coding（含 AI 味 RAG 实现）、AI 产品 System Design 和项目深挖：

• 多 part Coding（最高频：phone 1 轮 + onsite 1 轮）：两段式题是 Harvey 的标志性题型——Part 1 基础功能（文件目录、高亮、RAG 检索），Part 2 错误处理 / 约束升级（重名处理、边界 case、eval 优化）。评分看「先可运行，再谈演进」，每个 part 说清改了什么、边界怎么处理。
• System Design（onsite 1 轮，AI 产品向）：高频场景是规则打分 / review agent（文档评分、修改建议生成、并行冲突），不是高并发 web 系统。考点：先定义「什么算合格」（规则与输出格式），再简化（单 agent / 单 writer），再扩展（并行、冲突、评估），最后讲怎么衡量 agent 输出质量。
• RAG / ML 味（coding 内 follow-up，无独立 ML 轮）：轻量 embedding / RAG 实现 + eval 优化（recall / hit rate 怎么定义、怎么提升）。考点是能不能报出指标并给出 2-3 个具体改法（chunking、rerank、eval 集），不是模型原理。
• 项目深挖 / BQ（onsite 1 轮 + 穿插）：项目讲述以「决策过程」为核心——为什么这个方案、为什么时间紧、放弃了什么。公开信号里「为什么这个项目时间会紧」类追问是 Harvey 特色。准备 4-6 个 STAR 故事，每个有 measurable impact 且能接两层追问。
• 前端向（Frontend 岗位）：两道 coding 子问（组件 / 逻辑实现）+「假设要把这个 app launch to production，有什么可以改进」的 follow-up——React 性能（memo / lazy / code splitting）、状态管理、a11y、构建与部署，这个清单就是考点。
• SQL（低频 / 缺失）：公开信号没有独立 SQL 轮，不用单独堆。

高频题目：7 个代表题型和考点

以下是 2026 年公开面经信号里反复出现的题「类型」，只归纳题型和考点，不复刻任何候选人的具体原题：

• 内存文件目录系统（Vault）（2026 当前 phone 新题，最高频）：实现 add_file(path) / get_files(path) 两段式，Part 2 处理重名（在扩展名前加副本后缀）。考点：路径解析与归一化、树 / map 结构选型、get_files 的边界（文件 / 目录 / 空路径）、重名后缀规则、Part 2 的 corner case（已有副本名再重名怎么递增）。
• 句子高亮（2026 phone 新题）：给定句子和一组匹配短语，输出高亮后的字符串。考点：多 substring 匹配（含重叠与重复）、输出格式（HTML 标签 / markdown）、边界（短语不存在、相邻匹配）、复杂度说明。
• Spreadsheet 操作（旧题库，可能复现）：表格 / 网格操作类题。公开信号显示有候选人「只备了这类型题」结果被新题命中——旧题型仍值得用来练多 part 节奏，但别当唯一准备线。
• RAG 引文检索（citation）（旧 phone 题）：文档切块 + 查询，输出答案和引用来源。公开信号显示这道题以「working code」通过并当晚收到通知——Harvey 的 coding 评分确实偏完成度，但 Part 2 追问（检索不到怎么办、引用错了怎么办）仍要接住。
• 前端 coding + production follow-up（Frontend 岗位）：两道 coding 子问（组件 / 交互逻辑实现），follow-up 是「假设 launch to production，有什么可以改进」。考点：bundle 与 code splitting、memo / lazy、状态管理选型、a11y、错误边界、构建 / 部署 / 监控——能列 3-5 个具体项并讲取舍。
• Onsite SD：规则打分 / review agent：设计一个按规则给文档打分（合格 / 可接受 / 不合格）并给修改建议的 agent。考点：输出契约定义（状态 + 建议的格式）、先简化到单 agent / 单 writer 再讨论并行冲突（锁 / 队列 / 单写者）、agent 输出质量怎么评估（golden set、human eval、一致性）。
• Onsite Coding：轻量 RAG / embedding + eval：在云端 notebook（Google Colab 类环境）实现一个最小可用的 embedding / RAG pipeline。考点：数据加载 → 切块 → 向量化 → 检索 → 生成，先跑通；收尾 follow-up 是 eval 优化——recall / hit rate 的定义、eval 集怎么建、改法（chunk 大小、embedding 模型、rerank、query rewrite）。

公开面经信号怎么读

一亩三分地等社区是 Harvey 面试信息最集中的公开来源，但 Harvey 的公开信号量比大厂小，而且 2026 年有一个突出特征：题库换新快——数周内多篇独立帖子先后出现 spreadsheet 旧题、句子高亮、内存文件目录（Vault）新题，说明旧题单会快速过期。读法比内容更重要，几个原则：

先区分岗位，再读轮次结构。按题目内容而不是标题判断：帖子里出现文件系统、高亮、RAG、打分 agent 的，是 SWE 信号；出现两道子问 + production follow-up 的，是 Frontend 信号。再按「年份 + 轮次」筛选，只看最近半年的帖子——题库和轮次本身在变，旧帖的题单会误导你。

找共识，不信个例。多篇独立帖子都提到「phone 一道多 part coding、working code 就够」「onsite 三轮（SD / deep dive / coding + eval follow-up）」「反馈快」，这个结构才可信。单篇面经的轮次数量和题目难度不能当结论；面经作者有幸存者偏差（过的人爱写，挂的人少写），整体难度感知会偏乐观。

提取「轮次结构 + 题型方向 + 挂点」，忽略剧情。每篇面经真正有用的信息密度就这三样：每轮考什么类型、follow-up 追问到多深、作者觉得过 / 挂在哪。情绪细节、对面试官的评价、等待体验不需要带进准备（但「onsite 到场等不到面试官」这类信息值得用来提醒自己提前和 recruiter 确认日程）。

不搬运、不暗示合作。本站所有 Harvey 面经内容都只归纳公开信号，不复制任何候选人的逐字面经，也不代表与一亩三分地或任何面经社区有合作或转载关系。你读到的公开帖子请以原作者发布的内容为准。

常见挂点：Harvey 独有的失分方式

把公开面经里的挂因和模拟面试复盘对照，Harvey 特有的失分点集中在这几个：

• 只备旧题库：公开信号里有「之前一直准备 spreadsheet 的题，结果碰到新题」的案例——Harvey 题库换新比多数公司快，按旧题单准备是最大的挂因。准备按题型走（多 part 小系统、字符串处理、RAG 实现），不按题单背。
• Part 2 错误处理缺失：多 part 题的 Part 2（重名后缀、边界 case）才是区分点，只把 Part 1 跑通等于只做了一半。时间分配建议：Part 1 控制在 25 分钟内，留 20 分钟以上给 Part 2 和 corner case。
• SD 绕路：公开挂经里卡在「多个 agent 并行如何避免冲突」的追问上讨论很久没收敛——其实可以先简化到单 agent / 单 writer 的方案再扩展。SD 的核心是「先简化再扩展」，别被一个子问带偏整轮节奏。
• 项目深挖答不出决策过程：「为什么这个项目时间会紧」这类追问，答成只报结果和时间线、没有取舍与反思，直接失分。每个主项目准备三层答案（概述 → 规模与取舍 → 反思）。
• RAG 的 eval 只会讲 accuracy：收尾追问是「如何优化 eval，比如 recall / hit rate」，报不出指标定义、给不出 2-3 个改法（chunking、rerank、eval 集），就接不住最后一问。
• 前端 production follow-up 答泛泛：「launch to production 能改什么」只答「写更多单测」是泛泛——需要 React 性能 / 状态 / a11y / 构建部署的具体清单和取舍，至少 3-5 个能展开的项。
• 流程与日程被动：公开信号有 onsite 到场后面试官缺席（在会议室等 5 分钟、开 zoom 发现人不在）的案例。日程有异常提前和 recruiter 确认，不要干等；Harvey 的快流程奖励主动推进的候选人。

准备路线：7 天 / 14 天 / 30 天

按你距 Phone / Onsite 的天数选路线。三个版本的共同原则：多 part「可运行 → corner case」的节奏是基本盘，AI 味 follow-up（RAG / eval / production）是区分点，项目深挖三层话术保下限，最后一天只留缓冲和状态调整，不学新东西。

• 7 天（保下限版）：D1 多 part coding 模板：1 道文件目录系统题 + 1 道字符串处理题（高亮类），练「Part 1 25 分钟内可运行 → Part 2 corner case 20 分钟」的节奏，记录时间分配；D2 AI 味 coding：1 道轻量 RAG / 引文检索实现，eval 指标（recall / hit rate 定义 + 2-3 个改法）整理成 2 分钟话术；D3 SD 叙事：规则打分 / review agent，按「定义输出契约 → 单 agent 简化 → 扩展到并行冲突 → 评估方法」讲完整流程，录音回听；D4 项目深挖：2 个主项目各写三层答案（概述 2 分钟 → 规模与取舍 5 分钟 → 反思 3 分钟），预答「为什么时间紧」类追问；D5 前端候选人：production readiness 清单（bundle / memo / 状态 / a11y / 构建 / 监控），每项一句取舍；D6 完整 mock 1 场（phone 60 分钟 + follow-up），录音复盘；D7 缓冲，确认设备与日程。
• 14 天（标准版）：在 7 天基础上——D8-D9 DSA 补线：2-3 道经典 medium（字符串处理、map / 树），目标是多 part 节奏而不是 hard；D10 SD follow-up 专项：给 SD 叙事补三类追问（规模 10 倍、规则冲突怎么办、agent 输出质量怎么衡量），每类给方案 + 取舍；D11 RAG 补深度：chunking 策略、embedding 模型选型、检索 + rerank、eval 集构建，每个概念能讲 2 分钟；D12 BQ 故事库 5-6 个（为什么 Harvey / AI 法律、失败项目、跨团队分歧、时间紧的项目、不确定性下的决策），英文口述各过一遍；D13-D14 完整 mock 2 场（1 场 phone coding + 1 场 onsite 三轮模拟），重点看 follow-up 接没接住、SD 的简化步骤有没有；D15 缓冲。
• 30 天（系统版）：在 14 天基础上——D16-D20 coding 广度：多 part 小系统（文件系统、parser、队列）和 AI 味（RAG、引文、eval pipeline）交替，每天 1 道，每道强制 3 个 follow-up（规模上去、corner case、怎么评估）；D21-D24 AI 产品 SD 专项：2-3 道 SD 题（打分 agent、带引用的文档问答、建议生成），每道强制「简化路径 + 并行 + 评估 + 成本 / 监控」四段；D25-D27 eval 专项：真的搭一个小 eval 集（50-100 条），练「recall / hit rate 怎么测、怎么迭代改进」的完整口述，LLM-as-judge 的坑（位置偏差、自我偏好）能讲清；D28-D29 完整 mock 3 场 + 复盘，断片点写下来各补一段；D30 缓冲，状态调整。

FAQ：Harvey SWE / Frontend 面试 5 个高频问题

Q1：Harvey SWE / Frontend 面试几轮？
2026 公开信号主线：recruiter screen（30 分钟，不考技术）→ Phone / phone screen（45-60 分钟，一道多 part coding）→ Onsite / superday（公开信号三轮：System Design + 项目 deep dive + Coding，每轮约 60 分钟）→ HM / offer。反馈快：phone 当晚通知、onsite 1 小时内到 1 天内出结果都有公开案例，整体 2-4 周常见，以实际收到的邀请为准。

Q2：Harvey phone（phone screen）考什么？难度如何？
一道多 part coding：Part 1 基础实现 + Part 2 错误处理 / 约束升级，评分口径是「working code 优先于最优」。2026 当前新题是内存文件目录系统（Vault，重名加副本后缀）和句子高亮；旧题库有 spreadsheet 操作和 RAG 引文检索。难度不高于 LeetCode medium，难在 Part 2 的 follow-up 链和时间分配；题库换新快，不要背旧题单，按题型练多 part 节奏。

Q3：Harvey onsite 考什么？
三轮主线：Round 1 System Design 是 AI 产品向（规则打分 / review agent：合格 / 可接受 / 不合格 + 修改建议，高频追问是多个 agent 并行的冲突处理）；Round 2 项目 deep dive（项目讲述 + 决策过程追问，「为什么时间紧」类问题高频）；Round 3 Coding 是轻量 embedding / RAG 实现，收尾追问 eval 优化（recall / hit rate）。SD 的关键是「先简化再扩展」，coding 的关键是「先跑通再讲 eval 话术」。

Q4：Harvey Frontend 和 SWE 的准备有什么区别？
共同点：都是多 part coding（working code 优先）、都有项目深挖、反馈都快。区别：Frontend 岗位是两道 coding 子问 +「launch to production 能改什么」的 follow-up，重心是 React 性能、状态管理、a11y、构建部署清单；SWE 岗位是一道多 part coding（小系统 / 字符串）+ AI 味 RAG / eval follow-up，外加一轮规则打分 / review agent 的 SD。如果想补通用 AI 公司的 systems coding 底子，看站内 Anthropic SWE Systems 面经；本篇只覆盖 Harvey 岗位特有信号。

Q5：Harvey 流程多快？「为什么 Harvey」要准备吗？
公开信号：phone 过当晚通知、onsite 结果 1 小时内到 1 天内，从第一次联系到 offer 2-4 周常见，日程留空并主动跟 recruiter 推进（公开信号有 onsite 到场等不到面试官的案例，提前确认日程更稳妥）。「为什么 Harvey」通常在 recruiter screen 和 BQ 轮出现，要落到 AI 法律的具体方向（法律文档问答、引文检索、审查自动化），而不是泛泛的「AI 是未来」。