What to Expect in the GitHub System Design Interview

GitHub's system design interview is notably domain-specific: rather than generic social-network prompts, reported questions center on developer infrastructure, the systems GitHub actually operates at extraordinary scale. The flagship reported prompt is designing GitHub Actions as a CI/CD platform, alongside classics with a GitHub accent: notification systems, rate limiters, and webhook delivery. The platform's operating reality shapes the probing: hundreds of millions of repositories, read-heavy traffic with bursty write storms (a popular release, a viral repo), a public API consumed by millions of integrations, and a developer audience that notices every inconsistency.

For candidates, the domain specificity is an opportunity: the question territory is guessable, the underlying systems are publicly documented, and fluency with developer-infrastructure concepts (CI schedulers, merge semantics, webhook guarantees) converts directly into interview credibility.

The Question Territory

• Design GitHub Actions (a CI/CD platform). The signature prompt: accept workflow definitions, schedule jobs onto ephemeral runners, stream logs live, enforce per-tenant limits, and remain fair when one customer queues fifty thousand jobs.
• Design a notification system. Watch/subscribe semantics across repos, issues, and PRs; fan-out to millions of users across web, email, and mobile; digesting and deduplication; and user-level preference resolution.
• Design webhook delivery. At-least-once delivery to millions of externally-owned endpoints that are slow, flaky, or hostile: retries with backoff, per-endpoint circuit breaking, ordering caveats, and security (signatures, secret rotation).
• Design a rate limiter for a public API. Per-token and per-IP budgets, standard headers developers can program against, burst allowances, and graceful 429 behavior at enormous scale.
• Git-adjacent storage prompts. Occasionally: designing repository storage, code search across hundreds of millions of repos, or a merge queue: prompts where knowing how Git works underneath (content-addressed objects, refs) pays off directly.

What Interviewers Are Probing

1. Read-heavy scale with burst discipline. GitHub's traffic shape is extreme read dominance punctuated by write bursts and thundering herds (a release triggers webhooks, notifications, CI, and feed updates simultaneously). Strong designs name the fan-out explosion and tame it: queues as shock absorbers, deduplication, and per-tenant isolation so one viral repo cannot starve the platform.
2. API design for developers. The consumers are programmers, so interface quality is graded seriously: pagination that survives concurrent writes, rate-limit headers that enable client-side budgeting, idempotency for retried mutations, and versioning discipline. This mirrors the platform's own famously careful API.
3. Multi-tenancy and fairness. Nearly every GitHub-flavored prompt hides a fairness problem: CI capacity, webhook workers, notification throughput. Expect follow-ups on quotas, weighted fair queuing, and abuse containment (crypto-mining on free CI runners is a real-world war story worth knowing).
4. Delivery semantics, stated honestly. Webhooks and notifications force the classic conversation: at-least-once delivery with idempotent consumers, what ordering you can and cannot promise, and where duplicates are acceptable versus where they corrupt downstream state.
5. Operational maturity. GitHub runs developer-critical infrastructure with a public status page; incidents are visible worldwide. Designs that include observability, gradual rollout, and blast-radius limits fit the house culture of operating in public.

Walkthrough Sketch: Designing GitHub Actions

Requirements first: workflows defined in-repo trigger on events (push, PR, schedule); jobs need isolated, ephemeral execution environments; logs must stream live to watching developers; throughput is millions of jobs daily with vicious burstiness; and both hosted and customer-self-hosted runners exist. Name the core tension early: latency (developers watch CI block their merge) versus cost (runner fleets are expensive) versus fairness (tenants share capacity).

Control plane: an event ingester consumes platform events, matches them against workflow definitions, and materializes job graphs (jobs with dependency edges, since workflows are DAGs). Jobs enter per-tenant queues feeding a scheduler that assigns them to runners, with weighted fair scheduling across tenants plus plan-based quotas; a burst from one tenant deepens its own queue without touching others. Runner fleet: pools of pre-warmed ephemeral VMs (cold-boot latency is the enemy of the developer experience), sized by predictive scaling on historical patterns (Monday mornings are real), with strict single-use isolation because CI executes arbitrary untrusted code, which also motivates egress controls and abuse detection. Log streaming: runners push log chunks to a streaming service; watchers subscribe over server-sent events or websockets; chunks persist to blob storage with the live tail served from memory, so the same pipeline serves both watching and replay.

Failure handling shapes the follow-ups: a runner dies mid-job (job marked failed-with-retry per workflow policy; idempotency is the workflow author's problem but the platform must make retry semantics explicit); the scheduler partition hiccups (queues absorb, jobs delay, nothing is lost: the at-least-once contract); log service degrades (jobs continue, tails go stale with a visible indicator, blobs backfill). Close with the fairness-and-abuse dimension unprompted: per-tenant concurrency caps, anomaly detection for mining workloads, and quarantine paths, because the interviewer running this prompt has lived it.

How to Prepare

• Method and depth: Grokking the System Design Interview for the approach, Grokking System Design Fundamentals for the building blocks, and Advanced System Design Interview, Volume II for the queueing, replication, and failure-handling depth the follow-ups reach.
• Rehearse the four house prompts. Actions, notifications, webhooks, and the API rate limiter, each end to end. The territory is unusually predictable; use that.
• Learn the platform's own engineering. GitHub's engineering blog documents its scaling war stories (webhook delivery, Actions architecture, search). Two hours of reading yields vocabulary and real numbers that make your answers concrete.
• Practice the fairness follow-up. For any shared-capacity design, rehearse: how does one abusive or viral tenant affect everyone else, and what specifically contains them?

For the full loop, see What is the GitHub interview process like?, and prepare the collaboration rounds with Top GitHub behavioral interview questions and your answer to "Why GitHub?"