Ask Git Questions!

Too many interviews don’t include Git questions! Why are we okay with that? Not knowing Git is a serious handicap in software teams, and I only forgive junior or entry-level programmers for not knowing much about it.

Here you’ll find interview questions I ask about Git, along with summarized answers and why they are important to ask. I urge you to reflect on why the questions are what they are and adjust them in preparation of candidates that saw this page.

I would disqualify anyone applying for a senior role if they cannot answer all of these questions. That is, unless there is a strong mitigating factor like being the CEO’s nephew.

A Quick Aside on Spec Work

A couple of the questions involve small coding exercises with creative input on your part. Do not mix those questions with actual domain knowledge of use to your company. You don’t want to ask something that could turn a candidate’s answer into spec work. Always use dummy examples that your company doesn’t plan to use for anything except for evaluating candidates. It’s only fair.

Question 1

How do you make a new repository and commit your first files?

Answer: Init, add, commit. This should fly off the tongue. If the candidate wants to note transitions from the working directory to the staging area or repository, that’s a good sign. Use that to segue to the next question.

Why ask?: While the candidate’s wheel is spinning, use this to check if the hamster is dead. Any candidate that is not entry-level should answer this question quickly and correctly during a phone screen. I’d be livid if someone applying for a senior role made it to an in-person interview without knowing how to set up a vanilla Git repository.

Question 2

Why do you add changes before committing them?

Answer: So you can “do version control” when you’re ready. You don’t have to know what goes into a commit before making changes.

Why ask?: If the candidate understands the staging area, they likely took time to learn about Git beyond what they memorized to get by in a job.

Question 3

Why is force pushing to master a bad idea?

Answer: You can blow away other people’s work. This will cause a ripple effect where the world stops turning, children scream, and tear-soaked villagers slowly rebuild something that may never be the same because of you.

Why ask?: Obviously you should have protected branches and reasonable permissions so this doesn’t happen in the first place. You ask this question only to make sure the candidate is not the kind of person who pipes curl into sudo.

Question 4

What would you write as a commit message for this change? *show a diff*

Answer: What the change is, and why you are making it.

Why ask?: I like this because the candidate has to read code and communicate. If you are pressed for time, this question can double as another question. Keep the example light and meaningful. For example, you could present a JavaScript diff that fixes a broken promise chain.

- const getProducts = fetch(...).then(() => { new Promise(...) });
+ const getProducts = fetch(...).then(() => new Promise(...));

A bad answer would be “fix promise”. A better answer would be “Return correct Promise from getProducts()”. Try to learn what the candidate feels is the right level of detail in the message. It’s okay—with me, anyway—if the candidate hasn’t memorized details like having a max. 50 character summary line in the imperative tone. If the candidate is impressive, they will add more details than the summary line and have a back-and-forth with you about how they can be sure their commit messages will get read.

Question 5

Could you resolve this merge conflict with me?

Answer: Depends on the merge conflict. You’ll know what you are looking for, and it’s not hard to make a small example.

Why ask?: I love learning by doing. You get a sample of the candidate’s communication skills in a mini-pair programming session, and they get to exercise use of Git while reasoning about a language you expect them to know. Resolving merge conflicts takes shared knowledge, and you need at least a rough idea of how they tap into your team to get it.

I would still ask this of entry-level programmers, even if I don’t expect them to get it right. They need to deal with this at some point, so may as well do it where it’s safe.