GitHub interview process (2026)
Round-by-round breakdown of the GitHub software engineering interview across 3 levels and 15 rounds: what each round covers, what interviewers evaluate, sample questions, and preparation tips.
Software Engineer II — India (Remote)
Difficulty: Medium · Timeline: ~4-6 weeks · Recommended prep: 4-6 weeks
-
Round 0: Recruiter screen
Phone · ~30 min
Focus: Background, motivation, remote-first fit, logistics
A 30-minute call on your background, why GitHub, and how you work in a remote-first, async setup (GitHub India is remote-first with Bengaluru/Hyderabad hubs; expect some timezone-overlap discussion with US/EU teammates). Covers role level, comp expectations and the process ahead. A Feb 2025 SWE II candidate also had a short standard LeetCode-style online question to clear before the recruiter chat.
What they evaluate: Interest, communication, comfort with remote/async collaboration; not a technical filter.
Tips: GitHub cares about written communication — keep your GitHub profile and any open-source contributions handy; recruiters do look at them.
-
Round 1: Take-home exercise (coding + code review)
Assessment · ~3-5 hrs (300-min window) · difficulty 3/5 · elimination round
Focus: Practical coding in a real repo, unit tests, PR hygiene, code review
GitHub's signature screen, not a LeetCode OA. You get access to a small real-world service repo (one reported instance: an ASP.NET Core web API) for 300 minutes. Part 1 (coding): understand the codebase, implement a feature against intentionally vague requirements, fix/add unit tests, and open a PR with a clear description. Part 2 (code review): review a provided pull request and leave written comments. Two engineers grade each submission independently.
What they evaluate: Code quality and tests over cleverness; commit history, branch management and README/PR write-up are explicitly part of the score. Requirement-reading matters — a reported reject came from misreading the spec.
Sample question: Part-1 style task: the service needs request throttling. Implement a sliding-window rate limiter — given a limit of N requests per W-second window and a stream of request timestamps (non-decreasing), decide ALLOW or DROP for each request. Input: N W Q, then Q timestamps. Output one line per request.
Tips: Read the requirements twice before writing code — the spec is vague on purpose. Budget your 300 minutes: ~30 min reading the repo, code in small commits with messages, leave time to fix tests and write the PR description. In the review part, comment on correctness, tests and readability, not style nits.
-
Round 2: Pairing exercise (live coding + code review)
Onsite · ~60 min · difficulty 3/5
Focus: Pair programming, collaboration, navigating unfamiliar code, code review
A 60-minute session with two GitHub engineers on the same codebase as your take-home — roughly half pair-programming a small extension, half walking through a code review together. Modeled on day-to-day work at GitHub: you drive, share your screen in your own dev environment, and think out loud. Implementation-style problems with multiple subparts also show up in technical screens (a Feb 2025 SWE II day included building a game of battleship).
What they evaluate: How you collaborate: asking clarifying questions, taking hints, narrating trade-offs, and writing working code in front of people.
Sample question: Implementation exercise in the reported battleship flavor: given an n x m board where 'X' marks ship cells and '.' water, ships are straight horizontal/vertical lines and no two ships touch, count the number of ships in a single pass. Input: n m, then n rows. Output the count.
Tips: Set up your editor, repo and screen-share beforehand. Treat interviewers as pairing partners — verbalize your plan before typing, and in the review half, anchor comments to concrete bugs/tests rather than opinions.
-
Round 3: Technical interview (implementation + API/product)
Onsite · ~45-60 min · difficulty 3/5
Focus: Practical implementation, HTTP/APIs, debugging, product thinking
Second technical session on the virtual interview day (Feb 2025 SWE II loop: two technical interviews plus one culture round). Practical rather than algorithmic: reported questions include setting up HTTP calls against an API, small design-and-implement tasks, and live problems with multiple subparts on a 45-min screen. Expect follow-ups on error handling, retries and testing.
What they evaluate: Real-world engineering: can you consume/build an API cleanly, handle failures, and reason about the product impact of your choices.
Sample question: Write a small client for a paginated HTTP API (GET /repos?page=N returning JSON with items and next_page). Handle rate-limit 429 responses with retry-after and exponential backoff, and aggregate all items. Walk through your error handling, timeouts and how you would unit-test it without hitting the network.
Tips: Brush up HTTP semantics (status codes, idempotency, pagination, auth headers) and mocking strategies for network code — this round rewards engineers who have shipped API integrations, not puzzle grinders.
-
Round 4: Leadership principles + culture (incl. D&I)
Behavioral · ~60 min (+30 min D&I) · difficulty 2/5
Focus: Collaboration, growth mindset, remote communication, inclusion
Final stretch: an hour with two GitHubbers on leadership behaviors — growth mindset, teamwork, handling disagreement and feedback — plus, in many loops, a separate ~30-minute diversity-and-inclusion conversation about building inclusive, belonging-first teams. Async-friendly written communication and empathy in code review come up repeatedly.
What they evaluate: Culture add for a remote-first company: self-direction, clear async communication, how you support teammates and handle conflict across timezones.
Tips: Prepare STAR stories about unblocking teammates asynchronously, disagreeing respectfully on a PR, and mentoring. For D&I, have a genuine example of making a team or community more inclusive — canned answers stand out badly.
Software Engineer III — India (Remote)
Difficulty: Medium · Timeline: ~4-6 weeks · Recommended prep: 6-8 weeks
-
Round 0: Recruiter screen
Phone · ~30 min
Focus: Background, level mapping, remote logistics
Standard 30-minute intro: your experience, target level (GitHub uses SWE I/II/III, then Senior/Staff — different ladder from parent Microsoft), location and comp. GitHub India roles are remote-within-India with Bengaluru/Hyderabad presence; clarify timezone-overlap expectations for your target team.
What they evaluate: Fit for level and role; communication.
Tips: GitHub's process is distinct from Microsoft's — do not expect the Microsoft L61/L62 loop. Ask which team and which rounds your loop will have; loops vary by org.
-
Round 1: Take-home exercise (coding + code review)
Assessment · ~3-5 hrs (300-min window) · difficulty 3/5 · elimination round
Focus: Feature work in an unfamiliar repo, tests, PR quality, review judgment
Same two-part format as all GitHub SWE loops, graded to a mid-level bar: 300 minutes in a real service repo — implement a feature from a loosely specified issue, repair and extend the unit-test suite, open a well-written PR; then review a provided PR in writing. Two engineers evaluate independently; commit hygiene, branch management and the README count toward the score.
What they evaluate: Whether you can ship production-quality change in unfamiliar code: scoping vague requirements, test coverage, clean diffs, and substantive review comments.
Sample question: Warm-up in GitHub's own domain: a commit DAG is given as parent edges. Find the merge-base of two commits — the nearest common ancestor (as git merge-base does). Input: n m, then m lines "child parent", then two commits a b. Output the merge-base commit id, or -1 if none.
Tips: Mid-level submissions are judged hardest on judgment: what you chose NOT to build, edge cases you tested, and how readable the PR is. Timebox exploration; a working slice with tests beats an ambitious half-finished feature.
-
Round 2: Pairing + code review (with DSA/LLD flavor)
Onsite · ~60-90 min · difficulty 4/5
Focus: Pair programming, code review, data structures, low-level design
Live session with two engineers: extend the take-home codebase or a similar service while pairing, then dissect a PR together. An India SDE-2 full-stack loop reported this technical block as DSA + low-level design — expect to structure classes/modules cleanly and justify data-structure choices while you code, not whiteboard-only LLD.
What they evaluate: Collaboration under review: incorporating feedback in real time, spotting a planted bug or race condition in review, and clean object/module design.
Sample question: Code-review exercise: you are shown a PR that adds an in-process cache to a hot API path. The diff has a check-then-act race between contains() and get(), no TTL/eviction, and a test that asserts on timing. Identify the issues, rank them by severity, and propose the fix you would request before approving.
Tips: Practice reviewing real open-source PRs out loud. Lead with the highest-severity issue (correctness under concurrency), suggest concrete fixes (atomic get-or-compute, bounded LRU with TTL), and say what tests you would require.
-
Round 3: System design (HLD)
System_design · ~60 min · difficulty 4/5
Focus: Distributed systems, API design, queues/retries, data modeling
High-level design round reported in India SDE-2 loops. GitHub-flavored prompts play to their domain: webhook delivery, notifications, CI job scheduling (Actions), or collaboration features. Interviewers push on delivery guarantees, retries/idempotency, storage schema and scale (millions of repos, high fan-out events).
What they evaluate: Structured design: requirements first, clear APIs, sensible data model, and honest trade-off reasoning; senior-of-your-level depth on one or two components.
Sample question: Design GitHub's webhook delivery system: repos register endpoint URLs for events (push, PR, issue). Deliver events at-least-once with HMAC signing, per-endpoint ordering, exponential-backoff retries for failing endpoints, dead-lettering after N attempts, and a redelivery UI — at the scale of millions of active repositories.
Tips: Study GitHub's own engineering blog (webhooks, Actions, MySQL sharding) — interviewers recognize their domain. Nail idempotency keys and retry/backoff math; call out the noisy-endpoint isolation problem unprompted.
-
Round 4: Hiring manager + leadership/D&I
Behavioral · ~60-90 min total · difficulty 2/5
Focus: Ownership, remote collaboration, conflict resolution, inclusion
Closing block: a hiring-manager conversation (project deep-dive, team fit, product thinking, your questions) plus the leadership-principles discussion with two GitHubbers and a short D&I conversation. India SDE-2 loops reported distinct HM and HR rounds; content overlaps — ownership, disagreement handled well, working across timezones.
What they evaluate: Impact and ownership at mid-level, mentoring signals, and whether you communicate like a good remote teammate (clear, written-first, empathetic).
Tips: Bring one project you can go three levels deep on — architecture, trade-offs, measured impact. Have a crisp story about a code-review disagreement you resolved without escalation.
Senior Software Engineer — India (Remote)
Difficulty: Hard · Timeline: ~4-6 weeks · Recommended prep: 8-10 weeks
-
Round 0: Recruiter + hiring manager screens
Phone · ~30-45 min each · difficulty 1/5
Focus: Scope, level calibration, team fit
Senior loops reported on Blind open with an HR screen followed by a hiring-manager screen before any technical loop. Expect calibration on scope (leading projects vs people), the specific team (platform, Copilot, Actions, security), and remote-within-India logistics.
What they evaluate: Whether your experience matches Senior scope; motivation and communication.
Tips: Senior at GitHub means driving multi-quarter work and raising the bar in review — frame your background that way from the first call.
-
Round 1: Technical screen (live coding / Codility)
Assessment · ~45-60 min · difficulty 3/5 · elimination round
Focus: Practical coding, implementation problems with subparts, debugging
Reported entry filter for senior loops: either a Codility-style online screen or a 45-minute live phone screen with an engineer — implementation-based problems with multiple subparts (build up a small utility, then extend it), not hard algorithm puzzles. Some senior loops get the standard take-home instead; ask your recruiter which applies.
What they evaluate: Fluency: clean working code fast, sensible decomposition as requirements grow, and testing instincts.
Sample question: Build a tiny in-memory file-system API in stages: (1) mkdir/addFile/ls with path validation; (2) add file contents and a find(pattern) walk; (3) add size accounting per directory. Each stage builds on the last — keep the design extensible as subparts land.
Tips: Practice incremental-implementation problems (design-a-class kata) rather than LC hards. Keep functions small so the next subpart drops in without rewrites.
-
Round 2: Pairing + code review
Onsite · ~60-90 min · difficulty 4/5
Focus: Pair programming in a real codebase, review leadership, mentoring signals
The collaborative core of the loop, senior bar: pair with two engineers extending a service codebase, then lead a code review discussion. As a senior you are expected to drive — set the plan, surface risks (concurrency, migrations, backwards compatibility) and coach rather than just comment.
What they evaluate: Bar-raising review: catching subtle correctness issues, weighing them against ship pressure, and communicating feedback a junior author would thank you for.
Tips: Show review leadership: summarize the PR's intent first, separate blocking from non-blocking feedback, and propose the smallest safe path to merge.
-
Round 3: System design + architecture deep-dive
System_design · ~60-75 min · difficulty 5/5
Focus: Large-scale distributed design, storage, real-time collaboration, past-system depth
The decisive senior round per Glassdoor/Blind reports: one open-ended design at GitHub scale plus a deep-dive where you explain a system you built while a senior interviewer probes how deep your knowledge really goes. GitHub-scale prompts: hosting millions of repos and billions of commits, PR/merge workflows, CI at scale, real-time collaboration.
What they evaluate: Depth over breadth: storage and consistency choices you can defend three follow-ups deep, honest ownership of past design mistakes, and operating experience (on-call, migrations, incidents).
Sample question: Design the pull-request service for a GitHub-scale code host: diff computation and storage for large repos, merge-conflict detection, mergeability checks that stay fresh as base branches move, review state, and required status checks — for millions of repositories with hot monorepos. Then: walk through the hardest system you have built and its worst production incident.
Tips: Prepare your own system's story to incident-level detail — the probing is real. For the design, know git internals (packfiles, refs, merge-base) enough to make storage choices credible.
-
Round 4: Leadership principles + D&I
Behavioral · ~60 min (+30 min D&I) · difficulty 2/5
Focus: Technical leadership, mentoring, remote-first collaboration, inclusion
Final block with two GitHubbers on leadership: influencing without authority, growing engineers through review, handling disagreement across timezones, and shipping through ambiguity; plus a ~30-minute diversity-and-inclusion conversation. One senior loop also included a wrap-up with a programs/director-level leader.
What they evaluate: Senior leadership behaviors: multiplying the team, judgment under trade-offs, and authentic commitment to inclusive, remote-first collaboration.
Tips: Quantify leadership: engineers mentored to promotion, review culture you changed, incidents you turned into process. For D&I, concrete actions beat philosophy.
Other companies' interview processes
Worked sample solutions (code, design diagrams, and STAR answers) for every round are available in the FAANGPlus app: open interview processes.