3 ms·
Ask HN: How many dev candidates make it to the take-home challenge stage?
If you've ever hired developers, what percentage of those candidates were asked to complete a take-home challenge (if that was even a part of the hiring process)? Also, what was the process of keeping track of the candidates and reviewing their code?
- PragmaticPulp 6y agoIt really depends on where the take-home challenge sits in your screening/hiring pipeline. I generally reject about 50% of resumes that our recruiters provide. I generally reject about 80-90% of resumes from public job postings because so many of them are low-effort spam. I prefer to phone screen people before providing the take-home homework. I would estimate that about half of those receive the take-home homework. Of those, I expect about 1/3 to knock it out of the park, and the other 2/3 are essentially getting a second chance to redeem themselves after a borderline phone screen. We have a near 90% completion rate for the take-home challenge. Surprisingly, about 1/4 of candidates don't even bother completing their work enough to pass all of the tests (we provide the tests), which always surprises me.
- sushshshsh 6y agoControversial opinion, I would rather a 45 minute coding interview that gets me through to the “final” round than a virtually unbounded take home test on some random-context task where the chance of me passing is 33%. If I was desperate for a job and needed practice then I would try the takehome but I much prefer reversing a linked list and traversing a binary tree for a job, which takes me all of 10 minutes.
- ping_pong 6y agoI will reject 80% of the phone screen candidates I get, and about 50% of the onsite candidates I get.
- wbobeirne 6y agoI used to be much more choosy about who I gave take-homes to until we started paying candidates to do the take-home. Now I don't feel as guilty taking a chance on someone I was on the fence on, since I know their time won't be wasted. I would say it went from ~15% to ~25%. My review process is to take their code, throw it up on GitHub for the repo we gave them to start, and then have the team review it as though it was a regular contribution. Depending on how well they did, we either give them a brief written summary of high level issues we found and a polite rejection, or we go over the PR with them in person and make a decision based on how well they responded to feedback, if they were able to understand why we made suggestions etc.