DEV Community

Discussion on: Should I accept coding challenges for a potential job?

Collapse
 
spirodonfl profile image
Spiro Floropoulos

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?