October 27, 2026·5 min read
Git sits underneath everything your team does and almost nobody interviews for it. It reads as tooling rather than engineering, so it gets waved through with a line on a CV.
Then a bad merge lands on main. Half a feature disappears, the person who did it cannot explain what happened, and three people spend a morning reading the reflog to work out what the repository used to contain.
That morning is what you are hiring against. It is cheap to test, because Git problems are reproducible: you can hand every candidate the exact same mess.
Not command recall. Nobody needs to know the flags for git log by heart, and a candidate who has them memorised has told you nothing except that they use the terminal.
What matters is narrower:
Four tasks, twenty minutes each, cover all of it.
The setup. Two branches changed the same area in compatible-looking ways. The merge conflicts in one file, and resolving the text leaves the code broken, because one side renamed a function the other side started calling.
Ask: merge these and make sure it is right.
Strong looks like: they read both sides before resolving, and after resolving they run the tests, because a resolved conflict is a guess until something proves it. They notice that the mechanical resolution compiles and is still wrong.
Weak looks like: accepting one side wholesale, or accepting both and moving on because the file now looks reasonable.
Why it works: the dangerous conflicts are exactly the ones where the text merges cleanly enough. This one separates people who treat a merge as a text operation from people who treat it as a code change.
The setup. A commit on main that should not be there, already pushed, already pulled by colleagues. Behind it sit three later commits that are fine.
Ask: remove it, and tell me what the effect is on everyone else.
Strong looks like: they distinguish rewriting shared history from adding a commit that undoes the change. They pick the second one for a shared branch, and they can say precisely why: the first makes every colleague's clone wrong. If they do reach for a rewrite, they say who has to be told and what those people must run.
Weak looks like: a reset and a force push to main, described casually. It works, in the sense that an earthquake works.
Why it works: it is the single most common way a team loses work, and the answer is a judgment about other people rather than a command.
The setup. A feature branch a week behind main, with three commits of its own, one of which is a mess of unrelated changes.
Ask: get this ready to review.
Strong looks like: they bring it up to date deliberately, and they can explain their choice between a merge and a rebase in terms of who else is using the branch rather than in terms of preference. If they rebase, they know that it is fine here precisely because nobody else has this branch. They tidy the commits so the reviewer can read them.
Weak looks like: a pull that creates a merge commit nobody wanted, then a review with forty files and no story. Also weak: rebasing a branch two people are sharing, with confidence.
Why it works: preparing work for review is a daily act and a courtesy, and it is visible in the diff you hand over. The downstream effect is in the CI/CD skills assessment: unreadable history is what makes a red pipeline hard to explain.
The setup. A bug that is present now and was not present a month ago, in a repository with a few hundred commits and a test that reproduces it.
Ask: find the commit that introduced this.
Strong looks like: they automate the search rather than reading commits one at a time. Bisect with the test as the oracle is the obvious route, and searching history for the moment a line changed is a good one too. The strongest candidates say what they will do with the answer: read the commit message and the pull request around it, because the reason for a change matters as much as the change.
Weak looks like: scrolling the log hopefully, or rewriting the broken function without finding out why it was written that way.
Why it works: it is the one Git task that is unambiguously debugging, and it ties to the same habit as how to assess debugging skill: narrow the space systematically instead of guessing.
Four rows, the same for every candidate:
Command fluency is not a row. It is visible, it is learnable in a week, and it is the least predictive thing on the screen.
This only works if every candidate gets the identical repository: same conflict, same shared history, same bug introduced at the same commit. A candidate who gets a slightly different mess is not comparable to the previous one, and a repository they clone themselves drifts the moment anybody pushes.
EasyEnv gives the candidate a box with the repository already in the state you designed, including a remote that behaves like a shared one, so a force push has visible consequences rather than theoretical ones. Boxes are disposable, so destroying the repository is a legitimate thing to do and an interesting thing to watch. The session is recorded, so you can see the order they did things in, which is the whole signal here.
The limits, plainly. Preparing the repository takes an afternoon the first time. This is a twenty to forty minute slice of a wider interview rather than a whole stage. And for a team of two who never share a branch, most of this does not apply: the value scales with how many people touch the same code.
Nobody tests Git until it has already gone wrong. Give the candidate a conflict that merges cleanly and still breaks, a commit that has to come out of a shared main, a branch a week behind, and a bug with an unknown birthday.
If you only run one, run the commit removal. How someone talks about rewriting shared history tells you exactly how much of other people's work they are willing to risk.
Run live coding sessions and take-home challenges in real production environments. Watch sessions back, score consistently, and hire with confidence.
More posts you might like
Most API interviews turn into a style argument about plurals and status codes. The decisions that cost money are elsewhere. Here are four tasks on a running service that test retries, compatibility, pagination and error design, with what a strong answer sounds like.
Substitution is rare, real, and concentrated at the volume end of hiring where nobody meets anybody before the offer. ID uploads and webcam checks mostly inconvenience honest candidates. Here is what actually makes a stand-in impossible, and what it costs.
Read more
A week inside the team answers nearly everything an interview is guessing at, and rules out most of the people worth hiring. Here is when a trial earns its cost, how to structure one that is fair, and what to run instead when it is the wrong tool.
Read more
