My experience is that the interviewer can pretty much make or break a technical interview.
I've had interviewers that used them in like they should (get a feel how you solve problems and think, how you communicate, etc.), and I've had garbage interviewers that read a script, with problems they themselves didn't understand.
I know the view on take-home assignments is very polarized, but you know what? The net time spent is usually far, far less than the prepping game for technical interviews. You see people grinding leetcode for hundreds of hours, memorizing problems and solutions, trying to get every edge-case they can - just in case the interviewer throws something obscure at them.
At least with assignments you get a well-defined problem, where you get time to think and reflect, and can work/learn enough to have a meaningful discussion.
Yep, that's exactly what I've tried to communicate here.
I like the idea of take home assignments as well. Maybe the industry will get to a state where these can be done completely remotely (and even graded automatically) in order to determine whom to bring onsite, where you just have a general discussion.
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.
