On the other hand, I personally cannot code properly while someone is conceptually "breathing down my neck". A for loop sure, but I'd probably fail at writing a hash table or whatever despite nearing 10 years of experience on many different projects, including compiler frontends and a simple garbage collector I wrote for the fun of it.
Not hiring them is better than a bad hire.
If it were me, I would not use Hackerrank, Leetcode, or other online puzzles sites. Instead it would be just a conversation in to just show me your open source contributions in large repositories or you building projects (open / closed) that others are using.
That is it.
For contributions, they must be under public code review or you doing the review and for open source projects they shouldn't be hello world / test projects but useful to others which are used as dependencies in other larger open-source projects.
A basic easy conversation that rids of 95% of cheaters and frauds and those who cannot code.
Also, how do you even know if it's the candidate that has developed the code? You simply don't know if the candidate copy-pasted the code.
Secondly, just because someone cheated at an extremely difficult Leetcode problem doesn't in any way mean that they can't code on the job. Jobs hardly require such problems.
Instead, ask the candidate to explain specific parts of your code that you show them. It can also be cheated, but it has both a screen and a voice input component, so cheating would take more work.
Declare a variable with any number type initialized to the value 0. I’ve seen candidates fail that, spend 30 minutes attempting to declare a variable in the LANGUAGE OF THEIR CHOICE.