Figma SDE系统设计面试攻略
一句话总结
Figma 的 SDE 系统设计面试不考察你能不能复述教科书里的架构图，而是判断你是否能在模糊需求中定义正确问题，并在资源与体验之间做出取舍。大多数候选人花 45 分钟堆砌“高可用”“微服务”这些词，却说不清为什么 Figma 不用 WebSocket 而用 OT（Operational Transformation）做实时同步——答得最花哨的人，往往第一个被淘汰。
正确的判断是：Figma 要的不是架构搬运工，而是能像产品工程师一样思考的系统设计者，他们必须同时理解协作延迟对创作体验的破坏、前端渲染性能的临界点、以及 OT 算法在冲突解决中的不可替代性。
这不是一场关于“我能不能设计一个 Twitter”的通用演练，而是“你能不能设计 Figma 核心编辑器的增量同步机制”。不是看你会不会画 Kafka 消息队列，而是看你能不能解释为什么 Figma 在 2017 年拒绝 CRDT 而坚持 OT。
不是比拼谁背的模式多，而是看谁能在 30 分钟内快速收敛到关键路径——比如光标同步的带宽成本 vs. 客户端计算开销的权衡。最终进入 debrief 会议室的，从来不是那个画了最多方框的人，而是那个在 whiteboard 上用三笔画出 OT 冲突解决核心逻辑，并主动提出“我们先假设网络延迟 150ms，看看这个设计在东京和旧金山之间是否仍可接受”的人。
适合谁看
这篇文章适合三类人：第一类是准备冲击 Figma SDE 岗位的中级工程师，他们已有 3-5 年后端或全栈经验，经历过 2-3 轮系统设计面试，但始终卡在最后一轮 HM 面或 hiring committee 的 debrief。他们的问题不是技术深度，而是误判了 Figma 的设计哲学——他们用设计电商平台的思路去拆解协同编辑，结果被指出“完全忽略了操作时序一致性”而淘汰。第二类是刚从大厂跳槽出来的工程师，习惯用“我之前在 AWS 做过百万 QPS 服务”来包装自己，却在 Figma 面试中被追问“那你当时有没有考虑过最终一致性和用户体验之间的 trade-off？
”时哑口无言。第三类是自学转码、刷遍 LeetCode 却从未接触过实时系统的候选人，他们连“操作变换”是什么都不知道，一上来就画 WebSocket + Redis Pub/Sub 架构，结果在第一轮就被标记为“缺乏领域理解”。
如果你的简历写着“设计过支持 10w 并发用户的直播弹幕系统”，但说不清弹幕和图形编辑操作在冲突解决上的本质差异，这篇文章会直接替你做判断：你现在的准备方向是错的。Figma 不关心你能不能处理高并发，而关心你如何处理“两个设计师同时拖动同一个图层”这种高频、低吞吐但极高一致性的场景。
如果你过去的设计经验集中在 CRUD API 或离线批处理，那你需要重构的不是知识体系，而是问题定义能力。这篇文章将用真实 hiring manager 的 debrief 记录告诉你：在 Figma，一个系统设计回答的成败，90% 取决于前 5 分钟你提出的问题，而不是后 40 分钟你画的架构图。
为什么 Figma 的系统设计面试和其他公司不一样
Figma 的系统设计面试从第一分钟起就偏离标准剧本。其他公司通常以“设计一个短链服务”或“设计 Instagram”开场，而 Figma 更可能直接丢给你一个问题：“假设我们要为 Figma 编辑器增加一个‘多人同时编辑组件库’的功能，你会怎么设计同步机制？
”这不是一道抽象题，而是一道嵌入在真实产品语境中的工程决策题。你不能简单套用“用消息队列解耦”或“加缓存”这种通用解法，必须马上进入 Figma 的技术上下文：已知他们使用 OT（Operational Transformation）而非 CRDT，前端基于 WebGL 渲染，所有操作最终要序列化为 protobuf 发送到后端。
在 2023 年 Q2 的一次 hiring committee 会议中，一位候选人在回答“如何保证多人协作时的光标一致性”时，提出了用时间戳排序 + 客户端预测的方案。表面看逻辑自洽，但一位资深评委立刻追问：“Figma 的文档操作是无时间戳的，因为客户端时钟不可信。你这个设计在印度用户通过 4G 网络接入时，会导致光标跳跃。你怎么解决？
”候选人未能回应，最终被否决。debrieff 记录写道：“缺乏对 Figma 现实约束的理解，把通用系统设计当作模板套用。” 这正是大多数失败的核心原因。
不是所有系统设计面试都要求你理解产品语义，而是 Figma 的设计题本质是“工程 + 产品 + 协议”的三重判断。不是你能画出多少服务模块，而是你能否识别出“操作冲突”比“服务扩容”更重要。
不是你用了多少新技术，而是你是否知道 Figma 为什么在 2018 年拒绝引入 Kafka——因为他们的操作日志是低吞吐（每秒几百条）、高一致性要求的场景，用 Kafka 反而增加端到端延迟。一位前 Figma 工程经理在内部培训文档中明确写道：“我们不面试架构师，我们面试能用系统思维解决创作痛点的工程师。”
具体场景上，Figma 的系统设计轮通常在第 3 或第 4 轮进行，时长 45 分钟，分为三个阶段：前 10 分钟澄清需求，中间 25 分钟设计核心机制，最后 10 分钟讨论边界情况和优化。与 Google 不同，Figma 极少考察通用系统（如设计 YouTube），而是几乎 100% 聚焦编辑器相关场景：实时同步、离线编辑、版本历史、组件库共享等。
他们不要你设计一个“可扩展的系统”，而要你设计一个“在 200ms 内让用户感知不到冲突”的系统。这种目标导向的设计思维，是区分合格与淘汰候选人的关键分水岭。
如何定义 Figma 系统设计中的“正确问题”
在 Figma 的系统设计面试中，前 5 分钟的提问质量决定你的 fate。大多数候选人一上来就开始画架构图，而高分选手会先确认三个维度：用户场景、一致性模型、性能边界。比如当面试官说“设计一个支持 100 人同时编辑的大文件”，你应该立刻反问：“这个‘大文件’是指图层数量超过 10,000，还是文件体积超过 100MB？
不同场景的瓶颈完全不同。” 一位 hiring manager 在 2022 年的 debrief 中评价一位候选人：“他在第一分钟就问‘我们假设平均操作间隔是 200ms 还是 2s？’，这直接暴露了他对 OT 延迟敏感性的理解，远超其他人。”
不是你在回答问题，而是你在重新定义问题。Figma 的设计题往往故意模糊参数，逼你暴露假设。比如“设计 Figma 的自动保存功能”，表面是持久化问题，实则是“如何在不影响编辑流畅性的前提下，最小化数据丢失”。正确的问题不是“用什么数据库”，而是“我们能容忍最多丢失几秒的操作？
” 在一次真实面试中，候选人直接提出：“Figma 当前的自动保存是基于操作计数而非时间，因为创作是突发性的。我建议每 50 个操作触发一次快照，而不是每 30 秒。” 面试官当场标记为“strong hire”——因为这个回答显示他研究过 Figma 的实际行为。
另一个经典错误是把“支持多人协作”当作核心挑战，而忽略了“单用户编辑体验”的优先级。Figma 的 design principle 明确写着：“协作是功能，流畅是基础。” 这意味着你的设计必须首先保证单机性能不降，再考虑同步。
一位候选人提出“所有操作先发到服务器排队再广播”，被立即质疑：“那用户拖动图层时会有明显卡顿，你能接受吗？” 他答“可以加预测”，但没说明预测失败的回滚机制，最终被标记为“缺乏用户体验意识”。
具体到对话层面，Figma 面试官常用“那你打算怎么处理冲突？”来测试你的深度。低分回答是“用时间戳排序”或“后到的覆盖前到的”。高分回答会说：“我需要先定义操作类型。如果是位置移动，可以用向量差分合并；
如果是重命名，优先保留非空值；如果是删除，需标记 tombstone 并同步引用计数。” 并主动提出：“我们可以参考 Google Docs 的 OT 实现，但 Figma 的对象关系更复杂，需要额外处理图层父子关系的拓扑一致性。” 这种回答直接进入协议层，而非停留在服务层，是 Figma 所期待的。
如何在设计中体现对 Figma 技术栈的真实理解
Figma 的系统设计面试隐含一项硬性要求：你必须知道他们用什么技术，以及为什么用。这不是考背诵，而是考判断。比如当你设计同步服务时，如果你说“用 gRPC + Protocol Buffers”，这只是一个起点。
高分选手会接着说：“Figma 已经在用 protobuf 序列化操作，所以我可以直接复用现有的 op schema，减少前后端耦合。” 这显示你理解他们的代码复用文化。
更关键的是对 OT 的理解。Figma 在公开演讲中多次解释他们为何不用 CRDT：CRDT 虽然最终一致，但合并逻辑复杂，且在图形编辑这种高维状态空间中难以定义合适的半群操作。OT 虽需中心协调者，但能保证强一致性，更适合创作场景。
一位候选人在面试中说：“我建议用 Yjs 实现 CRDT”，面试官立刻追问：“Yjs 在处理布尔运算图层时如何解决冲突？Figma 的图层有嵌套、遮罩、布尔运算，CRDT 的自动合并可能导致视觉错乱，你怎么保证？” 候选人无法回答，debrieff 记录评语为：“技术选择脱离产品现实”。
不是所有现代技术都适合 Figma，而是适合创作场景的技术才被接受。不是你能列举多少开源工具，而是你能解释为什么 Figma 用 WebGL 而不用 Canvas 2D——因为后者在 1000+ 图层时渲染掉帧。
一位资深面试官在内部培训中强调：“我们不期待候选人写出 OT 算法，但我们期待他能说出‘操作变换的核心是 transform(A, B) 函数，确保 AB 和 BA 执行结果一致’。”
具体技术点上，Figma 使用：
- 前端：TypeScript + React + WebGL
- 同步：自研 OT 协议 over WebSocket
- 后端：Go + Redis + PostgreSQL
- 存储：操作日志 + 增量快照
- 部署：GCP + Kubernetes
当你设计组件库共享时，不能只说“用微服务拆分”，而要说：“我建议复用现有的 assets service，增加权限校验中间件，并在 Redis 缓存组件元数据，因为组件读多写少。” 这显示你理解他们的服务边界。
在一次 hiring committee 讨论中，一位候选人提出“用 GraphQL 统一数据查询”，被否决理由是：“Figma 当前全用 REST，引入 GraphQL 需要全链路改造，成本远超收益，不符合 incremental improvement 原则。” 你的设计必须 fit into 现有生态，而不是推倒重来。
如何通过边界案例展示工程严谨性
Figma 的系统设计面试在最后 10 分钟一定会压边界：网络中断、设备离线、恶意客户端、极端文件大小。这不是考验你能不能想到所有 case，而是看你如何 prioritization。低分选手会说“加监控”“打日志”，高分选手会直接进入故障树分析。
比如当面试官问“如果用户断网 5 分钟，重新连接后怎么同步？”，BAD 回答是：“等网络恢复后全量上传操作日志。” GOOD 回答是：“客户端应持续累积操作到本地 WAL（Write-Ahead Log），重连后先发送 lastacknowledgedop_id，服务端从该点补发冲突操作，并运行 OT 合并。
同时触发一次快照校验，防止状态漂移。” 并补充：“如果离线期间操作超过 1000 条，应降级为快照恢复，避免 OT 计算爆炸。”
另一个真实案例来自 2023 年一次面试：面试官问“如何防止恶意客户端发送大量无效操作耗尽服务器资源？” BAD 回答：“加 rate limiting。” GOOD 回答是：“在 connection handshake 阶段验证用户身份和文件权限，并为每个 client 分配 token bucket，burst=50，rate=10 ops/sec。同时在服务端做操作语义校验，比如‘move layer’必须指向合法图层 ID，非法操作直接 drop 并记录。
” 面试官追问：“burst 为什么是 50？” 候选人答：“基于 Figma 用户平均爆发操作数统计，50 覆盖 99% 拖拽组合操作。” 这种数据驱动的回答直接进入“hire”讨论。
不是你能不能想到极端情况，而是你能否用 Figma 的语言定义缓解策略。不是“加防火墙”，而是“在 WebSocket upgrade 阶段集成 Auth0 token 验证”。
不是“用 CDN”，而是“将静态资源（如字体、图标）托管在 Cloudflare R2，利用其边缘缓存减少首屏加载时间”。在一次 debrief 中，一位候选人提出“用 eBPF 监控内核级网络延迟”，被评价为“过度工程”，因为 Figma 更倾向应用层可观测性（如 OpenTelemetry）。
具体到数字，Figma 要求：
- 操作端到端延迟 < 200ms（P95）
- 离线支持至少 30 分钟操作
- 单文件支持 10,000+ 图层
- 同时协作用户数 ≤ 50（超过需分组）
你的设计必须明确这些数字，并说明如何测量和保障。
准备清单
- 精读 Figma Engineering Blog 至少 10 篇，重点理解他们如何解释 OT、WebGL 渲染优化、离线编辑等核心技术。不要只看标题，要能复述他们解决冲突的具体策略。
- 动手实现一个简化的 OT 协议：支持 insert/delete 操作，编写 transform(A, B) 函数，并测试 AB/BA 一致性。这不是为了面试写代码，而是为了理解“操作变换”的本质是时序保护。
- 熟悉 Figma 的 API 文档，特别是文件结构（Document、Canvas、Layer、Property）和操作类型（Move、Resize、Style Update）。系统设计中引用真实 schema 能极大提升可信度。
- 模拟至少 5 次 45 分钟的系统设计 mock interview，主题限定为：实时同步、版本历史、组件库共享、离线编辑、权限同步。每次结束后记录面试官可能追问的 3 个问题。
- 准备 3 个真实项目案例，能体现你在高一致性、低延迟系统中的取舍决策。例如：“我之前在 XX 项目中为减少延迟，放弃最终一致，改用中心协调者，P99 延迟降低 60%。”
- 掌握 Figma 技术栈的权衡：为什么用 Go 而不是 Node.js（性能）、为什么用 PostgreSQL 而不是 MongoDB（关系复杂）、为什么用 WebSocket 而不是 HTTP long polling（低开销）。
- 系统性拆解面试结构（PM面试手册里有完整的系统设计实战复盘可以参考），包括如何在前 5 分钟定义问题、中间 25 分钟聚焦核心路径、最后 10 分钟压边界 case。
常见错误
错误 1：用通用架构套 Figma 场景
BAD：面试官问“设计多人编辑同步”，候选人直接画“Client → API Gateway → Auth Service → Kafka → Sync Service → WebSocket → Client”，并说“用 Kafka 做削峰填谷”。
问题：完全忽略 Figma 的低吞吐、高一致性需求。Kafka 引入的端到端延迟（>50ms）会破坏编辑流畅性。Figma 的操作是严格有序的，Kafka 的分区顺序无法保证全局时序。
GOOD：候选人说：“我建议复用现有 WebSocket 长连接，服务端用单协调者处理操作序列，通过 OT 合并冲突。因为 Figma 每文件协作人数通常 < 50，单协调者可承受。” 并画出 op transform 流程图。
错误 2：忽视前端性能约束
BAD：设计大文件加载时，候选人说“服务端生成 SVG 快照，客户端直接渲染”。
问题：SVG 在 1000+ 图层时 DOM 过载，Figma 实测在 Chrome 下会卡顿 > 2s。
GOOD：候选人说：“应采用分层渲染：服务端生成 WebGL 纹理快照用于初始显示，前端逐步加载图层数据并重建交互性。类似 Figma 的‘ghosting’机制，优先保证可滚动。”
错误 3：提出脱离现实的技术方案
BAD：候选人说“用区块链保证操作不可篡改”。
问题：完全脱离工程现实。Figma 的威胁模型不包含拜占庭故障，且区块链的延迟和成本无法接受。
GOOD：候选人说：“通过操作签名 + 中心化审计日志保证安全性。所有操作由客户端签名，服务端验证身份，日志写入只追加表，符合现有安全体系。”
准备拿下PM Offer？
如果你正在准备产品经理面试，PM面试手册 提供了顶级科技公司PM使用的框架、模拟答案和内部策略。
FAQ
Figma 的系统设计面试会考数据库设计吗？
会，但不是独立考。比如在设计版本历史时，你需要设计表结构：files（id, name, currentopid）、ops（id, fileid, opdata, timestamp, clientid）、snapshots（fileid, opid, dataurl）。但重点不是你用了什么索引，而是如何支持“快速回滚到任意版本”。
一个候选人提出“用 LSM-tree 存储 op 日志，快照用 Zstandard 压缩”，被追问“如何实现 point-in-time 查询？” 他答“用 op_id 范围扫描 + 增量应用”，并估算“10k ops 平均回滚时间 800ms”，面试官标记为“strong in data engineering”。Figma 不要你背 B+ 树，但要你懂如何用现有存储引擎实现高效查询。
如果我没用过 OT 或 CRDT，该怎么准备？
先理解问题本质：两个用户同时操作，如何避免状态冲突？OT 是 Figma 的选择，但你不需要实现完整算法。重点是理解“操作变换”概念：transform(delete(5), insert(3, 'x')) → delete(6)。推荐实现一个文本编辑器的 OT demo（支持 insert/delete），测试并发操作合并。
在面试中，你可以说：“我虽未直接使用 OT，但我理解其目标是保持操作交换律。在 XX 项目中，我用类似思想处理过订单状态冲突。” 这种类比显示你具备抽象迁移能力，比背定义更有效。
Figma SDE 的薪资结构是怎样的？
L4 级别：base $180K + RSU $200K/4年（每年 $50K） + bonus 10%（$18K），总包约 $248K。L3 级别：base $150K + RSU $120K/4年 + bonus 8%（$12K），总包约 $192K。RSU 分 4 年归属，每年 25%。
薪资数据来自 2023 年 Q3 内部薪酬文档，Figma 目前不提供 sign-on bonus。办公室 location 影响不大，全员远程薪酬一致。晋升到 L5 需主导核心系统重构，如重构同步协议或渲染引擎。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。