Open source contributions/projects is an extremely weak signal in my experience, and sometimes can be an negative signal. Open source software is developed generally differently than closed source software, much more async, and much more slowly. It is rare for people that professionally develop software to want to go write more software after work, and so quite often open source projects indicate they had a lot of free time for some reason, or they read something that they should do an open source project to increase chances of being hired.

The places I've worked in the past 15 years generally take open source contributions as a very slight positive signal, but only one of many.

> Open source contributions/projects is an extremely weak signal in my experience

What's a strong signal in your experience?

There really are no strong signals, which is why interviewing is relatively painful. Instead, there are a bunch of weak and moderate positive and negative signals, that you have to aggregate into an overall signal. Unfortunately the error bars on those signals are significant, and so usually you only hire on a relatively strong aggregate signal, and even then get it wrong occasionally.

Plus, nervousness and comfort with the environment and questions makes the error bars bigger.

Depending on the level, but assuming a Senior role, then some stronger (not strong, just stronger) signals are:

- ability to code basic solutions in the language of choice - ability to reason about code complexity

- ability to get to a solution

- ability to explain their reasoning

- demonstrate they understand the nuance and complexity of software development

- understanding common tools in the domain they are interviewing for (sharding for distributed systems for instance)

Same, but on the negative/bad side of things:

- arrogance, argumentative, rude (nervousness is totally fine and expected)

- one true way-ism

- complaining about interviews during an interview

- inability to solve basic coding questions

- lack of understanding about basic data structures (too many people I've interviewed don't even understand how a hashmap is used)

This is a bad idea. Even if "additive", giving significant weight to OSS work has a systemic effect of filtering for candidates with the free time, prior expertise, and/or liberty to do OSS work. In turn, those filters penalize: candidates trying to break into the field from other fields; candidates without a lot of free time outside of their existing work; candidates with more than full-time commitments (e.g. a lot of candidates from diverse backgrounds who are combining pre-existing FT+ employment with school to try to break into programming); entry-level candidates who might be able to code a TODO app from a quickstart, but aren't experienced enough to make substantial contributions to larger OSS projects; people whose prior employers didn't allow contributions (as another commenter pointed out); people whose programming experience is niche such that OSS contribution opportunities are rare.

Like, whiteboard interviews and leetcode grinding are not good filters, no argument there. And OSS is good and we should encourage more contributions in general. But using OSS/hobby contributions as an interview filter is just as bad as leetcode, in that it inequitably narrows the field of candidates and further compounds the hiring diversity problems in the US tech industry.

This feels like it could end up being the software equivalent of musicians/artists to do free work "for exposure".

I can see a lot of value in contributing to open source being an alternative way of demonstrating competency. However, I don't think I'd want to see it become the only or primary way.

This is a hollow excuse.

It doesn't have to be a replacement for traditional interviews. Rather it could be a way of distinguishing candidates instead of only relying on a white board.

When I was trying to get my first job out of bootcamp, I had a built a mobile app with my team mates, and we had it on our phones. The idea behind that was we could pull put our phones during interviews and show our interviewers exactly what we did.

"Btw, hiring manager, I happen to have that app on the projects section of my resume on my iphone as we speak - would you like to see it? Happy to walk you through the commits I made on github if you would like."

But...

Most hiring managers were not interested at all. Instead, it was all white board. The whiteboard brain worm infection in hiring managers just runs too deep, there's probably no cure at this point.

Who would you rather hire -- some one who could show you an actual project, code and all, or someone that can implement LRU cache in under 25 mins bc they happened to already do the problem on leetcode?

Not surprised interviewers aren’t very interested in looking at an app with you. Having produced some code that runs is the lowest possible bar to cross, and if your resume said ‘I wrote this app’, they are probably willing to give you the benefit of the doubt and believe that yes, indeed, you got an SDK to emit an executable that actually ran. Seeing the app isn’t going to give much more information.

This rules out good developers who work/worked at places that limit open source contributions.

Also opens the door to a lot of ultra-low-effort open source contributions that are done for the sake of it :/

I help maintaining a quite popular package ATM, I prefer when people do it for pragmatic reasons or for passion, rather than to improve their GitHub stats :/

But you can see them and filter out the low quality contributions. And ask about the good ones.

Filtering them out and dealing with the resulting drama is an additional drain on the maintainers' time.

Totally true, but I was talking more from a package maintainer PoV.

Most of the best commercial product developers that I've worked with had zero open source contributions. If they have some then sure, take a look. But it's not an effective filtering mechanism.

There is also now an underground economy built around fake open source contributions and even entire projects. This exists precisely because some employers do care about open source contributions, so hiring managers now have to verify that those contributions are real.