I have witnessed a huge range of anxiety levels from candidates and when you get used to interviewing it is pretty clear what comes down to anxiety and what comes down to simply not being able to program.
When a candidate struggles, I gently lead them and help move things along in a very collaborative way - I am also very tolerant of mistakes or poor starts and proactively give every opportunity for those to be discounted.
If somebody, after 10 hints as to the ordering of the if/else if/else of fizzbuzz, still cannot figure it out when you have held their hand for 30 minutes that's not because you lack interview skill.
Interviewing is inevitably vastly imperfect and many aspects that are not relevant to the job will play a role (for example - time constraints dictate that you must ask small questions that are sufficiently challenging that might not always be entirely representative of the job) - nobody who is honest could claim otherwise, but that is the nature of the task - it has to be an approximation - and you have to asssess actual ability to code and do the job.
You calling them a liar eh?
Conducting a full interview “without letting things get confrontational” is difficult. However, unless the job actually requires intense face to face confrontation you want to know how well they can do the job, not how well they can interview for it.
I don't think a candidate who I put at ease then absolutely hammered would compliment me on putting them at ease would they? Or does your theory stretch to them somehow having short-term memory loss?
If the second group preformed better then presumably the testing methodology played a role with a higher percentage of people being able to actually program than your suggesting.
Granted it takes a lot of interviews to build a reasonable sample, but we aren’t talking about 1% better performance here.
I've tried both. I've tried leaving them to it entirely, I've tried leaving them to it then if they get stuck helping both from a lesser to a greater degree.
It really makes no difference - the bad coders struggle on that and other problems, they just lack the ability to think through the problem.
And again I've seen enough anxious candidates to see the difference. I'm pretty good at gauging things well as to how and when to help.
Overall I'm not hearing many specifics more 'I am great at interviewing'.
The empirical evidence is overwhelmingly that there are many bad programmers out there with long CVs. That's also my experience WITHIN companies, though a lesser proportion.
In terms of a test I use mean, median, mode, and range for an array. Then go into basic performance trade offs.
The best advice I can give is look at how entertainers get random audience members to relax and engage in front of huge audiences. Many people lock up in such situations and can barely say their own name, yet with the right approach it’s a non issue.
Compare that to the rapid fire technical questions I have watched people get into and it’s obvious what’s going on. Someone fumbles something and then gets flustered and shuts down. But, pepper the exact same questions into a larger conversation, perhaps going so far as to occasionally complement them, and shockingly they do better on the exact same problems.