几个月前我在 Malvern 面完了 Vanguard 的一个 Senior SWE 岗位流程。想分享一下 system design 这一轮我实际看到的情况，因为网上关于这家公司的有用信息几乎没有。
Vanguard 说这个 level 大致等同于 Google 的 L5 或 Meta 的 E5。system design 面试 60 分钟，一个面试官，用共享的线上白板。
他们给我的题目是：设计一个系统，用来追踪大型共同基金组合的实时 NAV（net asset value）更新，并在某只基金相对其 benchmark 偏离超过某个阈值时触发告警。
重要的点： 他们真的在意数据新鲜度的取舍。我在事件流（Kafka-style）和轮询之间讲得很深，面试官也围绕这个点追问得很狠。 延迟 vs. 正确性是个真实主题。他们会追问如果你处理了一个过期价格会怎样。金融数据有合规影响，他们很认真。 他们想知道你怎么在不「过度设计」的情况下处理规模。这不是面向消费者的 TikTok 级产品。吞吐量是每天几万条基金更新，不是几十亿请求。要匹配这个量级。 存储：他们希望你考虑时间序列数据、历史快照、审计日志。合规在 Vanguard 很重要。
他们不太关注的：PB 级规模的分片方案、CDN 策略、任何纯 FAANG 风格的东西。他们看重正确性、可审计性和可靠性。把它当成「无聊但稳」的金融基础设施，不是 Google Maps。
面试官是 principal 级别工程师。追问质量很好，不是刁难风格。他提到他们内部在用 AWS，也在把一些老的 on-prem 系统现代化，所以自然聊到了云迁移背景。
整体难度：中上。懂金融数据概念的话，比 FAANG system design 更容易；如果你只刷过「design Twitter.（设计 Twitter。）」，会更难。
我因为 comp 原因拒了 offer（另一个帖子再细说），但这个流程本身算是我经历过技术上比较实在的一个。
5 条回复
ae_andre (Primly starter)
NAV 这个题很有意思。他们在不在意 end-of-day NAV（标准的 mutual fund 计算）和 ETF 的 intraday estimated NAV 之间的区别？这是一个很关键的架构分岔。intraday 意味着要接近实时地接入市场行情流，end-of-day 基本就是个 batch job。
由 AI 翻译，查看原文
sdr_sky (Primly starter)
对，他们确实问到这块了。他们的表述是「assume mutual funds for now but design for future ETF support.」（先按 mutual funds 来假设，但要为未来支持 ETF 做设计。）所以你至少得承认 intraday feed 这个问题，不能把自己逼到死角。system design 里自然会聊到可扩展点。
由 AI 翻译，查看原文
marketer_mei (Primly starter)
那个无聊的 finance infra 点说得太对了。我面过几家 asset manager，他们的校准标准一直都是“我们要正确、可审计、可恢复”。没人会在乎你的 p99 latency 是 12ms 还是 8ms。他们在乎的是，会不会因为系统里有 race condition，导致一笔错误交易被放过去。
由 AI 翻译，查看原文
content_cole (Primly starter)
他们会问任何 frontend system design 吗？我是 frontend eng，在考虑 Vanguard，想知道不同方向的 loop 是不是一样，还是 design 这一轮会分叉。
由 AI 翻译，查看原文
pivot_pat (Primly starter)
我的 loop 更偏 backend，所以 frontend 我不太清楚。你可以直接问 recruiter，你这个 track 的 design 轮具体考什么。我当时的 recruiter 对这种「流程层面的」问题回复挺快的。
由 AI 翻译，查看原文