Take homes are one of the single biggest turnoffs for experienced talent in interview processes. People don't want to do them. Especially good devs who can land a job anywhere.
> Don't make them jump through hoops
The take homes are the hoops.
> Don't make them jump through hoops
The take homes are the hoops.
Otherwise, I'll do something simple, on a shared screen in the language of their choice.
It shouldn't be hours and hours and, ideally, it's a win/win.
The shared coding screen is definitely the most common method. And the one I've found most folk prefer. There won't ever be a one size fits all solution, but ideally your interview methods are equitable across all candidates, and ones that the majority of candidates are comfortable going through. Disparate processes hurts the former.
It might not actually be their project.
> but ideally your interview methods are equitable across all candidates
My candidates are not competing with each other, the tests do not need to be "equitable" between candidates, just fair for that candidate.
One problem, for instance, with github projects is that it's a fairly privileged position to be able to have significant side projects. So it's not fair to expect a candidate to have a github presence and you would be eliminating people without a lot spare time (single parents is the go to example).
I don't really care how successful you are. I want to see how readable and maintainable your code is. Sometimes I just ask for example projects that I can read.
But I do need to know you can, you know, actually do the job. I personally find in person coding significantly more stressful than take homes. So what would you suggest? How do I test someone's ability to code?
I may be being generous. I am noticeably “older,” so it may have simply been bald-faced ageism, in my case. Maybe younger folks would have been given more latitude.
I remember getting a take-home, once, where they asked me to write an iOS app that leveraged a specific library. They did not provide a template. They simply sent me an email with a fairly vague spec (I'm fine with that). They also wanted me to use a specific $methodologyDuJour, that would have resulted in needlessly complex, underperformant, and buggy code.
At the time they gave it to me, I had a pretty serious personal family emergency, so I did the app, using the industry-standard method. I wrote a full-quality, localizable, documented app, in less than four hours. While my house was trying to burn down, so there was a bit of extra stress.
Oh, and also, I had never worked with the library they wanted me to use, so I had to learn the API.
So, I wrote a full native Swift iOS app, from scratch, learned a commercial API, integrated it, tested the app, documented it, and delivered an App Store ship-ready iOS app, with very high-Quality code, in about four hours, while under serious personal stress. I did let them know that I had had to deal with a "personal emergency," so the test was a bit "rushed."
They ghosted me hard after that. I was actually shocked at how discourteous they were, as everything before that, was great.
They maybe didn't like that I used classic MVC for the app, because it is ... less than optimal ... to use other patterns, when writing a UIKit app. Of course, it's also possible that they finally brought in a tech manager, who figured out I was old, so...
But I regularly write full apps in record time. My GH repos are full of test harnesses that I toss together in no time at all. Pretty much every test harness is one that many folks would be proud to submit to the App Store. I’ve had over 20 published native apps, over the last ten years (mostly deprecated, these days), so I’m used to regularly shipping (and maintaining) native iOS apps.
I'd suggest that someone that can chock together an app like that, in just a few hours, while under a serious amount of external stress, could be someone worth following up on. BTW: The library was MapBox. I'd never worked with it before. I enjoyed the opportunity to learn about it, as I may use it in the future (offline maps, and it's a pretty decent dependency).
But that was about three years ago, and I'm actually really glad that I got chased out of the rat race. It just took me a while to appreciate it.