GitHub Interview Guide (2026)

1Snapshot, read this first#

The one thing to understand about GitHub: it is a remote-first, writing-heavy, developer-obsessed company owned by Microsoft. Read that back into the interview and it explains everything.

• The job is async, so a lot of decisions happen in issues and pull request comments, not meetings.
• Interviewers are checking whether you would be a good teammate in that world, not just whether you can solve a problem.
• If you cannot talk about pull requests, Actions, or what separates a good code review from a rubber stamp, you are starting from behind.
• Your public work is part of your resume whether you link it or not.

2Getting the call (the part most guides skip)#

GitHub gets a flood of applications, tens of thousands a year against a small number of open reqs on any team. The apply button is the slow lane.

The fastest path in:

• A referral from someone inside. GitHub is unusually easy to get one at, because your public work is your resume.
• A short, specific note to an engineer on the team you want, linking a repo or contribution relevant to what they build. That converts far better than cold applying.

Your GitHub profile is part of the application, so treat it like one:

• A recruiter will look, every time.
• An active profile with real commits, repos with READMEs that explain what the thing does and why, and a merged PR to a project the team cares about beats a polished PDF.
• Profiles get forwarded to hiring managers purely off a good contribution graph and one well-reviewed PR.
• The opposite is a quiet negative: an empty profile from someone applying to GitHub reads as a flag.

On the resume, kill the vague bullets. "Worked on backend services" tells me nothing: I cannot tell what you owned, how big it was, or whether it worked. Compare the before and after.

Cut p99 API latency from 820ms to 190ms by moving N+1 queries to a batched loader and adding a Redis read-through cache, across 40M daily requests.

• That bullet has a before, an after, a method, and scale.
• A reviewer reads it in four seconds and knows you can diagnose, fix, and measure.
• Aim for every bullet to carry a metric and a verb that names what you personally did.

On ATS keywords, mirror the job post honestly:

• If they say Ruby, Go, Rails, Kubernetes, distributed systems, put the ones that are genuinely true in plain words, not buried in a skills soup at the bottom.
• GitHub's core app is a large Rails monolith with Go services around it, so Ruby and Go are real signals, and so is anything about scaling a monolith or breaking pieces out of one.
• Never lie about a language. It surfaces in round one the moment someone asks you to write it.

3The loop at a glance#

How the loop shifts by level:

• Juniors often skip full system design and get a CS-fundamentals or practical-coding round instead.
• Seniors almost always get design, sometimes two.
• The recruiter screen is a real gate, not a formality.

Walk into the screen with two things locked:

• A clear two-sentence "why GitHub" that is about the product, not the logo.
• A comp number you can say cleanly, because an awkward answer here can stall the whole thing before you ever write code.

4The coding or technical rounds#

Good news: GitHub is not a trick-question shop.

• No obscure DP that only shows up in competitive programming.
• Difficulty sits at LeetCode medium, occasionally a medium-hard.
• The hard part is doing it cleanly while talking, in 45 working minutes, after clarifying eats the first five.

The patterns they reuse:

• Hash maps and frequency counting. Group things, dedupe, count. Shows up constantly, often dressed as "aggregate events by repo." The win is usually a single pass with a map keyed on the right field.
• Strings and parsing. Parsing a diff, a log line, a query filter like is:open label:bug. GitHub's world is full of text, so expect to split, scan, and build structure from a raw string.
• Trees and graphs. Dependency resolution, file trees, commit ancestry (a commit DAG is a real thing here, every merge is a graph). BFS/DFS, topological sort, cycle detection.
• Intervals and sorting. Merging ranges, scheduling overlapping jobs, "did these two time windows collide."
• Two pointers and sliding window for the array-heavy ones, usually a "longest/shortest window that satisfies X" framing.

Expect the problem framed as a real engineering task, not "given an array of ints."

• Something like: "given a list of pull request events, return the most active reviewers in a time window."
• The underlying move is a hash map plus a sort, same as a textbook problem.
• The twist: you have to find the algorithm inside the product language yourself.

How to actually win the round. Communication is scored as heavily as correctness.

1. Clarify first. Restate the problem in your own words. Ask about input size (does it fit in memory?), edge cases, sorted or not, bad or empty input, whether ties matter. Candidates who clarify well and write slightly messy code pass; candidates who write perfect code in silence fail, because I cannot tell if they understood it or got lucky.
2. Say your plan out loud before typing. "Hash map keyed by reviewer, one pass to count, then a sort for top-k, so O(n log n) time, O(n) space." Now I know you think before you code, and I can catch a bad plan before you burn 20 minutes.
3. Write code a teammate could read. Real names, small functions, no single-letter variables outside a tight loop. This is GitHub. They review code for a living, so sloppy naming reads as a culture miss, not a style preference.
4. State complexity without being asked. Time and space, and whether you think it is optimal or where the obvious win would be with more time.
5. Test it yourself. Walk a small input through by hand, out loud. Call out the empty case, the single element, the duplicate, the tie. Finding your own off-by-one before I point it out is a strong signal.

How to practice so it transfers:

• 40 to 60 mediums on arrays, hash maps, strings, trees, and graphs.
• Do them talking out loud, on a timer, in a shared editor with no autocomplete or compiler, because that is the real setup.
• Silent grinding trains the wrong muscle: it optimizes for getting the answer, when the round scores how you get there.

5System design and CS fundamentals#

For Senior and above, design is where offers are won or lost. For juniors, substitute the CS-fundamentals version at the end of this section.

A framework that works in GitHub's loop:

1. Scope it. Who uses this, core flows, scale. Nail reads vs writes, QPS, data size, and the read/write ratio. Two minutes of real numbers (say 100M repos, 10k webhook deliveries per second, read-heavy) saves you from designing the wrong system.
2. Draw the API. Endpoints, request and response shapes, what is idempotent. GitHub people love a clean API contract because they ship one for a living. Name the status codes.
3. Data model. Stores, access patterns, hot keys. Justify SQL vs NoSQL from the access pattern, not vibes: "Postgres, because I need transactional writes on the delivery record and I query by a few indexed columns."
4. High-level architecture. Clients, services, queues, caches, storage. Keep it simple first, one box per responsibility, then add complexity only when you have named the pressure that forces it.
5. Scale and failure. Where does it break at 10x? What happens when a node dies, a queue backs up, a region goes down, the customer endpoint is slow? Talk idempotency keys, retries with backoff, backpressure, and what you shed when overloaded.
6. Tradeoffs out loud. There is no right answer, there is a defended answer. Every time you pick something, name what you gave up to get it.

Classic prompts in GitHub-flavored loops:

• Design the pull request notification system (fan-out on write vs read, dedupe so one person is not pinged five times, mute/subscribe state).
• Design CI/CD job scheduling like GitHub Actions (job queue, pool of runners, fairness across orgs so one customer cannot starve the rest, isolation between jobs).
• Design a webhook delivery system (at-least-once delivery, retry with exponential backoff, ordering guarantees, a dead-letter queue for endpoints that stay down).
• Design a rate limiter for the public API (token bucket vs sliding window, per-user and per-IP, where the counter lives so it is consistent across servers).
• Design code search across millions of repos (inverted index, sharding by repo, keeping the index fresh as commits land, ranking results).

Here is a simple webhook delivery sketch to anchor one of these.

For junior pipelines, expect CS fundamentals instead. Be ready across four areas.

• OS. Processes vs threads, deadlock and the four conditions for it, how a mutex works, what a context switch actually costs you.
• DBMS. Indexes, what a B-tree index buys you on a range scan, normalization and when you would denormalize on purpose, ACID, when an isolation level like read-committed vs serializable actually bites.
• Networking. TCP vs UDP and why you would pick each, what happens step by step when you type a URL and hit enter, common HTTP status codes, TLS basics.
• OOP and low-level design. Design a parking lot, a rate limiter class, a URL shortener. Draw the classes, show the interfaces, and say where you would extend it later and which change you deliberately made easy.

6Behavioral and culture fit#

Do not sleep on this round.

• GitHub is remote-first and writing-heavy, so how you collaborate is a real technical skill to them, not a soft extra.
• Strong coders get a "no" purely because the behavioral round made them sound like someone who needs a meeting to make any decision.

What their values translate to in practice:

• Developer-first, shipping, collaboration, and operating transparently and async.
• The read: they want people who write clearly, make decisions in the open where the team can see the reasoning, disagree respectfully without needing to win, and do not block on a synchronous meeting for everything.
• In a behavioral round, the listen is for whether you would be a good async teammate nobody has to chase.

Prepare 6 to 8 STAR stories, each with real numbers:

• A conflict with a teammate.
• A project you led.
• A failure and what you changed afterward.
• A call made with incomplete information.
• Something you improved that nobody asked you to.

One full worked STAR example:

Situation: Our deploy pipeline was flaky, roughly 1 in 5 deploys failed on a transient test, and the team had started re-running blindly instead of reading the failure. Task: I owned CI reliability that quarter, so getting the failure rate down was on me. Action: I pulled 60 days of CI logs, clustered the failures, and found 70% came from three tests with real race conditions, not infra. I fixed two myself, paired with the owner on the third, and added a quarantine lane so a known-flaky test couldn't block a deploy while being fixed. I wrote it all up in a public issue so the team could follow the reasoning and challenge it. Result: Deploy failure rate dropped from 19% to 3% in six weeks, and we cut about 8 engineer-hours a week of re-running and babysitting.

Why that story is the full package for GitHub:

• Ownership, data over guessing, collaboration, writing in the open, and a hard number.
• It says "I" for the parts you did and "we" for the outcome, so the interviewer can tell exactly what was yours.
• Vague "we did X" stories with no personal ownership and no numbers die in this room.

7Your prep plan#

4-week plan

• Week 1: 15 LeetCode mediums on arrays, hash maps, strings. Refresh Big-O until stating complexity is automatic. Clean up your GitHub profile and rewrite your resume bullets to carry a metric each.
• Week 2: Trees and graphs, 15 problems including topological sort and BFS/DFS. Start one system design per day, sketching the classics above until the framework is muscle memory.
• Week 3: Mock interviews with a human, out loud, in a shared editor. 2 system design mocks where someone pushes back on your tradeoffs. Write your 8 STAR stories.
• Week 4: Mixed timed sets. Re-drill your weakest pattern specifically, not the ones you already like. Re-read the GitHub values and map each one to a story you can tell.

2-week plan

• Days 1 to 5: 20 mediums across hash maps, strings, trees, graphs, talking out loud on a timer.
• Days 6 to 9: 4 system design walkthroughs (PR notifications, Actions scheduling, webhooks, rate limiter). CS fundamentals block if junior.
• Days 10 to 12: 3 mocks, STAR stories written down and said out loud at least once each.
• Days 13 to 14: Light review, sleep, logistics check (camera, editor, quiet room, "why GitHub" answer).

2-day crash plan

• Day 1 AM: 6 mediums, focus on hash maps and graphs. PM: read 3 system design writeups, sketch each once from a blank page.
• Day 2 AM: 1 full mock out loud, ideally with another person. PM: write 5 STAR stories, read GitHub's values, prep your "why GitHub" answer and 3 sharp questions to ask the interviewer.

8Why people get rejected at GitHub#

1. Silent coding. Solved it, said nothing for ten minutes. In a remote, async culture that reads as "cannot collaborate," because the whole job is thinking out loud in writing.
2. No product sense. Could not explain why a design choice matters to a user or a developer. "I would cache this" without "because this read is hit 50 times for every write" lands flat.
3. Hand-waved tradeoffs. Picked a database or a queue and could not defend it when pushed once. One good "it depends, and here is the specific thing it depends on" beats a confident wrong answer every time.
4. Sloppy code. Bad names, 60-line functions, no tests, no edge cases. At a code-review company this is a culture flag, not a nitpick, because the interviewer is imagining reviewing your real PRs.
5. Weak behavioral answers. Vague "we did X" with no personal ownership and no numbers. If I cannot tell what you did versus the team, I cannot give you credit.
6. No GitHub fluency. Never used Actions, could not describe a good PR review, did not know the product. It signals you want a job, not this job, and the gap shows up in minute one of "why GitHub."

At a company that reviews code for a living, how you work is the thing being interviewed.

9The offer, comp and negotiation#

Comp is backed by Microsoft, so it is structured: base salary, an annual bonus, and Microsoft RSUs vesting over time. Realistic 2026 ranges:

• US Senior: ~$190k to $250k base, $280k to $420k total.
• US SWE II: ~$130k to $165k base, $160k to $230k total.
• India: Senior ~₹45L to ₹80L total, mid ~₹25L to ₹45L (Bengaluru/Hyderabad).
• UK (London): Senior ~£85k to £120k base, £110k to £160k total.
• Canada: Senior ~C$160k to C$210k base, C$210k to C$300k total.

Negotiation tips that work here:

1. Push on base and RSUs together, not just base. The equity line has the most room, especially at Senior and above, and RSUs are the growth lever since Microsoft stock is what compounds over your vest. A recruiter who cannot move base much can often move the stock grant more.
2. Bring a competing offer or a real market number. Specific beats emotional. "I have an offer at X total" or "comparable Senior roles are landing at Y" moves a recruiter far more than "I was hoping for more." Have the number written down so you say it cleanly.
3. Negotiate the level, not just the money. If you are borderline between SWE II and Senior, getting leveled up is worth more than a signing bonus over two years, and it resets your base, bonus target, and RSU band all at once. Make the case with concrete scope from your STAR stories, the projects where you owned the outcome end to end.

Want this turned into a dated, week-by-week plan around your actual interview date? Map your rounds to the calendar and start with your weakest pattern first.