GitHub · Primly Community

GitHub senior / L5 system design interview, what to expect going in

infra_ines · 4 replies

Just finished my GitHub senior SWE loop a few weeks ago and want to write up the system design portion while it's still fresh. Spoiler: it's a genuine technical conversation, not a whiteboard hazing session.

The round was 60 minutes. My interviewer was a staff engineer on a platform team. First ten minutes or so were just introductions and him explaining how he likes to run the session. He was pretty explicit that he cared more about how I reason through tradeoffs than whether I hit some checklist.

The problem was a notification delivery system, which felt very on-brand for GitHub (you know, watch subscriptions, PR notifications, issue mentions). They didn't give me a single-sentence prompt and leave me hanging. It was more like a dialogue. I'd propose something, he'd add a constraint, I'd revise. Felt collaborative.

Things that came up: Distinguishing between fan-out-on-write vs fan-out-on-read for different subscription patterns How to handle bursty load (think: Linus Torvalds merges something and 50k watchers get pings) Idempotency for retries, deduplication at the delivery layer Trade-offs between Kafka and a simpler queue depending on ordering guarantees needed Brief discussion of rate-limiting outbound email so you don't get blocked by email providers

I got into database schema a bit but he redirected me back to the higher-level design, which was a useful signal: at this level they want you thinking in systems, not in column types.

Total loop was 5 rounds including this one. Other rounds covered coding (2 rounds), behavioral, and a hiring manager conversation. The system design was probably my strongest round.

Level-wise this was targeted at senior/IC4 equivalent, not staff. I've heard the staff design sessions are broader in scope and bring in a second interviewer for parts of it, but I can't confirm that.

Happy to answer questions about the other rounds.

4 replies

infra_ines

The fan-out-on-write vs read tradeoff is a classic for GitHub's domain. Did they push you on consistency guarantees at all? Like, how stale can a notification be before it's a problem?

backend_bekah

Yeah, briefly. I said for watch notifications a few seconds of lag is fine but for PR review request pings you want delivery within like 30 seconds. He seemed satisfied with just naming the tradeoff and not requiring me to engineer a hard SLA.

staff_steph

Good write-up. One thing I'd add for anyone prepping: GitHub's infra is built heavily on Rails and they still run a lot of jobs through their internal background job system. Knowing a bit about how GitHub works under the hood (Actions, webhooks, audit log) helps you ask better clarifying questions and signal that you've thought about the product.

sre_sol

Did the deduplication piece come up for the case where the same user is mentioned in a PR and is also a watcher? Curious how granular they went.