4 ms·
> I’m not saying that’s how you’re running things Good, because we're not. The main takeaway here, which I think we agree on, is that a good hiring decision r
by saxonww 4y ago
> I’m not saying that’s how you’re running things
Good, because we're not.
The main takeaway here, which I think we agree on, is that a good hiring decision requires more than one input. We happen to use a coding challenge as one input in our decisions, but I agree that a collaborative discussion could work too. In particular, we do ask about background and learning style, among other things, in subsequent interviews.
Overall, if I had to attach a percentage to it, I'd say the coding challenge is no more than 25% of the overall decision, with the provision that if you clearly just don't know what you're doing at all - which has happened just a handful of times that I can remember - we're not going to invest more time in you as a candidate.
> There’s a growing contingent of the types of people who you’d want the most, but will not consider your team for doing this.
All I can say to this is that you're probably right, but also that almost no one is as uniquely qualified as they think they are. There are millions of candidates, and especially now that more software companies are OK with remote work, we can consider more of them than before. This is really good and really bad, the latter because employers are even more likely to :shrug: at this sort of thing and move to an equivalently-capable candidate who doesn't complain about having a one hour coding test.
- haswell 4y agoYeah, I think we’re on the same page regarding the importance of multiple inputs. > In particular, we do ask about background and learning style, among other things, in subsequent interviews. In the past, I’ve done the opposite, and started with these questions up front. In my mind, they’re the most important thing to learn about a candidate, but I realize not everyone goes about this the same way. It does require more time investment up front though, and I get that. > I'd say the coding challenge is no more than 25% of the overall decision, with the provision that if you clearly just don't know what you're doing at all - which has happened just a handful of times that I can remember - we're not going to invest more time… If this is the case, wouldn’t that be evidence that this process should be de-emphasized even further, or at least moved to a later stage? Correct me if I’m misreading this, but if almost everyone coming through has had some level of success with the coding stage, it’s not really screening many candidates out, but still could be changing the candidate’s view of your team and company. If it’s the first thing they encounter, it’s a big part of the first impression the candidate forms. In a worst case scenario, you may drive someone good away with minimal benefit to the hiring process, and in a best case scenario, you’ve only saved a few conversations given the low failure rate. > but also that almost no one is as uniquely qualified as they think they are. I completely agree with you here, I just don’t believe an artificial coding test is the antidote to that. The more experience and confidence someone has (warranted or not), the less they feel they need to put themselves through pain for their next role. Really not trying to be difficult here, but trying to understand the mindset and strategy behind this style of hiring, and I’m not quite seeing where the value is coming from based on what you’ve shared. I will say that what you describe is one of the more reasonable stances I’ve come across, but still seems potentially counterproductive. I do hear you regarding the access to millions of candidates. It’s a great problem to have, I just wonder if the old ways are still relevant. Thanks for being willing to share your thought processes on this - it’s what I love about this site.