GitHub interview, from the take-home pull request to the loop.

The first four steps are GitHub's own, from its careers page, which says the process varies by role. The rounds after the take-home come from candidates. The complaint candidates post most in 2026 is the wait at the end: weeks or months for a decision after the final interviews, and slow background checks.

GitHub's engineering blog describes its take-home in detail (2022): an app called Interview-bot sets up a private repository, you choose the language, a timer starts, and you submit a pull request. GitHub's 2026 careers page still lists the assessment step, and candidates this year still describe a take-home and a follow-up on it. The time limit and the exercise change by role, so the items below are how it works and how to do well, not the questions themselves.

• How you receive it: You get an email, choose your language, and get access to a private repository; the timer starts then. Clone it and work in your own editor, or use Codespaces. GitHub's blog says using the internet for documentation is expected. Start only when you have the full time free.
• How long it takes: GitHub hasn't published the current limit. Candidates in 2021 reported three hours, and five hours with a suggestion to spend two. Read the instructions for your limit and plan to finish early enough to write the pull request properly.
• How it is marked: The pull request runs automated tests through GitHub Actions and is marked against a rubric, then approved or sent back with Request changes, which is a pass or a fail. Reviewers see it anonymised. Employees say they look at code quality, edge cases and the write-up, and whether the pull request makes sense.
• Write the pull request a reviewer can approve: Get the tests passing, then explain what you changed, the assumptions you made, what you left out and why. An employee's advice is a comprehensive pull request explaining your changes and assumptions. Small, clear commits help too.
• Prepare for the follow-up: Candidates in 2026 describe an interview about the submission, and one was asked to extend it. Know your trade-offs, and have a short list of what you would improve with more time.
• Ask about AI tools first: GitHub's postings ask engineers to use tools such as Copilot at work, but nothing public says whether they are allowed in the take-home. Ask your recruiter before the timer starts.

GitHub's page doesn't list the values its interviewers check, but its exercise and the rounds after it keep testing the same things.

• Working the way GitHub works. The exercise is a real repository and a real pull request, so commits, tests and the description are all part of the answer
• Explaining your changes in writing. Employees advise a pull request description that explains your changes and assumptions; in a remote company, that writing is how work gets reviewed
• Code quality and edge cases. An employee lists code quality, edge cases and an excellent write-up as what a reviewer looks for
• Reviewing other people's code. A 2022 candidate had a round reviewing someone else's pull request and deciding whether to approve it
• Using AI tools well. Postings ask engineers to work with tools such as Copilot; ask whether they are allowed in the take-home before you start

The behavioural questions below follow what GitHub's rounds test; the technical themes follow the exercises candidates describe.

Levels.fyi medians for GitHub software engineers in the United States, read on 8 October 2026; samples per level are small. A 2026 candidate reports that base pay follows geographic zones, with a significant cut outside the top zone, so ask which zone your location falls in. A 2021 commenter called GitHub known for down-levelling offers; check the level before you discuss numbers.

1. Ask your recruiter which steps your role has, the take-home's time limit, and whether AI tools such as Copilot are allowed in it.
2. Start the take-home only when you have the whole time free; the timer starts when you get the repository.
3. Get the tests passing first, then handle edge cases, then write a pull request that explains your changes, assumptions and what you left out.
4. Practise reviewing someone else's pull request out loud: what you would check, and how you would phrase the comments.
5. Practise building a small REST API and an API client with retries and timeouts in your interview language.
6. Prepare one system design about delivering events or webhooks at scale, with how it fails and recovers.
7. Ask which pay zone your location falls in before talking numbers, and check the level of any offer.
8. Expect to wait after the final round. Candidates in 2026 report weeks to months; keep other processes going.

This guide covers GitHub's software engineering hiring. Design and content roles get a different assessment, such as a writing assignment. For management and leadership roles the loop is similar but the bar shifts to people, delivery and strategy, so pair it with the leadership interview prep hub. The bar for your exact role comes from the role-by-role guides, and the prep that actually transfers is spoken, so run a mock interview before the real one.

Also interviewing at Zapier, Atlassian or Canonical? Their guides follow the same format, from the first screen to the offer.

• 01GitHub Careers, Interviewing at GitHubthe talent conversation, the hiring manager conversation, the tool-based assessment (a coding exercise or writing assignment) and the interviews (read 8 October 2026)
• 02GitHub Blog, How GitHub does take-home technical interviews (2022)Interview-bot, choosing the language, the timer, cloning or Codespaces, the anonymised pull request, tests and rubric, Approve or Request changes
• 03GitHub Blog, Technical interviews via Codespaces (2021, updated 2024)a Rails technical screen run in Codespaces, and pairing exercises
• 04GitHub Careers, open roles73 open roles, 56 in engineering, remote in the US, UK and Canada (read 8 October 2026)
• 05Blind, GitHub pair coding round (October 2026)a take-home, a follow-up on it, system design, then pair coding the recruiter said would not be LeetCode style
• 06Blind, GitHub senior interview (September 2026)two coding rounds and system design, one live round building a REST API service
• 07Blind, GitHub senior interview prep (2026)an assessment first, then extending it on site; one commenter reports LeetCode medium to hard
• 08Blind, GitHub take-home (2022)an employee on what reviewers look for: code quality, edge cases and the write-up
• 09Blind, GitHub storage API assignment (2022)an employee's advice: get the tests passing and write a comprehensive pull request
• 10Blind, GitHub onsite (2022)a pull request review round and an API client round against a server that fails on purpose
• 11Blind, GitHub take-home coding test (2021)a private repository, a timer and about three hours
• 12Blind, waiting after a GitHub final interview (August 2026)no decision weeks after the final round, third-party recruiters, a four-week background check
• 13Blind, evaluating a GitHub staff offer (September 2026)base pay by geographic zone
• 14GitHub Blog, Auf Wiedersehen, GitHub (August 2025)GitHub continuing as part of Microsoft's CoreAI organisation
• 15Levels.fyi, GitHub Software Engineer, United Statesmedians by level, read 8 October 2026

Interview processes change. This reflects widely-reported and sourced conditions as of 2026 — confirm specifics with your recruiter, and treat it as a map rather than a guarantee.