How about: When searching for a new job, your previous years of experience, github repos, personal projects, consulting gigs and all other relevant information about your ability to produce quality software will not matter at all compared to your ability to do leetcode style programming challenges.
"America lacks top notch engineers" - Says every large tech company. It didn't dawn on me until now that, "top notch engineers" really just means "people that are good at passing algorithm interviews". So many people I work with can code every algorithm on leetcode in a jiffy but can't write quality software that works.
For me, moving to the bay area would be a bigger problem than these kinds of interviews anyway. All interviews I have done the lasts years didn't involve code challenges.
I don't apply to many jobs (I've got a tolerable one and am picky about location and other things), but the one startup tech job I applied to didn't do puzzles, they did do a screenshared coding portion, but it wasn't a puzzle kind of thing.
Oh, no, we do whiteboard interviews. But they aren't those kind of stupid puzzles. We just have candidates write a little code, and do a little design. The "write a little code" is not one of those leetcode questions - it's really a simple problem. We just want to watch them code, and to hear what they're thinking as they do it.
This is the way to do it. How an applicant applies process to problem solving and communicates their ideas, is way more important than being able to regurgitate bubble-sort.
> previous years of experience, github repos, personal projects, consulting gigs and all other relevant information about your ability
As far as evidence for a hiring decision goes, all of the things you listed are things that can either be easily faked, are hard to verify, or require implicitly trusting another organization. How am I supposed to spend the time reading all the code on your github account and forming a judgment of your ability based on that? Even if I do that, how can I be sure that you're the one who wrote that code? 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? Even if I call your references, they'll probably just say, "yes, this guy definitely worked here, and by HR policy I'm not allowed to say more". Even if they do say more, how am I supposed to trust them? There's not nearly enough information there to make a hiring decision.
> 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.
