GitHub Take-Home Interview: The Timed Pull Request & Interview-bot

Last updated: November 2026

Quick Answer

The GitHub take-home is a timed coding exercise in a private repository created by a GitHub app called Interview-bot. You pick a language, work in your own editor or Codespaces, and submit a pull request. Actions runs the tests, your name is stripped from the PR, and an engineer scores it against a rubric, then clicks Approve (pass) or Request changes (fail). Rehearse the follow-up walkthrough in OphyAI Interview Practice.

Part	What is known
Setup	Interview-bot copies files, issues and PRs into a private repo (GitHub blog)
Time limit	Not published; candidates report 2-5 hours
Submission	One pull request
Review	Anonymized; per-language engineer, rubric, scorecard
What follows	Walkthrough, extension or PR review round (reported)

What GitHub Is Testing in This Round

GitHub’s engineering blog says it wants the technical interview “as similar as possible to the way we work at GitHub,” with problems that “aren’t problems to trick or test obscure knowledge.” The reviewer judges your PR the way a teammate would:

• Working code. The Actions test run is the reviewer’s baseline.
• Reading the brief. The repo ships with issues and pull requests, not just a README. Reported tasks include a file storage and retrieval API with unit tests and a CRUD-style task (2021, candidate-reported).
• The write-up. Blind posts summarized by a prep site say reviewers look at “code quality, edge cases and the write-up” (candidate-reported).
• Scope judgment. GitHub says the time limit exists so the exercise does not favor candidates “who have more time to invest in the solution.”

Red flags that fail candidates:

• Failing tests with no note explaining why.
• An empty or one-line PR description.
• Ignoring an issue in the repo, or solving a different problem.
• Gold-plating while the core requirement is half done.

The GitHub interview guide covers the other stages; this page covers only the pull request round.

What to Expect

GitHub’s 2022 post describes the flow:

1. You choose a language and get an email inviting you to sign in to Interview-bot whenever you are ready.
2. Interview-bot copies the exercise into a new repo (a copy, not a fork, so Git history is removed). You get access and the timer starts.
3. You clone locally or open Codespaces, with any editor and tooling. Using the internet for documentation is expected.
4. You open a pull request; Interview-bot detects it by webhook and confirms receipt.
5. The PR is copied back with the title removed and Interview-bot shown as author.
6. A reviewer reads the Actions results and rubric, posts a scorecard comment, and marks it Approve or Request changes. Interview-bot then notifies the staff member who follows up.

GitHub has not published the limit. Glassdoor reviewers describe a suggested 2 hours with the repo open for 5, and a hard 5-hour cap; a Taro reviewer reports 4 hours (candidate-reported, 2020-2021). Waits for results run from days to over two weeks. One Taro reviewer was sent a PR to review before the onsite (2019).

Example Questions and How to Answer Them

The exercise is not public. These are prompts candidates report after submission, plus one you answer in the PR itself.

1. “Walk me through your pull request.”

Approach: One sentence on the problem, then the change in the order a reviewer reads it, then your tests. Point to the commit where the key decision lives.

2. “What would you change with another day?”

Approach: Name two improvements you left out on purpose and why the time box cut them. It shows the cut was a choice.

3. “Extend your solution to handle a new requirement.”

Approach: Restate it, say which module it touches, and talk through the change before typing. If a refactor comes first, say why.

4. “Review this pull request as if a teammate wrote it.”

Approach: Description, then tests, then diff. Rank findings (bug, security, maintainability, style), suggest fixes, and say what earns your Approve.

5. The PR description: “What changed, why, and what is left?”

Approach: Four headings: Summary, Approach and assumptions, Testing, Next steps. The reviewer reads this before your code.

How to Prepare in 3 Days

• Day 1: one timed run. Pick a small file storage or CRUD task with failing tests. Set a 3-hour timer, commit in small steps, open a real PR with the four-heading description, and stop at the bell.
• Day 2: review yourself. Read your PR cold, then review two open-source PRs in writing. Compare approaches in OphyAI Coding Interview; in the desktop app it runs as Coding Copilot (Premium, 15 credits a session) and shows the code, a dry run with edge cases and the Big O.
• Day 3: rehearse the walkthrough. Run a technical mock in OphyAI Interview Practice, which asks follow-ups and gives per-answer feedback. Confirm the time limit and stack with your recruiter, and block the full window before you sign in.

Start practicing →

Common Mistakes

• Starting without the full block free. The timer runs from repo access.
• Reading only the README. The issues are part of the brief.
• One giant commit. Reviewers judge the diff like a colleague’s.

Related Guides

• GitHub interview guide (all stages, pay and timeline)
• Rippling take-home assignment interview
• Stripe technical phone screen interview
• Technical interview prep for software engineers

Frequently Asked Questions

How long is the GitHub take-home interview?

GitHub has not published a time limit; its blog says only that one exists so the exercise does not favor people with more free time. Candidates on Glassdoor and Taro report 2-5 hours, including a suggested 2 hours with 5 available. Confirm the current limit with your recruiter before you start.

What is Interview-bot?

Interview-bot is the GitHub app GitHub’s engineers built to run the take-home. It creates your private repository from a base exercise, starts the timer, detects your pull request through webhooks, copies it back anonymized, and notifies the staff member who follows up once a reviewer approves or requests changes.

Is the GitHub take-home reviewed anonymously?

Mostly. GitHub’s blog says the pull request is copied back with the title removed and commits attributed to Interview-bot, so reviewers see an anonymized ID, done “as best as it can.” Keep your name and personal links out of code comments and the PR description.

What happens after the GitHub take-home?

If the reviewer approves, a staff member contacts you about the interview stage. Candidates report a walkthrough of the PR, a request to extend it, or a separate PR to review, alongside system design and behavioral rounds. Candidate reviews say rejections usually come without detailed feedback.

How does OphyAI work for the GitHub take-home?

Interview Practice runs technical mock interviews with follow-up questions and per-answer feedback, which suits the walkthrough round. Coding Interview runs as Coding Copilot in the desktop app on Premium: it reads a problem from your screen and shows the code, a dry run with edge cases and the Big O in an overlay left out of screen sharing.

Sources and verification notes

Checked November 2026. Glassdoor returned 403; its details come from search summaries of individual reviews. GitHub has not published the time limit, rubric or exercise.

• GitHub Blog, “How GitHub does take home technical interviews” (Andy McKay, March 2022, updated May 2022): Interview-bot steps, anonymization, tests, rubric, quotes. First-party.
• GitHub Careers, Experienced Professionals: tool-based assessment as stage three. First-party.
• Glassdoor, GitHub interviews: 2 and 5-hour limits, tasks, slow follow-up. Candidate-reported.
• Taro, GitHub interview experiences: 4-hour assignment, PR review before onsite. Candidate-reported.
• Calibrd, GitHub take-home: Blind summaries on reviewer focus and an extension round. Third-party.