Why a Weak Git Answer Doesn't Always Mean Rejection

Interview Insights · Git

Why a Weak Git Answer Doesn't Always Mean Rejection

SECTION 01Core Git versus the long tail of commands

Not every Git question carries the same weight. When I interview a fresher or junior developer, I sort Git topics into two groups in my head. The core is what you will use on your first day: cloning, committing, branching, pulling, pushing, resolving a simple conflict and opening a pull request. The long tail is everything you will use occasionally: cherry-pick, bisect, submodules, interactive rebase, worktrees.

A gap in the long tail is normal at the junior level, because you only learn those commands when a real situation needs them. A gap in the core worries me more, because it means daily work will be slow. So if you stumble, the first question is which group the topic belongs to.

Q: How would you use git bisect?

A: I have not used bisect in a project.
I know it helps find which commit introduced
a bug. I think it does a binary search
between a good and a bad commit, and I mark
each step as good or bad. I would read the
docs and try it on a small repo first.

My note: long-tail gap, honest, reasoned. Fine.

Q: You have changed three files. How do you
commit only two of them?

A: I would commit everything and then delete
the third file's changes later.

Interviewer: Is there a way to choose
what goes into the commit?

A: Maybe git push only those files?

My note: core gap. Does not understand
the staging area (git add file1 file2).

If you are unsure whether a topic is core, a safe assumption is this: if you would need it every week on a team, it is core. Spend your preparation time there first.

SECTION 02How to recover in the next two minutes

The moments after a weak answer often matter more than the answer itself. Some candidates go quiet and carry the mistake into every later question. Others bluff and give a confident but wrong command, which is worse, because now I am unsure whether to trust their other answers.

The recovery that works is simple. Admit the gap in one sentence, say what you do know that is nearby, and reason towards an approach. Then move on calmly. If a later question touches the same topic, show that you are thinking about it. I notice candidates who come back and say 'about the stash question earlier, I think it would also help here.'

WHEN YOU BLANK ON A GIT COMMAND

1. Admit briefly:
   "I don't remember the exact command."

2. State the goal in your words:
   "The goal is to save my unfinished changes
    so I can switch branches without committing."

3. Offer what you would do:
   "I could commit them as WIP on my branch and
    amend later, or I think git has a stash
    feature for exactly this."

4. Move on calmly. Do not apologise again.

# Save unfinished work and get a clean tree
git stash push -m "half-done navbar"

# Fix the urgent bug on another branch
git switch hotfix/login
# ... commit and push the fix ...

# Come back and restore your work
git switch feature/navbar
git stash list
# stash@{0}: On feature/navbar: half-done navbar
git stash pop        # apply and remove from stash

# Include new untracked files too:
# git stash push -u -m "with new files"

Notice that the recovery script offers a workaround that really works: a WIP commit on your own branch. Even without remembering stash, that answer shows you understand what Git is for.

SECTION 03Reason from how Git works, not from memory

The best protection against blanking is a small mental model of Git internals. You do not need to know everything. Four ideas are enough. A commit is a snapshot of your files plus a pointer to its parent commit. A branch is just a movable label pointing at one commit. HEAD points to the branch you are on. Most commands either create commits or move labels.

With that model, you can reason about commands you have never used. Cherry-pick? It must take the change from one commit and create a new commit with that change on the current branch. Reset? It moves the label. When candidates reason like this out loud, the weak answer turns into a strong signal of understanding.

# Branches really are tiny files with a SHA inside
git switch -c demo
cat .git/HEAD
# ref: refs/heads/demo

git rev-parse demo
# 4e2c9a1...  (the commit the label points to)

# Note: refs can also be stored in .git/packed-refs,
# so rev-parse is the reliable way to read them.

git log --oneline --decorate -3
# 4e2c9a1 (HEAD -> demo, main) add footer

# A fix was committed on develop. You need it on release.
git switch develop
git log --oneline -3
# b7d31f0 fix price rounding in invoice
# ...

git switch release/2.1
git cherry-pick b7d31f0
# Creates a NEW commit on release/2.1 with the same
# change. It gets a different SHA because its parent
# is different.

# If it conflicts: fix files, git add,
# then git cherry-pick --continue

The detail about a different SHA is exactly the kind of reasoning that comes from the model. You do not need to have memorised it. You can work it out because a commit includes its parent.

SECTION 04A short plan to close your Git gaps

After an interview with a shaky Git answer, the useful move is to close that exact gap quickly. Use this plan over the next two weeks. It focuses on core topics first and keeps each session short.

AFTER EACH INTERVIEW

Git question I struggled with: ________________
Core, middle or long tail?     ________________
What I said:                   ________________
What I should have said:       ________________

Practice step (in a test repo):
______________________________________________

Date I practised it: ________
Can I explain it aloud now? Y / N

WEEK 1: CORE
  Day 1  status, add, commit, staging area
  Day 2  log, diff, show
  Day 3  branch, switch, merge
  Day 4  resolve a conflict on purpose
  Day 5  push, pull, fetch with a remote

WEEK 2: MIDDLE AND TAIL
  Day 6  stash push, list, pop, apply
  Day 7  reset soft, mixed, hard
  Day 8  revert and reflog
  Day 9  cherry-pick between branches
  Day 10 bisect on a small repo

Each day: 20 minutes hands-on,
5 minutes explaining it aloud.

ANSWER ALOUD WITHOUT NOTES

[ ] What does the staging area do?
[ ] What is a branch, technically?
[ ] What does HEAD point to?
[ ] stash pop vs stash apply?
[ ] Why does a cherry-picked commit get a new SHA?
[ ] How would you find which commit added a bug?
[ ] What happens in detached HEAD state?

If any answer is shaky, do that day of the
plan again in your test repo.

SECTION 05Mindset tips for the round after a slip

A weak answer only hurts twice if you let it affect the next questions. These habits keep it contained.

• Treat it as one data point — An interview has many questions. Interviewers form a view from the whole round, so give the next question your full attention.
• Do not over-apologise — One honest sentence about the gap is enough. Repeated apologies make a small gap feel bigger to both of you.
• Show your reasoning — Thinking aloud from the commit and branch model often earns more credit than a quick memorised answer would have.
• Come back if it fits — If a later question connects to your weak topic, mention the link. It shows you are still thinking and learning.
• Close the gap the same day — Practise the command that evening in a test repo. Next time the question comes up, you will answer from experience.

SECTION 06Interview Q&A — Recovering on Git

SECTION 07Test yourself — Recovering on Git quiz

SECTION 08Frequently asked questions

SECTION 09Related reads