There are people who can talk their way out of trouble for sure. That is why I suggested the take home exercise followed by a discussion.
It's only when there's niche knowledge involved that I think it isn't necessary, because you won't be able to answer any hard questions properly without having actually worked on code for that niche at one point or another.
I've been lucky to never have to deal with that. Sucks for everyone that has.
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.
Today, I guarantee you that candidates will eventually take that risk to cheat in the online assessment stage in the hopes of getting an offer from the company and will likely turn into a bad hire.
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.
Not everyone has open source projects to show. Also, for the ones that do, extremely few would be used as dependencies in larger projects, so that requirement is just ridiculous.
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.
That is really grim. I work on rather niche systems engineering stuff so that already serves as a pretty major filter, your average codemonkey won't even bother applying to this sort of stuff.
It's only when there's niche knowledge involved that I think it isn't necessary, because you won't be able to answer any hard questions properly without having actually worked on code for that niche at one point or another.