From interviewer's perspective, I enjoy doing live coding. It gives me an opportunity to not only see the candidate's coding skills, but also to understand their thought process, and to see their communication skills - can they explain me how they plan to solve the problem? If they get stuck, can they explain me what is the issue?
In order to make this process as comfortable for candidates as possible, I asked them to either bring their own laptop, or tell me they preferred language and IDE so that I could prepare it for them; we used a laptop + large TV, so that I didn't have to sit behind the candidate, they were looking on the laptop and I could see the code on the 2nd screen; candidates could use any online tools available when writing code.
It worked for some candidates, and it worked quite well. I must admit though - there were cases where people I knew people failed because they were stressed. I had one candidate literally look at me scared and say "oh, you're going to sit here and watch me coding?!". So I agree with you that this is not a great way to test candidates. Being good at live coding is not the same as being good at software development.
Eventually I think the take-home exercise (+ a follow-up discussion during live interview as next step) was a good balance between giving candidates environment that allows them to show their best skills, and my need to evaluate their skills and to determine whether we should be working together. You're right that these exercises might take some time, but it's an investment on both sides - my team prepares the exercises, we review the code, talk to the candidate, finally if we reject the candidate we provide written feedback on what went wrong. I think it's a fair deal - both sides invest some time (and I always check with candidates how much time they took to complete the task, so that I can limit the scope for the next candidates if I underestimated the required effort).
From interviewer's perspective, I enjoy doing live coding. It gives me an opportunity to not only see the candidate's coding skills, but also to understand their thought process, and to see their communication skills - can they explain me how they plan to solve the problem? If they get stuck, can they explain me what is the issue?
In order to make this process as comfortable for candidates as possible, I asked them to either bring their own laptop, or tell me they preferred language and IDE so that I could prepare it for them; we used a laptop + large TV, so that I didn't have to sit behind the candidate, they were looking on the laptop and I could see the code on the 2nd screen; candidates could use any online tools available when writing code.
It worked for some candidates, and it worked quite well. I must admit though - there were cases where people I knew people failed because they were stressed. I had one candidate literally look at me scared and say "oh, you're going to sit here and watch me coding?!". So I agree with you that this is not a great way to test candidates. Being good at live coding is not the same as being good at software development.
Eventually I think the take-home exercise (+ a follow-up discussion during live interview as next step) was a good balance between giving candidates environment that allows them to show their best skills, and my need to evaluate their skills and to determine whether we should be working together. You're right that these exercises might take some time, but it's an investment on both sides - my team prepares the exercises, we review the code, talk to the candidate, finally if we reject the candidate we provide written feedback on what went wrong. I think it's a fair deal - both sides invest some time (and I always check with candidates how much time they took to complete the task, so that I can limit the scope for the next candidates if I underestimated the required effort).
Great to hear that. I hope you switch to sort take-home assignments for future candidates.