[nickdandakis]

Yes, there is.

Extract a piece of work from the project the new hire will be working on. Set up scaffolding and any boilerplate so that only have to implement one new feature (or fix one bug). Give it to another employee or yourself and solve it while recording how long it took. If someone that's familiar with the project took 4 hours, simplify. If someone that's unfamiliar with the project took 1-2 hours to solve, send it out to candidates.

If you can't do any of the above, you might have process issues that you need to solve prior to getting a new hire in the first place.

Oh, and if the take-home exercise is expected to take 4+ hours, pay the candidates to do the exercise.

[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.

[machiaweliczny]

I don't like these because it's not hard, can't really show skill as people aren't impressed unless you overengineer. I don't have time/desire for that - prefer algo questions as it's some entertainment at least. Although this is probably best way to hire juniors.

[nickdandakis]

What does skill have to do with difficulty?

Big red flag if you think the only way to impress someone of your coding skills is if you overengineer a solution. If some candidate submitted an overengineered solution, I wouldn't hire them.

I agree on needing time to solve the take-home. That's the biggest con with this approach.

If you don't have the desire to complete the take-home exercise, then you probably don't want to work there in the first place.