How to assess · For hiring teams

How to Assess Git Skills When Hiring

The test formats that actually work for Git, what a strong answer looks like, sample questions and a scoring rubric you can use as-is.

The short answer

Assess Git with a task, not a conversation: recovery exercise, history-hygiene task, ai-scored assessment (e.g. cohesyve) or workflow conversation. Score it against written criteria you fix before you see any submissions, and weight the criteria that the role actually depends on.

  • Understands commits as snapshots, branches as pointers, and what the index is for
  • Writes commits that are small, focused and described so history is readable
  • Rebases and merges deliberately, knowing what each does to history and when each is appropriate
  • Recovers from mistakes: reflog, reset, revert, restoring a lost branch

Paste a job description; Cohesyve generates a role-specific assessment and rubric. Ten candidates free, no card.

Git is on every résumé and the source of a surprising amount of lost work: a force-push that erased a colleague's commits, a merge that silently dropped a change, a history so tangled nobody can find when a bug was introduced. The skill worth testing is not command recall. It is understanding the model — commits, branches, the working tree and the index — well enough to get out of trouble and to keep a shared history useful. This page covers how to assess Git for any engineering role: the mental model, day-to-day workflow, recovery, and collaboration habits.

Why Git is worth testing

Git mistakes are usually recoverable by someone who understands the model and unrecoverable by someone who does not. The cost is not only lost work; it is the time senior engineers spend untangling histories and the fear that stops juniors from rebasing or bisecting. A ten-minute exercise reveals whether a candidate is comfortable, and comfort with Git correlates with a lot of other engineering habits.

What strong Git looks like

  • Understands commits as snapshots, branches as pointers, and what the index is for
  • Writes commits that are small, focused and described so history is readable
  • Rebases and merges deliberately, knowing what each does to history and when each is appropriate
  • Recovers from mistakes: reflog, reset, revert, restoring a lost branch
  • Resolves conflicts by understanding both sides, not by picking one
  • Uses bisect, blame and log effectively to investigate
  • Respects shared history: no force-pushing to shared branches, protected mains, reviewed changes

Ways to assess Git

Recovery exercise

Provide a repository with a lost commit after a bad reset, a branch that was deleted, and a conflict to resolve. Ask the candidate to recover everything and explain how. Twenty to thirty minutes.

Pros

Tests the model directly; recovery is the skill that matters.

Cons

Needs a prepared repository.

Best for Any engineering role.

History-hygiene task

Give a messy feature branch with ten commits including fixups and typos. Ask for a clean history ready for review, and the reasoning.

Pros

Tests interactive rebase and judgement about what a reviewer needs.

Cons

Narrow; combine with recovery.

Best for Mid-level and above.

AI-scored assessment (e.g. Cohesyve)

Generate a Git scenario from the job description — a recovery, a workflow design, a conflict question — with a rubric. Each candidate receives a different variant; reasoning is scored in writing.

Pros

Asynchronous and consistent; unique per candidate; the model is testable in prose.

Cons

No hands-on; confirm with a short practical.

Best for Screening as part of a broader assessment.

Workflow conversation

Ask how they would set up branching, review and release for a team of eight, and what they would do when someone force-pushes to main.

Pros

Reveals collaboration habits and judgement.

Cons

Talk-based.

Best for Senior engineers and leads.

Cohesyve

Run a Git assessment on your next opening

Cohesyve generates a unique Git task per candidate from your job description, with the scoring rubric attached. Questions are different for every applicant, so they cannot be shared or looked up.

What to test

The model

Whether they understand what Git is doing.

Explain what a branch isDescribe the difference between the working tree, index and HEADExplain what a detached HEAD means and how to get out

Recovery

Whether they can get out of trouble.

Recover a commit after a hard resetRestore a deleted branchUndo a merge on a shared branch safely

History and review

Whether their history helps others.

Squash fixups into logical commitsWrite a commit message that explains whyFind the commit that introduced a bug with bisect

Collaboration

Whether they keep shared work safe.

Resolve a conflict correctlyExplain when to rebase and when to mergeDesign branch protection for a team

Sample Git questions

What is the difference between `git reset` and `git revert`?

Entry

Look for Reset moves the pointer and rewrites; revert adds a commit that undoes; use revert on shared history.

You ran `git reset --hard` and lost a commit. Get it back.

Entry

Look for Reflog, find the commit, reset or cherry-pick to it.

When would you rebase a branch, and when would you not?

Mid

Look for Rebase local or unshared work for a clean history; never rewrite shared branches; merge for integration.

A bug appeared somewhere in the last two hundred commits. Find it quickly.

Mid

Look for Bisect with a test, ideally automated.

Someone force-pushed to main and erased a day of commits. What do you do?

Senior

Look for Recover from reflog or another clone, restore, then add protection and talk about why it happened.

Red flags

  • Cannot explain what a branch is
  • Resolves conflicts by picking one side blindly
  • Force-pushes to shared branches
  • Has never used reflog
  • Commits with messages like "fix" and "wip" on shared history

Scoring rubric

CriterionWeightWhat strong looks like
Model understanding30%Can explain what commands do to commits, pointers and the index.
Recovery30%Gets out of trouble calmly and correctly.
History quality20%Commits are focused and explain why.
Collaboration20%Shared history is protected; workflow is deliberate.

Mistakes hiring teams make

  • Testing command flags instead of the model
  • Skipping Git because "everyone knows it"
  • Not including a recovery exercise
  • Accepting a messy history because the code works
  • Ignoring collaboration habits

Roles that need Git

Software EngineerFrontend DeveloperBackend DeveloperDevOps EngineerData EngineerTechnical Writer

Common questions

Is it worth assessing Git separately?

A short recovery exercise, yes. It takes fifteen minutes and reveals whether a candidate understands the tool every engineer uses all day. Poor Git skill costs the whole team.

What is the best single Git question?

Ask them to recover a commit after a hard reset. It tests the model, reflog and composure together.

Should I test a specific workflow like GitFlow or trunk-based development?

Ask what they have used and why. Understanding the trade-offs matters more than allegiance to one.

How much Git should a junior know?

Commit, branch, merge, resolve a conflict, and recover from a simple mistake with reflog. Interactive rebase and bisect are mid-level.

Cohesyve · Skill assessments for hiring

Test Git before the first interview

Generate a role-specific Git assessment from your job description and see who can do the work before you spend interview time on them.

1,500+

assessments completed

50%

faster time-to-hire

90%

completion rate

5 min

from JD to assessment

No credit card · 10 free candidates · Plans sized to your hiring volume

See Cohesyve in action

Free 30-min walkthrough

See it on your role