People complain about the coding tests at interviews. I don't think it's as big of a deal as people say. Treat it like a social skill or any of the myriad other unrelated things you are evaluated for at an interview and spend some time practicing.
I think for a reasonable programmer, yes, you are probably going to have to practice your whiteboard interview.[1] But no, it's not that hard, and it's pretty standardized, so you don't have to practice differently at each company you interview.
I personally think that practicing for the programming test is usually way easier than the social test... and I think the programming test is less biased than the social test.
on the other side of the fence, I think it's a good failsafe. Yes, it will fail many qualified people who don't practice, but it will also fail a lot of people who talk a good game but can't code their way out of a wet paper bag.
Overall, I think it's a great counterbalance to how overvalued confidence is at most interviews.
[1]I personally think that you should use one of the screen share programs designed for this; I like https://codepad.remoteinterview.io/ but anything that reduces the amount of handwriting required is going to vastly reduce your false negative ratio without impacting your false positive ratio (unless you code using whiteboards at your company)
> I think it's a good failsafe. Yes, it will fail many qualified people who don't practice, but it will also fail a lot of people who talk a good game but can't code their way out of a wet paper bag.
I don't. I do R&D for a living and have next to no time to relearn those types of undergrad programming techniques because it doesn't apply to the work I do at all. Ask me to create a model for a system, implement a classifier that hits 90% in a way that no one has ever done before and publish a paper on it, I can do that. Ask me about a breadth first search on some tree and I'll look at you blankly. It seems a bit ridiculous that some of my cookie-cutter engineering colleagues(some that relied on me to help them with homework) can make it into places like Google but I can't make it past the 3rd or 4th interview. I can also assure you that none of my colleagues where I work could make it past that same stage of interviews despite having a PhD and despite them being great researchers.
I think I said that it's turning down a bunch of people who are unwilling to practice.
And yes, turning down people who are unwilling to spend a week practicing is a cost... it could be a very big cost if someone else has a intake filtering procedure that allows them to snatch those people up at a lower cost, but it's also a really effective way of filtering out the people who can't learn those things after a few weeks of practice, which is super important.
Can't. I clearly said can't. It's irrelevant to my work and my work consumes all the time I can give to work before I burnout.
> but it's also a really effective way of filtering out the people who can't learn those things after a few weeks of practice, which is super important.
What's your source on that? Can I see the stats that say neglecting more talented engineers so that you don't have to deal with subpar engineers is better than having a larger amount of more talented engineers while having to intermittently deal with subpar engineers? We have brilliant engineers where I work and the average and subpar engineers are in and out inside of a month or two. Didn't seem to hurt us at all in being the leader in our industry.
"Hire easily, fire easily" is another strategy, it's true! but not one used by most places I've worked. It is a slower strategy when sorting through a pool of mostly not good enough candidates, and often makes employees more nervous (Just like how you "Can't" take three weeks off to practice, other people "Can't" get fired after a few months on a new job.)
I think for a reasonable programmer, yes, you are probably going to have to practice your whiteboard interview.[1] But no, it's not that hard, and it's pretty standardized, so you don't have to practice differently at each company you interview.
I personally think that practicing for the programming test is usually way easier than the social test... and I think the programming test is less biased than the social test.
on the other side of the fence, I think it's a good failsafe. Yes, it will fail many qualified people who don't practice, but it will also fail a lot of people who talk a good game but can't code their way out of a wet paper bag.
Overall, I think it's a great counterbalance to how overvalued confidence is at most interviews.
[1]I personally think that you should use one of the screen share programs designed for this; I like https://codepad.remoteinterview.io/ but anything that reduces the amount of handwriting required is going to vastly reduce your false negative ratio without impacting your false positive ratio (unless you code using whiteboards at your company)