FizzyOrange

I doubt this will fly in the UK. They are legally required to implement "highly effective" age verification, and that definitely rules out AI and probably face recognition (pornhub doesn't support that for example). It's going to be credit card checks all round, yeay.

The only rule you need is: preserve history that is worth preserving.

99% of the time, that means you should squash commits in a PR. Most commits should be small enough that they don't need more fine grained history than one commit.

I will grant a couple of exceptions:

1. Sometimes you have refactorings where you e.g. move a load of files and then do something else.. Or do a big search and replace and then fix the errors. In these cases it's nice to have the file moves or search/replace in separate commits to a) make review easier, b) make the significant changes easier to see, and c) let git track file moves reliably.
2. Sometimes you have a very long lived feature branch that multiple people have worked on for months. That can be worth keeping history for.

Unfortunately, if you enable merge queues on GitHub it forces you to pick one method for all PRs, which is kind of dumb. We just use squash merges for everything and accept that sometimes it's not the best.

Not really because I've never seen a setup that requires every commit in a branch to compile and pass tests. Only the merge commit needs to.

Also if your PR is so big that it would be painful to bisect within it, then it should be broken into smaller PRs.

Stock ctrl-r is kinda shit but you can make it a lot better with McFly or Atuin.

I don't think anyone disputes that, it's just that nobody has come up with anything better.

Take home exercises were a potentially better option (though they definitely have other big downsides) but they aren't a sensible choice in the age of AI.

Just taking people's word for it is clearly worse.

Asking to see people's open source code is unfair to people who don't have any.

The only other option I've heard - which I quite like the sound of but haven't had a chance to try - is to get candidates to do "live debugging" on a real world bug. But I expect that would draw exactly the same criticisms as live coding interviews do.

What would you do?

I don't have a particular story. A lot of industries use "competency based questions", you know "tell us about a time when...".

They're awful. If you don't know what I'm talking about count yourself lucky.

Which would you rather, "write some code to filter off numbers from a list", or "tell us about a time when you worked with someone difficult. How did you win them over and subsequently become best friends?".

No it has very significant differences to Git beyond the CLI.

It is no secret that git’s interface is a bit too complex

Right but that's mostly because the CLI is a mess, not because the fundamental data model is bad.

Some bad interview questions are like that, sure. But they're supposed to be things you are very unlikely to have done before and can reasonably figure out. It's not too hard to come up with simple questions like that. (Though I will grant many people don't seem to bother.)

IMO this is not a helpful way to put it. They measure skill under stress. Stress may have a large effect on skill level for some people but highly unlikely that it's so large that performance is completely random.

You don't know how good you've got it. The hiring process in other industries is much worse.

On a university network.