14 Essential GitHub Interview Questions *

Looking for freelance jobs? Design your lifestyle as a freelancer with Toptal.

Submit an Interview Question

[Developer Leadership] Which branches can be set as the main branch in a repository, and how is the main branch special? How do you keep a repository’s branches tidy?

By default, master is the main branch. Historically, the gh-pages branch was also treated specially, but not any more.

Any branch can be made the main branch in a repository. All that’s special about the main branch is that it is the default one that will be checked out when a repository is cloned, and the default one where pull requests will be sent.

To keep branches tidy you can delete the ones that are entirely merged into the default branch on the Branches settings page.

[Developer Leadership] GitHub provides three options when merging a pull request: Create a merge commit, Squash and merge, or Rebase and merge. When might you want to use each?

Using the Squash and merge option is a good way to preserve a tidy main branch history. Atomic commits are often useful when developing a feature or fixing a bug, but are not always necessary when merging the finished work into the main branch. However, one should really only use Squash and merge when the work being pulled forms a truly cohesive whole.

The Rebase and merge option is also good for a tidy commit history, as some maintainers want to preserve atomic commits made while building a feature, but find merge commits noisy or otherwise unsightly. However, after a Rebase and merge, it may be problematic to merge in any further work done in the feature branch. This may not be a problem, as one can always simply start a new feature bug-fix branch if any issues arise in the merged code.

When in doubt, Create a merge commit is always a fine, safe option. Though it creates an additional commit that some may see as unnecessary, the atomic commits and their hashes will be preserved from the branch.

[Operations] What do you need in order to have a command-line script take an action on behalf of a user (e.g., to clone a repository as part of a continuous deployment task) when the user’s account is protected with two-factor authentication?

You can use a personal access token. You should use a unique, well-documented token for each script so that they can be revoked and regenerated separately, if necessary.

Apply to Join Toptal's Development Network

and enjoy reliable, steady, remote Freelance GitHub Developer Jobs.

Apply as a Freelancer

[Operations] GitHub has integrations for a wide range of tools, but say you wanted to log—in your custom system—each new commit that a developer pushes to your repository. How would you go about that?

GitHub provides APIs with REST and GraphQL layouts.

The need in this question could be met simply by polling either of those APIs, but a proper implementation should use GitHub’s webhooks to trigger an action at some endpoint in your system.

[Development] When you use a repository’s SSH URL to push a commit to GitHub, you do not have to provide your username and password on each push. How does GitHub know that it’s you?

There are two parts to this:

  1. Each machine that you use GitHub from will have access to a private key that is connected to your account.
  2. GitHub uses the commit’s email address, which is set either on a local repository level, or globally across repositories on a given machine.

[Development/Operations] What are some benefits and limitations of hosting an application using GitHub Pages?

Some benefits are:

Limitations include:

  • No server-side computation. (This is a limitation but not a strict downside as it enforces separation of concerns for your truly static assets.)
  • No control over caching, authorization, or any other HTTP headers
  • Various soft limitations that make it potentially unsuitable for commercial applications.

[Developer Leadership] What are the options for a code reviewer’s response? For each option, explain when a reviewer would use it.

The options are Accept, Comment, or Request Changes. The way these options are used is specific to an organization’s agreed-upon procedures, but generally speaking:

  • Comment is for when more discussion is needed or there is no explicit verdict. It’s there to leave unresolved feedback.
  • Accept means that there are no changes needed, or only minimal changes that do not require further review.
  • Request Changes is generally meant to signify that there are changes needed in order to accept the commit, and that the review should be resubmitted after those changes are made.

For more information, see GitHub’s “Reviewing proposed changes in a pull request” help document.

[Project Management] There are a number of ways to use GitHub as a part of your client engagement strategy.

Say you are starting a project using Agile methodology. You intend to do work in iterations with regular client feedback sessions. Which GitHub tools could you use, and how would you explain the purpose of those tools to your client?

There are a range of answers that could be provided here, but the answer should definitely mention issues. Issues are for more than bug reports. Developers can use issues to track and share progress on individual units of work. Discussion on those units can happen asynchronously within the issues as well. The client should know that the work will be specified in these issues, and what the expectations around communication should be within the issues.

Additionally, the answer could mention the strengths and weaknesses of each of the projects and milestones features.

A project can be used to plan out and prioritize the work to be done in a given iteration, potentially across repositories.

A milestone can be used to group and prioritize related issues within a given repository. An advantage of milestones is the ability to set expected dates, though projects provide organization and tracking of issues by status. An interviewee may also mention other tools that integrate with GitHub, such as ZenHub, which add features like velocity tracking.

Note that some project owners have differing opinions about whether clients should be invited into the actual internal development planning and tracking tools, or whether there should always be some intermediate project planning communication tools that don’t go into technical detail. That disagreement is okay. This question is meant to serve both as a thought exercise, and to elicit the interviewee’s feelings toward the matter.

[Project Management] You are starting a project where you want to keep the code private. Organizational accounts are free for open source projects, while private repositories for personal accounts are free. For many projects, it is sufficient to start with a private personal repository. When or why might you want to migrate to a paid organizational account?

The main reasons are around team size or administrative flexibility. You can have collaborators on your personal private repositories, but only up to a certain number of collaborators.

Beyond that amount, you have to upgrade your account. However, a personal account upgraded to have unlimited collaborators is still cheaper than an organizational account.

One of the primary advantages of an organizational account is that you have more fine-grained control over repository access and account security.

Also important is that you can share the administrative burden: For personal repositories, only the owner may alter the repository settings. Organizations can be configured for other team members to be administrators as well.

[Development] What are some steps you can take to ensure the security of your GitHub account?

There are a number of approaches here, but worthwhile candidates will at least mention setting up two-factor authentication (2FA). The candidate may also note that 2FA can be configured as a requirement for organizational collaborators as well.

Other things that may be mentioned are:

  • Getting rid of unused key pairs for your account
  • Ensuring the security of machines that have key pair access to your account
  • Minimizing and regularly reviewing the access tokens and deploy keys connected to your account

GitHub has a number of recommendations as well.

[Development] How would you close an issue from a commit? Why else might you refer to an issue from a commit?

Mention Closes #... anywhere in the commit message, where ... is replaced by the issue number within the repository. If the issue is in a different repository than the commit is being made to, use Closes username/repository#... in the commit message.

Any time a user refers to an issue from a commit message, GitHub links to the commit directly from the issue it mentions. Using mentions can be useful as a way of building an easily traversable “paper trail” of related or affected commits.

[Developer Leadership] What are some of the differences between the Git Flow and GitHub Flow branching patterns? How does GitHub enable the latter?

There are a variety of answers that could be given here, but some things that should probably be mentioned:

  • Git Flow is organized around releases, where there is potentially a significant amount of work in development at any given time that hasn’t been approved for production. On the other hand, GitHub Flow assumes that the main branch is always ready for deployment.
  • In GitHub Flow, there is no strict separation between your main branch and your development branch. This makes things like hotfixes redundant, because a hotfix branch is just another branch off main.
  • Good development practices around code review and automated testing should be followed regardless of branching pattern but are of particular importance when adopting GitHub Flow. This is because they increase confidence that a particular change won’t wreak havoc on the production branch. GitHub helps with this by encouraging developer adoption of these good practices in two ways: It makes branching and pull request discussions easy and transparent to project participants, and it incorporates continuous integration tools into pull requests.
  • Using GitHub does not require the use of the GitHub Flow workflow, nor does it prohibit Git Flow, or any other branching workflow.

[Project Management] You are working on a project that is split across a few private repositories. You are contracting some aspects of the project out to a consulting firm with a few engineers who will need access to the project’s repositories. How would you manage access for those engineers while preserving the privacy of the rest of your repositories?

You can add collaborators from outside of your organization directly to a repository.

However, it may be better to create teams, as you can administer membership in teams separately from team repository access. Team members are added as members of your organization, so it is important to think carefully about access privileges across the organization overall. For example, in the Member privileges settings, you may want to change the base permissions for an organization member to None, and then add relevant teams to each repository as needed.

[Developer Leadership/Project Management] What is a feature that GitHub provides to ensure high-quality issues are submitted to your repositories?

Github provides issue templates for repository or organization managers to lay out a specific structure that should be followed when someone submits an issue.

Other things that may help:

  • Contributor guidelines
  • Generally coherent documentation about where contributions are needed and how they should be made

But often nothing is as good as someone who is familiar with the project and the practices walking a new contributor through the process.

There is more to interviewing than tricky technical questions, so these are intended merely as a guide. Not every “A” candidate worth hiring will be able to answer them all, nor does answering them all guarantee an “A” candidate. At the end of the day, hiring remains an art, a science — and a lot of work.

Submit an interview question

Submitted questions and answers are subject to review and editing, and may or may not be selected for posting, at the sole discretion of Toptal, LLC.

* All fields are required

João Dias Barbosa

Freelance GitHub Developer

PortugalToptal Member Since February 4, 2014

João is a passionate iOS and Android developer with strong attention to detail that has yielded great apps. He has delivered many projects for millions of users, for both startups and big companies, and he's worked extensively on the back end and API integrations. He has a very positive attitude and works well both alone and on teams.

Show More

David Braun

Freelance GitHub Developer

United StatesToptal Member Since January 22, 2014

David is a senior software engineering generalist with blockchain and security experience. With two years of management training and strong communication skills, he excels at bridging business requirements with modern technology. His EECS degree from U.C. Berkeley is evidence of his technical depth. David's current passion is building on his experience as a leader to maximize team effectiveness through industry best practices.

Show More

Aleksandar Tomislav Markovic

Freelance GitHub Developer

SerbiaToptal Member Since July 27, 2015

Aleksandar has been a software developer for about 5 years now, doing everything from Assembler programming to web development and, more recently, Android development. He has done work for companies like Sony Mobile, Plantronics, and Bottle Rocket Studios, and his communication skills combined with solid development work make him a useful asset to any project.

Show More

Looking for GitHub Developers experts?

Looking for GitHub Developers experts? Check out Toptal’s GitHub developers.

Toptal Connects the Top 3% of Freelance Talent All Over The World.

Join the Toptal community.

Learn more