As someone with plenty of experience on both sides of the table, I can't see this article as anything but misguided.
I indeed use a single (and original) take-home coding challenge instead of whiteboarding during an interview. Let's look at it this way...
If you ever come across an interview process for a coding position where the candidates never need to code as part of the hiring process...run.
A take-home coding challenge has less pressure attached. Would you rather do in 20 minutes, with a bunch of interviewers staring at you, or would you rather do it at your own pace, in your own environment, where you can give it your best?
Would you rather work on yet another version of "fizz buzz" during the interview, or tackle something legitimately interesting and unique that (seriously, according to all my candidates) takes no more than an hour or two?
Actual field experience has proven: take-home coding challenges are one of the best, fairest, and most objective means of evaluating the technical skills of a candidate. Everyone can talk the talk, but you must have a way of evaluating who can actually do the work.
(Yes, we have simple-but-effective ways of making sure the person really wrote the code.)
Side note: one also research jobs, applies for jobs, and interviews for jobs on their own time. It isn't unfair for one to do a coding challenge on one's own time too. If someone really doesn't want to bother, then that's fine - there are plenty of people who care enough about the position enough to use a couple hours of their Minecraft time to complete a coding challenge. (For cryin' out loud, we have over two dozen sites where people complete coding challenges for FUN.)
I see a lot of articles complaining about the hiring process, but honestly, until one has actually interviewed dozens of candidates, made a few mistakes in the process, and seen how one's hiring choices panned out, one doesn't have much basis to make as definitive statements as found in many articles like this.
Actually, if we were to take all the "complaining about the hiring process" articles at face value, we'd be hiring the first Joe Bloggs who applied for the position, and giving gift cards as consolation prizes to everyone else who didn't get the job (seriously, that WAS one article's suggestion).
The hiring system as a whole can certainly be improved, but a lot of the unpleasantness is due to our having to screen for people who talk big, but don't have the skills to match. They show up in every batch of candidates, for every job posted, every time. (Yes, there are people with no coding skills whatsoever who apply for senior development positions.)
Same thing here, I've been an interviewee and an invervieer many times in the past.
As much as I like seeing a sample of candidate's code, I disagree that this is a fair thing to do. It's ok to give an assignment on a later step in the process, but it's never a good option to give it as an initial filter.
Well, we may just be coming from different backgrounds, then. I've learned the hard way, it is a critical part of the interview process. Granted, this is after I phone interview them, but I will never hire without it. In fact, no successful hiring manager I've ever known will; the ones that skip it invariably wind up with extensive mishires.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
As someone with plenty of experience on both sides of the table, I can't see this article as anything but misguided.
I indeed use a single (and original) take-home coding challenge instead of whiteboarding during an interview. Let's look at it this way...
If you ever come across an interview process for a coding position where the candidates never need to code as part of the hiring process...run.
A take-home coding challenge has less pressure attached. Would you rather do in 20 minutes, with a bunch of interviewers staring at you, or would you rather do it at your own pace, in your own environment, where you can give it your best?
Would you rather work on yet another version of "fizz buzz" during the interview, or tackle something legitimately interesting and unique that (seriously, according to all my candidates) takes no more than an hour or two?
Actual field experience has proven: take-home coding challenges are one of the best, fairest, and most objective means of evaluating the technical skills of a candidate. Everyone can talk the talk, but you must have a way of evaluating who can actually do the work.
(Yes, we have simple-but-effective ways of making sure the person really wrote the code.)
Side note: one also research jobs, applies for jobs, and interviews for jobs on their own time. It isn't unfair for one to do a coding challenge on one's own time too. If someone really doesn't want to bother, then that's fine - there are plenty of people who care enough about the position enough to use a couple hours of their Minecraft time to complete a coding challenge. (For cryin' out loud, we have over two dozen sites where people complete coding challenges for FUN.)
I see a lot of articles complaining about the hiring process, but honestly, until one has actually interviewed dozens of candidates, made a few mistakes in the process, and seen how one's hiring choices panned out, one doesn't have much basis to make as definitive statements as found in many articles like this.
Actually, if we were to take all the "complaining about the hiring process" articles at face value, we'd be hiring the first Joe Bloggs who applied for the position, and giving gift cards as consolation prizes to everyone else who didn't get the job (seriously, that WAS one article's suggestion).
The hiring system as a whole can certainly be improved, but a lot of the unpleasantness is due to our having to screen for people who talk big, but don't have the skills to match. They show up in every batch of candidates, for every job posted, every time. (Yes, there are people with no coding skills whatsoever who apply for senior development positions.)
Same thing here, I've been an interviewee and an invervieer many times in the past.
As much as I like seeing a sample of candidate's code, I disagree that this is a fair thing to do. It's ok to give an assignment on a later step in the process, but it's never a good option to give it as an initial filter.
Well, we may just be coming from different backgrounds, then. I've learned the hard way, it is a critical part of the interview process. Granted, this is after I phone interview them, but I will never hire without it. In fact, no successful hiring manager I've ever known will; the ones that skip it invariably wind up with extensive mishires.