[renewiltord]

How many hires have you made using this process? It is interesting in that the cost scales per person significantly. If I'm putting that much effort into the candidate, I think I've already determined I want him.

I've definitely used a candidate's original work on Github to evaluate their skill but we still spoke about career objectives and culture.

Honestly, I doubt that guy wouldn't have aced the technical interview anyway. It just saved us both time to not do it.

[nickdandakis]

I've hired a handful of people with this process, across two organizations. First time around, I identified and created the take-home exercise in one working day. Half of it was actually setting things up, the second half was solving it myself and tweaking it such that it takes the amount of time I was aiming for. Second time around it took a half day total.

I'm not saying you shouldn't look at a Github profile or any code samples the candidate sends over. However, those metrics aren't good aptitude indicators. I feel the same way about algorithm-style coding tests that a lot of companies follow. Sure, let me find all the anagrams in a set of words only to land a job writing REST APIs...

I don't see how the cost scales per person significantly. You create one take-home exercise per role you're hiring for. You send the same take-home exercise to any candidates that apply for the role. Worst-case scenario, it takes too much time to compile this take-home exercise, in which case you've hopefully spent the time to smooth out your processes which leads to an easier onboarding. Best-case scenario, you've compiled a take-home exercise in a reasonable amount of time, which verifies that onboarding will be smooth for the new hire.

To your point, the take-home is for candidates in the 2nd or 3rd round of interviewing where you've verified their experience, you've verified their character/soft skills, and need to verify their aptitude/hard skills.

[renewiltord]

That's very interesting that you haven't had any signal from Github. My friends also shared that feeling but I've tried that on two people and they were both hits. So at least I know it has specificity.

Ah I see, you do one for the role, not per person. I misunderstood. That makes sense. What sort of roles were you doing that for? Generally, I aim to keep things short which is what I worry about with exercises. The tendency to perfectionism is higher in that than in real work. But if it's effective, so be it. I know I was hired that way once out of uni the better part of a decade ago! :D

[nickdandakis]

The vast majority of candidates I've spoken to commit their code to private repositories. Same goes for me.

Roles were for fullstack and frontend. You're right in that sometimes time escapes us when coding. That's why I set a time limit to the exercise and ask them to submit whatever they coded in that time frame. Doesn't have to be perfect, nor does it have to be complete. The point is to have code to talk through specific to the role you're hiring for, and ideally specific to the project itself.