What other methods would you see applicable to your candidates? (home assignments, pseudo code tests maybe)
Yeah, those are some of the options. But I don't think there's only one solution for interviewing.
Home Assignments
They have the benefits of giving the candidate some room to breath and take their time to really polish their code, since having someone "breathing" on your shoulder can make them too nervous. But it is not fair for those who have a kids, a second job, college, or just have other interests outside of work.
Pseudo Code Tests
They don't provide enough insight of a particular language feature or functionality. Things like:
Why did you choose to make this final or const?
Can you achieve the same results with a for or a while loop? If so, how? Then why did you prefer x over y in this scenario?
Giving him/her a laptop to code from scratch
It sounds better than having the candidate code on a whiteboard, but we still have the "breathing over your shoulder" issue.
But, this one can also help to test their debugging skills.
It would also require the company to dedicate resources into installing a wide range of tools like IDE/editors, so the candidate can feel somewhat comfortable.
Pair programming with the candidate
This is probably the one I'm most fan of. The interviewer can act as a guide for the candidate. As long as they provide a friendly approach to it. Instead of telling them what is wrong, the interviewer would have to say things like "this can be improved", "do you think we are missing something here?", etc.
Another big one for me is that I like to hear candidate's thought process. I ask them to speak out loud as much as they can so I can guide them through the process.
If the candidate turns out to make code that works but it might be missing some edge cases or could be cleaned up, I like to give them hints to see if they overlooked those details because they felt nervous or in a rush.
Why do you feel guilty about it? Has there been a particularly bad experience with a candidate who did the whiteboard interview?
Personally, I feel that one of the best skills to have is to not only to know the programming language, but also the tools at our disposal. Some may think that a developer who depends too much on their IDE is weak, but I actually consider them to be productive instead.
And I've noticed this with candidates: they get too nervous, they stop their thinking process because they care too much about ending each line with semicolons, every parenthesis, etc. And if they are used to various languages, it can be even worse.
Those are some of the ideas I've considered, but I think I might have missed some details, I guess you can have a general idea of what are the things I look out for :)
Yeah, those are some of the options. But I don't think there's only one solution for interviewing.
Home Assignments
They have the benefits of giving the candidate some room to breath and take their time to really polish their code, since having someone "breathing" on your shoulder can make them too nervous. But it is not fair for those who have a kids, a second job, college, or just have other interests outside of work.
Pseudo Code Tests
They don't provide enough insight of a particular language feature or functionality. Things like:
finalorconst?foror awhileloop? If so, how? Then why did you preferxoveryin this scenario?Giving him/her a laptop to code from scratch
It sounds better than having the candidate code on a whiteboard, but we still have the "breathing over your shoulder" issue.
But, this one can also help to test their debugging skills.
It would also require the company to dedicate resources into installing a wide range of tools like IDE/editors, so the candidate can feel somewhat comfortable.
Pair programming with the candidate
This is probably the one I'm most fan of. The interviewer can act as a guide for the candidate. As long as they provide a friendly approach to it. Instead of telling them what is wrong, the interviewer would have to say things like "this can be improved", "do you think we are missing something here?", etc.
Another big one for me is that I like to hear candidate's thought process. I ask them to speak out loud as much as they can so I can guide them through the process.
If the candidate turns out to make code that works but it might be missing some edge cases or could be cleaned up, I like to give them hints to see if they overlooked those details because they felt nervous or in a rush.
Personally, I feel that one of the best skills to have is to not only to know the programming language, but also the tools at our disposal. Some may think that a developer who depends too much on their IDE is weak, but I actually consider them to be productive instead.
And I've noticed this with candidates: they get too nervous, they stop their thinking process because they care too much about ending each line with semicolons, every parenthesis, etc. And if they are used to various languages, it can be even worse.
Those are some of the ideas I've considered, but I think I might have missed some details, I guess you can have a general idea of what are the things I look out for :)
I only can agree with you on these topics. We tend to recruit potential candidates similar the way you've just described.
Thanks for taking the time to share your thoughts with me! 🙏