> How am I supposed to spend the time reading all the code on your github account
Easy - spend the 45 minutes that you had allotted for whiteboard challenges.
> how can I be sure that you're the one who wrote that code?
You can't be, if the Github account has a single repo with a single commit. But impressive OSS has a history of commits, maybe even a community working with the applicant.
As a random example, do you really think it would be possible for someone to fake an account like this?
https://github.com/pedronauck
Even if someone went through the trouble to clone someone else's repo, modify all the commit messages to re-attribute them, and modify the code and commit messages enough to make it not obvious plagiarism, do you really think they could bullshit their way through a quick conversation about the code? Spend 20 minutes digging into it, and then ask pertinent questions about decisions made in the architecture. It'll become clear if this person is the author.
It's theoretically possible that someone could put in all the work to pull off a convincing fraud, but do you really think that's likely?
> How do I know that your previous employers and clients weren't all bozos or that you didn't slack off and let your teammates do all the work?
It's true that there is no perfect signal here, but the odds of this being true are not 50/50. It's not 100% accurate, but having references and employment history is better than nothing.
---
To be clear, I don't think OSS inspection is perfect as a hiring tool - it biases towards folks with the privilege to spend their free time working on passion projects - and I'd object to it being the sole determining factor. But I think the signal is far stronger than it is from whiteboarding, where the false negative rate is super high (I doubt most competent programmers would accurately showcase their skill in this environment).
There is no perfect hiring practice, but to immediately disregard anything that has even a negligible potential for fraud feels a bit silly to me.
> But impressive OSS has a history of commits, maybe even a community working with the applicant.
That's going to be a single-digit percentage of the entire developer community and an even smaller minority of developers who go looking for jobs.
> As a random example, do you really think it would be possible for someone to fake an account like this? https://github.com/pedronauck
No, but it would also take a lot longer than an hour for me to judge, from that Github account, whether that guy is a bozo.
> It's not 100% accurate, but having references and employment history is better than nothing.
Which is why they merit the dozen or so man-hours involved in an interview process.
> To be clear, I don't think OSS inspection is perfect as a hiring tool - it biases towards folks with the privilege to spend their free time working on passion projects - and I'd object to it being the sole determining factor.
There are even more flaws than that. Unless you only hire people who make a lot of OSS contributions, you need some other measurement. And it's fairer and more accurate to use the same measurement for everyone, so if you need some other measurement anyway, you should just use it.
Another issue is that OSS contributions are a good signal if and only if you are hiring people to do the same type of work. If you're investing in a specific open-source project and you want to hire the primary maintainer to maintain that project, fine. Otherwise, you have to rely on finding someone who has a rich OSS contribution history in the same basic stuff you're hiring them to do, which is really hard when e.g. most OSS is on the platform level and you're developing products, or if you want to hire generalists rather than specialists.
This strategy usually falls apart for two reasons:
1. Some people are really good talkers and some people are really bad talkers, especially in an interview setting. That said, all the software companies that people usually complain about do have part of the interview process dedicated to past experience, more the more senior you are.
2. It doesn't scale. To ask really pertinent questions that can trip up a good talker you usually need someone with a lot of experience. But you also don't want them to spend all day doing interviews. You need some type of interview that more junior employees can collect signal from.
Easy - spend the 45 minutes that you had allotted for whiteboard challenges.
> how can I be sure that you're the one who wrote that code?
You can't be, if the Github account has a single repo with a single commit. But impressive OSS has a history of commits, maybe even a community working with the applicant.
As a random example, do you really think it would be possible for someone to fake an account like this? https://github.com/pedronauck
Even if someone went through the trouble to clone someone else's repo, modify all the commit messages to re-attribute them, and modify the code and commit messages enough to make it not obvious plagiarism, do you really think they could bullshit their way through a quick conversation about the code? Spend 20 minutes digging into it, and then ask pertinent questions about decisions made in the architecture. It'll become clear if this person is the author.
It's theoretically possible that someone could put in all the work to pull off a convincing fraud, but do you really think that's likely?
> How do I know that your previous employers and clients weren't all bozos or that you didn't slack off and let your teammates do all the work?
It's true that there is no perfect signal here, but the odds of this being true are not 50/50. It's not 100% accurate, but having references and employment history is better than nothing.
---
To be clear, I don't think OSS inspection is perfect as a hiring tool - it biases towards folks with the privilege to spend their free time working on passion projects - and I'd object to it being the sole determining factor. But I think the signal is far stronger than it is from whiteboarding, where the false negative rate is super high (I doubt most competent programmers would accurately showcase their skill in this environment).
There is no perfect hiring practice, but to immediately disregard anything that has even a negligible potential for fraud feels a bit silly to me.