上个月刚走完 HubSpot 的 loop，投的是 senior SWE 岗，已接 offer。system design 那轮最有意思，所以写一下。
先说一句，HubSpot 不像 Google 那样正式用 L 级别。内部有 level，但你在和 recruiter 聊时听到的会是「senior」「principal」「staff」，不会是 L5。尽管如此，senior 的 bar 体感大概相当于中等梯队公司里的 L5。
这一轮本身
一小时，Zoom，Miro 白板。面试官是一个 senior eng，不是 panel。他给了我一个经典的 CRM 相关题：设计一个系统，高并发地追踪用户在各种触点上的行为（邮件打开、表单提交、页面访问）。这就是 HubSpot 真在做的那种问题，我挺喜欢。
他们在意的点，以及我们花时间的优先级： 先数据模型。他们要我先把实体和关系讲清楚，再谈基础设施。我得强压住自己直接画队列图的冲动。 大规模事件接入。Kafka 自然就提到了。他们没考 Kafka 细节，但想确认我理解 fan-out、consumer group、顺序保证。 存储选择。写密集 vs 读密集的取舍。我讲了 Postgres 做关系型，S3 + 列式格式做分析，他们会追问为什么不只用一个 DB。 API surface。你会怎么把它暴露给下游服务和第三方集成。
对分布式系统理论的深挖更少（没有 CAP 定理小测）。更强调真实产品公司会做的真实取舍。HubSpot 的 infra 不是 FAANG 规模，他们也知道。设计目标是「每天几 billion events 也能稳定跑」，不是「design Twitter.（设计 Twitter。）」
设计里嵌入的 behavioral
大概 20 分钟时他问了「tell me about a time you designed something at this scale for real.（讲讲你曾经真实地在这个规模下设计过东西的一次经历。）」。不意外，他们有时会把 behavioral 塞进 technical 轮。准备一个真实故事，不要假设性的。
结论
我用 LeetCode 那套 system design 资源准备，结果对 HubSpot 有点过度。Designing Data-Intensive Applications 更贴近他们在意的点。重点放在 event-driven 架构、数据建模、以及能把取舍讲出来，被 push 时别防御性太强。