Though ideally interviewers should appreciate this - unless its a hard requirement you do it by hand day to day - the rest of us can look this up quick enough.
My OS professor in college once told us about what he considered the difference between "knowledge" and "information", with "knowledge" being the underlying facts about how something works and "information" being the terminology/labeling/bucketing/etc. of how to refer to it. The point he made was that knowledge was more important than information, and that he would try to test us on knowledge rather than information. To me, knowing how the underlying version control model works and what "shapes" you might want to make with it is useful knowledge. The exact set of commands, interactions with an IDE, or specific prompts you can use to ask an LLM to produce them is information. Arguably the entire benefit of LLMs is that you can ask them to do things even if you don't have the exact information memorized; if you can describe it in a rigorous way, and recognize whether what it gives you as an output fits that or not, you don't need to know any of the actual information of how to do it manually.
Because LLMs aren't a reason to not learn your tools. A determinist CLI command vs using a statistical machine for it. It's just a waste of tokens at the very least.
I don't disagree that having a deterministic CLI is useful, but I'd argue that's not the question here, because the CLI is what the statistical machine will be using. The question is whether the time spend doing it manually is worthwhile compared to the tokens spend on it. I'd argue that if you instead learn how to pick the right model for the right job so that you don't use something way more expensive than needed for the task at hand, the token overhead will be extremely minimal for stuff like git operations; knowing that you can use something cheaper than like, Astra or Opus if all you want to do is a quick git cleanup and push is going to save your employer a lot more money in the long run than if you insist on doing every messy rebase by hand.
In terms of team practices, that basically seems like a code review thing. If my team has conventions around git, and a PR doesn't fit them, that's something I would point out regardless of how the PR was generated. If a team member is repeatedly not meeting the expectations we've all agreed upon, I would deal with it in the same way I always have; reach out and offer guidance for how to do things the way they're supposed to, notify my manager if they continue having trouble with it, and eventually just not bother looking at their PRs if they absolutely refuse to do things the way everyone else on the team has agreed they should be done.
One time setup commands are the sort of thing people do once when setting up the repo, but dont use day to day. its understandable that people dont have that memorized and will reach for a man page, google or an AI.
Some 6-figure per year developer spending a quarter’s worth of tokens to do something they do once a month or so is not something I’ll ever care to optimize away…
Personally I ask the LLM to summarise what the commit does and explain it to me, make sure I understand it, then review the PR. I'm getting half the speed the High Speed Sloperators are getting but I was the only person submitting PRs the other day when the LLM service was down.
For nasty multi-way git merges and rebases, it's been a game changer. And of course that's reviewable by doing a delta on the final rebase branch vs. the original branch.
With all that said... having to use LLMs at work is making me want to use them less on my own projects.
we also ask the candidate to open a PR against the repo just to see if they know the basics of git
A candidate may be able to open a PR and not be able to make a commit without an IDE.
Another candidate might know plenty of git, but haven't worked with Github.
I've heard this multiple times now and it still boggles my mind that git is something you have to test for.
This is more about opportunity cost because instead of asking about git, you could ask about other valuable skills in your limited time with the interviewee, but I guess if git is really that important, then it's justified.
not even joking: i've seen people with like 10y of experience trying to push to main :(
How does that work? Git has no concept of pull requests.