|
|
|
|
|
|
by sibeliuss
1225 days ago
|
|
|
I'd suggest requesting that the candidate limits the time they spend on it to three hours, but give them a 24 hour window to submit. Some will need more, some less, however having that limit in place will constrain things sufficiently, I think. At least, that's how we do it over here. As far as the coding test goes, I can say with utter certainty that its important that candidates are required to build something, even if its simple. We've had trouble in the past around this; meaning, candidates who could mainly only _read_ code and copy / paste were able to get through the filter. As soon as we introduced a code test instantly we had a baseline, where the candidates who couldn't successfully code something from scratch were filtered out, and the ones who's submissions looked crazy or didn't seem to follow best practices were immediately identifiable. From there -- and this is key -- we used other aspects of the interview process to determine best fit, independent of actual code, and this combination has proven quite successful. The most important thing the coding test does is filter out people who simply can't code. There are a LOT of folks like this, and in particular boot camp graduates. (There are also a lot of talented boot camp graduates, don't get me wrong, but we've consistently noted a problem with this model as applied to real-world working conditions.) Once you've determined that the candidate can code, really dig into everything else and try to surface their passion for the subject; because if there's that, then they'll be able to learn and grow. |
|
|
24h for a take home is equally limiting for people with actual lives, and other than speeding up your process, it won't say anything more than a 3- or 7-day take home that's supposed to take 3h.