In my experience, as a former candidate, I have met bad interviewers who deliberately focus too much on syntax and like nitpicking candidates knowledge on libraries while they attempt to implement or solve a problem for which they openly admit afterwards that they do not use and go far to secretly record candidates struggling. I even met some 'engineers' claimimg that they are senior in C++ and I brought up LLVM in the conversation and they had no clue on what that was. Likewise for 'JavaScript experts' having no idea about JavaScript engines such as V8, JavaScriptCore and SpiderMonkey.
I don't usually go technical in these interviews but only when asked and before that, I research their open-source contributions to ask relevant questions. Unfortunately, Most of these engineers had little to no open-source contributions or have only private (Obviously work related) which is very unfortunate.
As an interviewer, I have ultimately done away with take-home projects unless candidates are expecting something out of it (I used to pay all second stage candidates for their projects) otherwise it becomes a waste of their time if they are not considered.
Instead, I ask them about relevant open-source contributions to significant projects which is more or less a straight-forward free pass to a on-site interview and at the same time already eliminates beginner/intermediate level candidates. Which I go slightly technical on those patches as if I was conducting a code review. If the candidate is honest and everything matches up, I'll hire them on the spot and that is it. If I find that the candidate is suspiciously dishonest, That is the only time I will give a problem to solve without interrogating them.
By doing this I don't even need to waste money on Hackerrank/Leetcode/Codility tests which are useless in finding competent software engineers.