Huge problem with this, apart from not everyone has a GitHub, is that code and expertise are not the same thing.
You may spend years learning about some field like systems programming, and then when you make a contribution to the Linux kernel it's only a few lines. There's no way to know from that how well you actually understand the kernel. You might have a lot of experience, but so did previous contributors, so it looks like you only did a little bit when actually you know quite a lot.
Also there's a lot of work in coding a few lines of code that isn't just those lines. You may have taken apart very large systems and grepped huge amounts of logs to understand something, while having written many intermediate versions of a solution, only for you to figure out the problem could be elegantly solved.
For me the smart way to interview has always been the open ended technical discussion. People who don't know the vocabulary show this very quickly. Imagine pretending to be a surgeon, you'll last one minute. People who are close to the work but haven't done it will last a bit longer but there are so many technical terms they will also drop out, typically when you ask for some sort of judgement on A Vs B. This still hasn't gone wrong for me, my only dud hires have been people who wanted to do something else rather than couldn't do it.
> Also there's a lot of work in coding a few lines of code that isn't just those lines. You may have taken apart very large systems and grepped huge amounts of logs to understand something, while having written many intermediate versions of a solution, only for you to figure out the problem could be elegantly solved.
If that's the case, then that should be evident in the commit log.
My one commit in the Linux kernel mostly just moves a few assignments / variables around; but the commit message should make it clear the effort that went into it.
You may spend years learning about some field like systems programming, and then when you make a contribution to the Linux kernel it's only a few lines. There's no way to know from that how well you actually understand the kernel. You might have a lot of experience, but so did previous contributors, so it looks like you only did a little bit when actually you know quite a lot.
Also there's a lot of work in coding a few lines of code that isn't just those lines. You may have taken apart very large systems and grepped huge amounts of logs to understand something, while having written many intermediate versions of a solution, only for you to figure out the problem could be elegantly solved.
For me the smart way to interview has always been the open ended technical discussion. People who don't know the vocabulary show this very quickly. Imagine pretending to be a surgeon, you'll last one minute. People who are close to the work but haven't done it will last a bit longer but there are so many technical terms they will also drop out, typically when you ask for some sort of judgement on A Vs B. This still hasn't gone wrong for me, my only dud hires have been people who wanted to do something else rather than couldn't do it.