I disagree. I give live coding tests. I very much don’t want the candidate to be stressed. I provide a written and verbal description of the (simple) problem, and provide unit tests. And I talk them through it if they run into problems, but try to give them space to work it out.
I’m not sadistic. I want to see if they can write code.
The few times I skipped the live test because of practical reasons or they were “too senior” I absolutely regretted it.
Is this a serious question? What interview, a meeting specifically to scrutinize someone and compare them to their peers, isn’t stressful for candidates?
fully agree. we’re actually reintroducing live coding interviews into our process because so many candidates made it onsite who then showed that they didn’t really know how to code
I don’t think anyone disputes that, it’s just that nobody has come up with anything better.
Take home exercises were a potentially better option (though they definitely have other big downsides) but they aren’t a sensible choice in the age of AI.
Just taking people’s word for it is clearly worse.
Asking to see people’s open source code is unfair to people who don’t have any.
The only other option I’ve heard - which I quite like the sound of but haven’t had a chance to try - is to get candidates to do “live debugging” on a real world bug. But I expect that would draw exactly the same criticisms as live coding interviews do.
You mention lots of options. Given people are varied, and you want that in a company, how about letting the candidate decide how to prove themselves? It’s pretty established that it’s not “fair” to stick to a single style, so why hang on to that?
Interesting. What do you think happened with those you didn’t test? You think they were making stuff up or senior at their job is a far cry from senior at your job?
Not sure. One seemed either incredibly timid or just way in above his head on simple tasks. I assigned him a bug and had already narrowed it down to a particular return code, in a particular call tree. He could have set 20 breakpoints and found the bug in five minutes. Or put unique error codes and found the bug in ten minutes.
But weeks later he was still asking questions and eventually just moved on without solving the bug or even finding the cause.
Maaaybe he would have aced the live coding test, but I doubt it. He just never seemed to “get it” and I think the live test would have reflected it.
But by “senior” i mean decades of experience. No quibbling about job titles.
I disagree. I give live coding tests. I very much don’t want the candidate to be stressed. I provide a written and verbal description of the (simple) problem, and provide unit tests. And I talk them through it if they run into problems, but try to give them space to work it out.
I’m not sadistic. I want to see if they can write code.
The few times I skipped the live test because of practical reasons or they were “too senior” I absolutely regretted it.
You seem to be disagreeing with something that isn’t the main point of the article.
That you take those steps doesn’t mean candidates aren’t stressed, despite your intentions.
Sorry an interview is stressful to candidates?
Is this a serious question? What interview, a meeting specifically to scrutinize someone and compare them to their peers, isn’t stressful for candidates?
Fuck yes, and that’s just a regular one.
fully agree. we’re actually reintroducing live coding interviews into our process because so many candidates made it onsite who then showed that they didn’t really know how to code
The article isn’t saying don’t check, it’s saying that live coding interviews are a bad measure.
I don’t think anyone disputes that, it’s just that nobody has come up with anything better.
Take home exercises were a potentially better option (though they definitely have other big downsides) but they aren’t a sensible choice in the age of AI.
Just taking people’s word for it is clearly worse.
Asking to see people’s open source code is unfair to people who don’t have any.
The only other option I’ve heard - which I quite like the sound of but haven’t had a chance to try - is to get candidates to do “live debugging” on a real world bug. But I expect that would draw exactly the same criticisms as live coding interviews do.
What would you do?
You mention lots of options. Given people are varied, and you want that in a company, how about letting the candidate decide how to prove themselves? It’s pretty established that it’s not “fair” to stick to a single style, so why hang on to that?
Interesting. What do you think happened with those you didn’t test? You think they were making stuff up or senior at their job is a far cry from senior at your job?
Not sure. One seemed either incredibly timid or just way in above his head on simple tasks. I assigned him a bug and had already narrowed it down to a particular return code, in a particular call tree. He could have set 20 breakpoints and found the bug in five minutes. Or put unique error codes and found the bug in ten minutes.
But weeks later he was still asking questions and eventually just moved on without solving the bug or even finding the cause.
Maaaybe he would have aced the live coding test, but I doubt it. He just never seemed to “get it” and I think the live test would have reflected it.
But by “senior” i mean decades of experience. No quibbling about job titles.