system design 值得单独写一篇，所以我把这部分单独发出来。这个是 senior 的 backend/platform 岗，按大厂对标大概是 L5。
题目： 给了一个 healthcare 场景，大概是：设计一个临床告警的通知投递系统，护士或医生会收到 push notification、应用内提醒，并且如果 60 秒内没确认，还要 fallback SMS。上百万医院 staff，高可靠性要求，还需要合规用的审计日志。
这个场景不是随机的。他们似乎会用一些来自真实系统的问题变体。所以进去前值得想想 healthcare 的一些限制： HIPAA 合规（哪些数据可以，哪些不能放进消息 payload） reliability > availability 的取舍（医院不能漏掉关键告警） 审计日志是硬性要求，不是事后补的 在这个规模的公司里，legacy 系统集成是现实问题
他们怎么 probe： 面试官在 failure modes 上推得很狠。比如 push 通知服务挂了怎么办？怎么保证送达又不重复发送？也问了我怎么处理 audit trail，才能不把关键路径的延迟拖高。
真正重要的点： 清晰地边想边说。我从零画了整个系统，并把每个决策都讲出来。他们似乎没那么在意「完美架构」，更在意你能不能推理取舍。我说「这里我会用 kafka 做 event stream」之后，他们立刻问「why not a simple queue（为什么不用一个简单队列）」，想听我讲清楚 tradeoff，不是听我说一句 kafka。
他们没问的： 没问 ML，没问分布式一致性算法，也没有 CAP 定理的坑题。更偏实用，不偏学术。
时长： 55 分钟，然后留了几分钟 Q&A。时间感觉合理。
如果你习惯大厂 system design，这轮反而更协作、没那么对抗。比如我在 SMS fallback 这块卡住时，面试官会帮我一起推进，而不是看我干耗。