I do not enjoy coding interviews and I agree that it's on the developers themselves to fix this problem. However, I disagree with the solution this post promotes.
I have no problem with the initial code screen test. That test is an exchange of your time to prove that the company should provide multiple dev's time to interview you in person. A simple, fair exchange. If you're overbooked due to tons of programming tests, you over extended yourself when accepting to move forward with all of the companies at once. Quality over quantity means choosing the jobs you're most interested in first, and then coming back to others if you're still looking.
My biggest issues with coding interviews is the cookie cutter whiteboarding questions we ask developers to complete. I think whiteboarding is great for showing a candidate truly understands code, but as developers we need to spend more time in choosing the questions. Instead of selecting from a website or a book, we should consider the challenges we have faced in the job recently. Boil that challenge down into its most basic form and create a question for the candidate. Now we have an interview that reflects ability and aptitude for the job at hand.
Even better than whiteboarding is sitting down at a computer and pair programming the problem. That lends itself to the candidate sharing the process they are going through, and limits the intimidation of standing at a whiteboard and being judged by someone you don't know.
Thank you for a high quality response. Honestly. It's refreshing to hear someone who, although disagrees, does so with some effort and thoughtfulness behind their disagreement.
I think, overall, we could probably debate the issues around the tests themselves, how they're implemented, whether I've overextended myself in my example and so on.
You have some great points about how these tests could be properly structured, based on your experience, which I'm inclined to agree with.
I feel that there's a fundamental layer of this whole thing that we don't often talk about, though. The developers who discuss this topic often jump to the "We should or should not have these tests and here's X reasons for why I believe this" and that's fine.
But these kinds of tests were not standard even a few years ago. They're not even standard across the world. To me, that seems to indicate that there's something else going on. Why have these kinds of tests been introduced and why are they becoming normalized? Instead of asking the how, ask the why.
What points/factors led to that first company sitting down and talking about how they can't hire good developers and they end up deciding that a coding challenge (insert your nature of that challenge here) was the way to solve that?
What kind of expectations were broken and by whom? Do developers consistently under perform and lie about their experiences? Do companies consistently set their expectations too high?
It just feels like we're focused on arguing about the tests themselves but we're not focusing very much on the reason they came to be this way in the first place. These tests feel like an answer to a serious problem and I don't know that we're articulating that problem enough to tackle it properly.
Does that, at least, feel somewhat properly directed? Is that something we can agree on?
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.
I do not enjoy coding interviews and I agree that it's on the developers themselves to fix this problem. However, I disagree with the solution this post promotes.
I have no problem with the initial code screen test. That test is an exchange of your time to prove that the company should provide multiple dev's time to interview you in person. A simple, fair exchange. If you're overbooked due to tons of programming tests, you over extended yourself when accepting to move forward with all of the companies at once. Quality over quantity means choosing the jobs you're most interested in first, and then coming back to others if you're still looking.
My biggest issues with coding interviews is the cookie cutter whiteboarding questions we ask developers to complete. I think whiteboarding is great for showing a candidate truly understands code, but as developers we need to spend more time in choosing the questions. Instead of selecting from a website or a book, we should consider the challenges we have faced in the job recently. Boil that challenge down into its most basic form and create a question for the candidate. Now we have an interview that reflects ability and aptitude for the job at hand.
Even better than whiteboarding is sitting down at a computer and pair programming the problem. That lends itself to the candidate sharing the process they are going through, and limits the intimidation of standing at a whiteboard and being judged by someone you don't know.
Thank you for a high quality response. Honestly. It's refreshing to hear someone who, although disagrees, does so with some effort and thoughtfulness behind their disagreement.
I think, overall, we could probably debate the issues around the tests themselves, how they're implemented, whether I've overextended myself in my example and so on.
You have some great points about how these tests could be properly structured, based on your experience, which I'm inclined to agree with.
I feel that there's a fundamental layer of this whole thing that we don't often talk about, though. The developers who discuss this topic often jump to the "We should or should not have these tests and here's X reasons for why I believe this" and that's fine.
But these kinds of tests were not standard even a few years ago. They're not even standard across the world. To me, that seems to indicate that there's something else going on. Why have these kinds of tests been introduced and why are they becoming normalized? Instead of asking the how, ask the why.
What points/factors led to that first company sitting down and talking about how they can't hire good developers and they end up deciding that a coding challenge (insert your nature of that challenge here) was the way to solve that?
What kind of expectations were broken and by whom? Do developers consistently under perform and lie about their experiences? Do companies consistently set their expectations too high?
It just feels like we're focused on arguing about the tests themselves but we're not focusing very much on the reason they came to be this way in the first place. These tests feel like an answer to a serious problem and I don't know that we're articulating that problem enough to tackle it properly.
Does that, at least, feel somewhat properly directed? Is that something we can agree on?