Refining the details of pet projects is not a luxury that not everyone has. If the quality of the candidate was correlated, then sure. Even still, candidates who get shit done have always been the perceived best hires.
Seriously, though, for a reasonably senior position, they'll already have been employed for long enough at a high enough salary to be afforded hobby time. And if they really enjoy coding, they'll probably code something up just to scratch some itch. Or just to play with things not work-mandated.
That's not elitist. It's selecting for successful engineers who actually enjoy coding.
If the interviewer cannot determine whether the candidate is good in less than 2 hours interview session without previously made projects, it's on the interviewer.
On the other spectrum, companies are feeling too entitled for demanding pre-established projects to showcase, take-home assignments take can take days to do, without really offering any incentive to it.
Sure, there are plenty of good engineers who won't have a nice side project to bring up. And you will be auto-passing on them.
The real question is, how many bad engineers are hacking away on a side project they can show off and speak intelligently about?
He is right that his method doesn't scale. He is intentionally picking from a rather small bucket. But that bucket should be pretty high signal-to-noise. That makes his job pretty easy.
When hiring, I often try to filter for "gets stuff done". Side projects definitely help check that box. I also filter for how deep their technical knowledge is for their experience level. I love finding people who are passionate about computers and code, as they always hit above their pay grade, but don't really try to filter for this.
Now when this technique become successful and widespreadly adapted by other companies, everyone will start making minimum personal project to show, enlarging the bucket and increasing the signal until another, more effort interview style is introduced, thus reducing the signal again and repeat.
In the end it'll only take more and more time from job seeker.
Some days I just can't, I'm fried after work, and then I just hang out with the family.
Great. Two of the most common hobbies for everyone else is excluded so you have enough time to do side projects (TV here includes streaming service shows, sport broadcasts, etc.). How is this not reinforcing the idea that this purity test excludes many engineers?
This is where data would be helpful, and why numerous people have pointed out that bringing code you wrote, IP owned by your previous employer is a no go, and why we've goal post moved instead to bringing in your personal projects.
> If they don't have code to share for whatever reason, like it is owned by their previous employer or they are fresh out of school with no code to show, pass on them.
> You have other code to share?
Data would be helpful, but I don't even know how such data would be gathered. Is there a sure-fire method to identify a "Good Engineer" from one who is not?
I interview occasionally, been working a long time. The numbers of devs I know that have such code to share is small, and I would put them all in the work-with-again bucket. I'm not sure if I would adopt this method, but I've seen worse filters :)
Surely the most bias free way to hire would be to say yes to the first applicant. Of course this excludes engineers who are busy and were not able to apply first... so perhaps the randomth applicant gets sent a "youre hired".
I mean. Hey maybe its a better process. We have yet to see some metrics on this.