GitHub · Primly 社区

GitHub senior / L5 system design 面试:进去前你要知道什么

infra_ines (Primly starter) · 4 条回复

几周前刚结束 GitHub senior SWE loop,想趁还新鲜把 system design 部分写下来。先说结论:这是一场真正的技术对话,不是白板羞辱。

这一轮 60 分钟。面试官是 platform team 的一个 staff engineer。前十分钟左右主要是互相介绍,他也讲了下他喜欢怎么跑这场 session。他说得很直白:他更在意我怎么推理 tradeoff,而不是我有没有打中某个清单。

题目是通知投递系统,很符合 GitHub 的气质(watch 订阅、PR 通知、issue mentions 那套)。他们不是丢一句 prompt 就不管了,更像对话。我提一个方案,他加一个约束,我再调整。整体很协作。

聊到的点: 不同订阅模式下,fan-out-on-write vs fan-out-on-read 的区分 怎么处理 bursty load(比如 Linus Torvalds merge 了东西,50k watchers 同时被 ping) 重试的 idempotency、投递层的去重 需要的有序保证不同,Kafka 和更简单队列之间怎么取舍 简单聊了下 outbound email 的 rate-limiting,避免被邮件服务商封

我聊了一点数据库 schema,但他把我拉回到更高层的设计,这个信号挺有用:到这个 level 他们想看的是系统思维,不是列类型。

总共 loop 5 轮,这轮是其中之一。其他轮包括 coding(2 轮)、behavioral、以及一轮 hiring manager conversation。system design 应该是我最强的一轮。

Level 上,这轮目标大概是 senior/IC4 equivalent,不是 staff。我听说 staff 的设计会更广,会加第二个面试官负责部分内容,但我没法确认。

其他轮的问题也欢迎问。

由 AI 翻译,查看原文

4 条回复

infra_ines (Primly starter)

fan-out-on-write vs read 的权衡在 GitHub 这个领域算经典了。他们有追问一致性保证吗?比如通知最多可以延迟到什么程度才会成问题?

由 AI 翻译,查看原文

backend_bekah (Primly starter)

有,简单提了一下。我说 watch notifications 延迟几秒没关系,但 PR review request 的提醒希望在比如 30 秒内送达。他看起来只要你点出取舍就满意了,不要求我给出一个硬 SLA。

由 AI 翻译,查看原文

staff_steph (Primly starter)

写得很好。我想给准备的人再补充一点:GitHub 的基础设施很大一部分是基于 Rails 搭的,而且他们现在还有不少任务跑在自研的内部后台任务系统里。稍微了解一下 GitHub 底层是怎么运作的(Actions、webhooks、audit log),能帮你问出更好的澄清问题,也能让对方感觉你确实认真想过这个产品。

由 AI 翻译,查看原文

sre_sol (Primly starter)

有没有聊到去重那块,比如同一个用户既在 PR 里被提到,同时也是 watcher 的情况?好奇他们细化到了什么程度。

由 AI 翻译,查看原文