去年秋天我在 RenTech 面了 senior 的 SWE 岗，做了 system design 这一轮。分享一下笔记，因为形式和纯产品公司不太一样。
设置： 45 分钟，一个面试官（senior 工程师），没有白板花活。他们一开始给你 prompt，然后让你主导。我拿到的类似：设计一个低延迟的数据 pipeline，接收 market data 并路由给多个下游 consumer。很偏交易场景，不是那种泛泛的「design Twitter（设计 Twitter）」题。
他们看重什么： 延迟高于一切。 我说「这里可以用 Kafka」时，他们立刻追问：tail latency 多少，consumer 落后时会怎样，怎么隔离 backpressure。在产品公司可能听到 Kafka 就点点头过去了。这里默认你真的知道它怎么工作。 细到位的 failure mode。 他们要你讲失败场景、恢复策略、网络分区时怎么办、系统如何优雅降级。CAP 定理是自然出现的，不是故意刁难。 运维现实。 监控、告警、你怎么在凌晨 4 点 debug 延迟飙升。很明显他们有 on-call 文化，他们希望你能从运维角度思考，而不只是画架构。
不太在乎什么： 粗略估算和手算规模。他们似乎更关心你是否理解选择背后的权衡，而不是你能不能把 QPS 估得很准。
我会怎么准备： 说实话，多读分布式系统资料（DDIA 这本书基本覆盖概念地基），并把你的 streaming 技术栈吃透。如果你在生产环境跑过 Kafka、Flink 或类似系统，就把你真正踩过的 failure case 讲出来。
面试官真的很投入，也对这个领域很懂。感觉更像同行之间的技术讨论，而不是被审判。只是那个同行可能比你聪明。
6 条回复
marketer_mei (Primly starter)
DDIA 永远是正确答案。我这么说是因为我也曾觉得 system design 那轮前不需要重读一遍。结果我读了。我确实需要。
由 AI 翻译，查看原文
returner_ren (Primly starter)
prompt 是提前给你的吗，还是他们在 session 一开始才介绍？问是因为我喜欢先想清楚再说，而且我通常需要几分钟整理思路。
由 AI 翻译，查看原文
infra_ines (Primly starter)
一开始就给题。没有准备时间。你只需要习惯把「给我两分钟想一下」大声说出来。这个级别的大多数面试官都能接受。我就这么做了，面试官还直接说「当然，慢慢来。」
由 AI 翻译，查看原文
market_realist (Primly starter)
这个 trading-adjacent 的题目挺有意思。他们会期待你有金融数据领域知识吗，还是只是一个刚好涉及 market data 的系统题？
由 AI 翻译，查看原文
infra_ines (Primly starter)
他们不期待 trading 领域知识，就是个系统题。你大概知道「market data」是什么就够了，不会考你 order book 或期权定价。但如果你确实有相关背景，可能会更自然地把延迟要求之类的点框出来。
由 AI 翻译，查看原文
Primly Team
One piece candidates often under-prepare for in a low-latency design round is how you reason about time across the whole pipeline. Beyond naming components, practice explicitly budgeting latency end-to-end (ingest, decode, fan-out, queueing, processing) and calling out where tail latency is born. A useful structure is: define SLOs first (p99, drop policy, ordering guarantees), then walk through the data path once, then do a second pass for “what breaks” with concrete mitigations (bounded queues, backpressure strategy, load shedding, replay semantics, idempotency keys, and exactly what you measure at each hop).
For RenTech specifically, system design shows up as part of a full-day onsite for Software Engineer roles, and they tend to value operational scenarios alongside design and coding per typical process notes.
What’s one failure mode or latency killer you’ve seen derail otherwise solid designs in interviews, and how did you learn to address it succinctly?