> I have a Github profile with more than enough stuff on it
Based on my experience only, you're in the minority here. Most candidates I've interviewed have barely anything on GitHub. Some UI/UX-ish people will have a portfolio, which involves a lot of "view source" and isn't too rewarding. Lots of perfectly good working programmers have no active open source participation, not even a "dump of code" type of GH profile, making it difficult to tell wheat from chaff. Having them do code tests is pretty much the only way that doesn't involve talking to every single one.
Look at the other side, too: I've gone through hiring processes in the past as a candidate that started with a 30-45 minute conversation with the hiring manager, and proceeded to the onsite interview stage. This inevitably ended up being the classic 6-hour beatdown, with both sides muddling through without truly understanding what either is doing. These are usually so inconclusive (especially at bigger companies) that no one can make a decision, so they end up saying "no". Now both sides are 6+ hours in the hole. This could have been a simple 2-4 hour asynchronous code test, which would have provided hard information to the hiring team instead of the usual inconclusive bullshit.
> Having them do code tests is pretty much the only way that doesn't involve talking to every single one.
I get where you're coming from. But to me that's still a very, very selfish way of approaching this. You are asking for a blind burn of four hours of their time just to consider talking to them. Four hours is a lot of time. It's half a workday. You're asking for a hell of a lot just to not-a-culture-fit them out afterwards. And from a practical perspective, somebody who's good and employed is unlikely to expend the effort unless you're a very special company, too, which complicates the search.
> I've gone through hiring processes in the past as a candidate that started with a 30-45 minute conversation with the hiring manager, and proceeded to the onsite interview stage. This inevitably ended up being the classic 6-hour beatdown, with both sides muddling through without truly understanding what either is doing.
See...this I don't get. I know within an hour or so of talking to somebody if I want to work with them, and past that literally everything else, aside from compensation, is belaboring the point. And I mean "an hour"; if I'm not enjoying the process at that point, I'll usually suggest we end the interview. But on the flip side, because I am a good community member and I network heavily, I might in those situations go "hey, I think this isn't a good fit, but I want to introduce you to my friend who I think might be a better fit." I've done this before, and I can't do that (and wouldn't be inclined to do it) after you've burned half a workday on a monkey-work project.
I think there are reasonable ways to get a demonstration of work, but they involve investment and give-a-shit that I think most companies are way too happy to be bad cultural citizens to consider. Like, here's a coding test I'd be happy to do: "add this feature to this open-source project you probably use every day", well, that'd be different. I'd be getting something for my time, too, both in terms of feature and in terms of public recognition for open-source contribution. But one-way, dance-monkey-dance, throw-it-away-after stuff? That's very selfish, and I think we should be better than that.
I wish there was a way to scale the "add feature to FOSS project we use" thing. Scale is a concern here because I see this exercise being doled out more than a few times, which means that every instance must involve someone deciding what features should be added. There's also a limit to how much can be added to the same handful of projects over time.
Can't ask all candidates to add the same feature over and over, or else this becomes throwaway code as well, which doesn't address any of the valid negatives you've raised.
> I know within an hour or so of talking to somebody if I want to work with them
Ha ha! I've had an HR department at a BigCorp tell me that there was a minimum duration to each interview (30 minutes for phone screen, at least 45 but preferably an hour for in-person), regardless of how they were doing. Their thinking was that more time spent by us would cause the candidate to consider us a more desirable employer. You can imagine my anguish at having to speak endlessly with people who would clearly never cut it on my team.
> Can't ask all candidates to add the same feature over and over
Ehh. Make a list of, say, ten features across the stuff you use. You really think that's not going to be enough for fifty candidates, if the state of the industry is as apocalyptic as everyone says it is?
I don't know, I personally consider an all-day onsite interview to be a bigger waste of my time. With two or four hours spent on a take-home test, those can be any time during the day, probably time that I would have been wasting anyway. An interview has to happen during business hours, which means I have to take one of my scarce and therefore precious vacation days, and then actually go somewhere which is likely to take two hours round trip anyway, and that commuting time is entirely wasted. At least a work sample test can be an opportunity to practice my skills and an interesting challenge in itself. Then again, I actually used to do programming contests back in school so maybe that's just my personal preference.
Well, there's a pretty big difference between 2 hrs and 4 hrs. Most people are applying to multiple places when they are looking for a job. So let's say 3 places a week. Now this is the difference between 6 hrs (already a lot) vs. 12 hrs (practically insane) per week on this stuff.
And at the end of all that work, the candidate receives a binary yes/no. 1 bit of information. On the other hand, the 6 hour 'beatdown', as you term it, gives the candidate an incredible wealth of information. They see what their prospective coworkers are like, what the office is like, how people interact with each other, maybe what people talk about over lunch. So 3 interviews with 1 bit of information (12 hrs) each or 2 on-site interviews (12 hrs) with a hell of a lot? What's the rational choice?
And I'm not against programming assignments, but 4 hrs each?
Nearly all of the work I do for my employer is on public github. I always wonder though because if you just went to my personal github page it's not necessarily obvious that my Day Job is just a click or two away as these are contributions to another public repo, not one of my own. My own personal repo collection has close to nothing related to any job I'd ever want.
> I have a Github profile with more than enough stuff on it
Based on my experience only, you're in the minority here. Most candidates I've interviewed have barely anything on GitHub. Some UI/UX-ish people will have a portfolio, which involves a lot of "view source" and isn't too rewarding. Lots of perfectly good working programmers have no active open source participation, not even a "dump of code" type of GH profile, making it difficult to tell wheat from chaff. Having them do code tests is pretty much the only way that doesn't involve talking to every single one.
Look at the other side, too: I've gone through hiring processes in the past as a candidate that started with a 30-45 minute conversation with the hiring manager, and proceeded to the onsite interview stage. This inevitably ended up being the classic 6-hour beatdown, with both sides muddling through without truly understanding what either is doing. These are usually so inconclusive (especially at bigger companies) that no one can make a decision, so they end up saying "no". Now both sides are 6+ hours in the hole. This could have been a simple 2-4 hour asynchronous code test, which would have provided hard information to the hiring team instead of the usual inconclusive bullshit.