[davidbanham]

Thank-you!

My contention is that it doesn't matter if the time limit is unrealistic (within reason) so long as it's consistent.

ie: the challenge is not "Show me the best solution to this problem" but rather "Show me the best solution to this problem that you can achieve within an hour".

As long as everyone is under the same conditions, the playing field is level.

It's part of a holistic approach, too. The coding challenge is not the only part of the interview process. I suggest that there be an initial interview to assess experience, fit, explain the job, etc. Then if everyone is still interested, the coding challenge. The candidate's response to the challenge then forms the basis for a discussion in another, technically focused interview.

It's not about saying "You gave the wrong answer" but "Talk me through why you solved it this way" and "If this criteria in the challenge changed, tell me about how that might change your response"

The Codility and Hackerrank style problems are okay, but I don't like how constrained they are. I also think it's pointless having someone outside your organisation grade the results. What matters is not having a candidate who is "the best hacker" but having someone who fits what you need. If your team values robustness and debuggability above all else, you _don't_ want someone who can punch out 3 kinda-right prototypes before lunch. If you're an ideation agency, the inverse is true.

That's why takehome encourages companies to create and administer their own challenges rather than the samples. They should fit the kinds of problems your organisation faces, not contrived ones.

[janephilipps]

Good point about consistency, which is hard to achieve with the open-ended take-home challenges. I still feel like there is a catch 22 for new developers though - if you're competing with more experienced candidates, your best solution that you can achieve within one hour will rarely be one of the better ones, and the only way to really get better is to have real experience working on a production app. And you still have to get hired to do that, hence the catch 22. So, that's why I advocate for spending more time on these challenges up front, especially for people first making the switch, because they can be used as a learning opportunity. So many companies don't have the time or just don't want to invest the time to train newer developers, which automatically eliminates hiring someone straight out of a bootcamp. Maybe someone with a CS degree and no work experience would have the same problem though.

I like what you said about the importance of companies administering their own challenges as well. I've encountered some like that and they do tend to be a better reflection of the types of challenges and problems the company is facing.