One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
Candidates are free to decline coding challenges and companies are free to require them.
Glad to hear that.
While I'm sure that there exist unscrupulous places that do just that, more are probably presenting real life challenges because it better simulates actual work product.
(...)
The challenge we give takes people and average of 8 hours (or so our candidates say) it takes us about 5 work hours to review these, then another 5 or so in the follow up interview about the challenge.
My preference in this case would be:
have an initial extended conversation where you both establish that it could make sense to work together
test that hypothesis out by having the candidate work for you for N days, with N small, as a freelancer
if working together reveal a mutual fit, then make the hire.
I'm not saying that's a panacea that will work universally, because good hiring practices are always local, but I would argue that it de-risks the hiring process for everyone involved and is a more natural and efficient simulation of real life work.
We do give an initial hour long first round interview with the candidate and 4 to 5 people from our dev team after we ranked and sorted the resumes. Then if we think it makes sense we move on to the coding challenge.
Yes, I'd love it if we could do a "test hire" for a few days but neither HR nor legal would remotely be ok with that.
I've seen companies that hire as freelancers first and that seems like it can be exploitative. They generally don't move people to full time roles until they threaten to quit.
There are definitely cases where a coding challenge is almost an insult to the interviewee but there are also cases where the candidate struggles tremendously. It's hard to tell those people apart before hand. I've found that resume and the initial interview are surprisingly uncorrelated with the coding challenges and that's the main reason we do them.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
Glad to hear that.
My preference in this case would be:
I'm not saying that's a panacea that will work universally, because good hiring practices are always local, but I would argue that it de-risks the hiring process for everyone involved and is a more natural and efficient simulation of real life work.
We do give an initial hour long first round interview with the candidate and 4 to 5 people from our dev team after we ranked and sorted the resumes. Then if we think it makes sense we move on to the coding challenge.
Yes, I'd love it if we could do a "test hire" for a few days but neither HR nor legal would remotely be ok with that.
I've seen companies that hire as freelancers first and that seems like it can be exploitative. They generally don't move people to full time roles until they threaten to quit.
There are definitely cases where a coding challenge is almost an insult to the interviewee but there are also cases where the candidate struggles tremendously. It's hard to tell those people apart before hand. I've found that resume and the initial interview are surprisingly uncorrelated with the coding challenges and that's the main reason we do them.
Sounds good to me