[pydry]

>I say "often" because OSS contributions can still be an indicator of something, but it's not really clear what.

It's a fairly clear signal of skill quality and attitude.

Reading open source commits/PRs and issue trackers tells you quite a lot about a developer which you can't see without some sort of a test (often not even then).

>it's biased against people who don't have the time

Surely any career that requires a high level of skill and practice honing that skill is biased against people who don't have the time?

What's special about open source?

[notsuoh]

Yes it can tell a lot about people who have the bandwidth to be able to be able to contribute to such. Others may and do have the same level of skill but didn't have the bandwidth to contribute to PRs, so by looking at PRs as an extra we're effectively penalizing those without time, which has the practical effect of biasing us against people with kids, people with a full time job and in grad school, or you name it. We shouldn't be biased against those people.

Any career, especially in our field, requires a high level of skill. We try our best to level the playing field for everyone while still getting a lot of signal in the interview process so end up eschewing things like school attended, talks given, OSS contributions in evaluating candidates. Anecdotally we've seen little correlation with these sorts of things and interview ability or ability at the job after being hired.

[pydry]

>Others may and do have the same level of skill but didn't have the bandwidth to contribute

And even more have the potential to become excellent coders but didn't have the bandwidth to develop it.

It seems peculiar to single out one quality in particular that sends a clear signal that a skill has been honed on the basis that it took time to hone that skill.

All skills take time to develop.

[notsuoh]

All skills to take time to develop, well said. I am confident that looking at how a candidate interviews will no doubt show the fruits of that time spent without weighting too much the time spent, regardless of whether that time spent comes from contributing to open source, from their full time job, or just studying and honing their skills efficiently under harsher time constraints. We don't want people to target the metric of "time spend coding on OSS projects" do we? I don't.

Besides, having a diverse experience base and pipeline (parents, non traditional developers, non traditional paths to SWE, and even single people with a ton of time and fortune to be able to do things like robust side projects) has served us particularly well in having a team with a wide breadth and depth of experience and viewpoints. Specifically weighting side projects in lieu of technical/EQ interview performance would ruin that in favor of the latter group.

[pydry]

>We don't want people to target the metric of "time spend coding on OSS projects" do we?

Nobody said that we did.

This is about ignoring OSS contributions vs. reading them taking them into account - i.e. deliberately ignoring a signal of quality because it might, for instance, discriminate against people who chose to have kids.

I find it particularly ironic coz part of the reason I wrote open source was to save time - to skip wasteful technical interviews that it ought to be obvious are unnecessary if I have public evidence I can code well.

[notsuoh]

We don't ignore them completely, we just weight them very, very low, as I've indicated. They do provide context. Your phrasing "chose to have kids" betrays some of your underlying beliefs, I suspect. We'll likely just agree that we weight things differently and are willing to forego some otherwisee excellent candidates to index more heavily on being fair to everyone in the process and judging them to the same standards. This is a conscious choice, and so far a very good one.

To your second point, I can't think of a single thing I would let be a proxy for technical skill in an interview process -- certainly not some commits to open source. (Maybe if I had worked side by side with the person in a previous life would be weighted) Even if we did use that as a proxy, it doesn't really save time because people would have to inspect the work and still doesn't really tell me anything about the candidates approach to problem solving or framing of issues that I can get from pair programming or walking through some code for an hour.

I applaud all your open source contributions and appreciate them, but I wouldn't consider them in whether to hire you except perhaps at the margins. Others may disagree and that's their conscious choice or they're indexing on something different.

[pydry]

>Your phrasing "chose to have kids" betrays some of your underlying beliefs

I did suspect that underlying your opinion was a desire to discriminate in favor of parents/against non parents.

This would fit in with the double standard I highlighted in my first comment.

This was also because you mentioned "parents" in the context of diversity (which is weirdly unique). I threw that phrase out there to see if it triggered you.

>To your second point, I can't think of a single thing I would let be a proxy for technical skill in an interview process -- certainly not some commits to open source

I've not worked with a huge number of developers who have made > 3 significant pull requests to a serious OSS project but every single one has been stellar.

I've worked with a lot of developers who can do the cracking the coding interview dance who sucked and even more who interview well in other ways.

[varjag]

We OSS contributors with kids are in the worst spot! :)

[Agingcoder]

You need time.

A full time job and small children for example don't leave much space for extended coding sessions on side projects, unless you're lucky enough to need little sleep.

I've worked around this by learning at my day job : read books/papers at home (this is relaxing), and look for opportunities to apply this knowledge at the office. Unfortunately, it stays at the office though, and can't be shown as proof of your skills outside of the company.

[bauerd]

It's not about merit but about bias

[californical]

You generally become better with more practice though, right? Whole 10,000 hours thing? Surely someone who spends more time developing will be better at it.

Now of course this doesn’t matter past a certain point — people could spend all their time working on something that doesn’t help them grow.

Then once you have those 10,000 hours of actual growth, you are probably close to a Senior developer level. Which after 5 years in an office job working 40 hour weeks, you’re there anyways.

But at the earlier levels of developers, it seems that working on projects outside of work would definitely help you improve faster!

[omniscient_oce]

I've seen this on Reddit a fair bit too but there's this sort of anti "10x-er" attitude. It makes logical sense to me that if someone spends more time practising a skill, then they would be more proficient and thus worth paying more. Yet there's a lot of pushback against that thought process because it is biased or something. Obviously there's more to a candidate than purely 'coding' skill but I find it weird that a company would want to explicitly avoid an indicator of time spent honing skill X purely because it discredits other people. I guess in an idealistic world it makes sense but the real world never quite lives up to the ideals.

[pydry]

I've found that a lot of hiring is explicitly biased against skill. The root cause is mostly the hirer wanting "people like me". Or, at least, not discriminating against "people like me".

I'm sure a lot of people who hire developers think of themselves as people who could write open source but don't have the time.

This also accounts for why stuff like leetcode persists (the hirers were successfully selected by that process), why top colleges are often preferred and even why the profession is predominantly white/male.

[watwut]

> You generally become better with more practice though, right? Whole 10,000 hours thing?

Except that 10000 hours thing is non scientific nonsense.

To improve, you have to practice right way. If you code for 8 hours at work, coding 2 further hours wont make you improve more. Similarly, if you want to improve in music or running, just playing songs or jogging means you will hit plateau pretty fast. After that, you have to train on correct selection of exercises.

At that point reading some theory will have much bigger impact, because yoi are doing something new. And even exercising will likely make you improve more due to what it does to body then further 2 hours of the same.

[pydry]

>If you code for 8 hours at work, coding 2 further hours wont make you improve more.

A) I'm pretty sure almost nobody actually codes 8 hours at work.

B) Those two hours will be of a very different nature to "work coding" and this can lead you to learn things you wouldn't pick up at work.

[watwut]

> I'm pretty sure almost nobody actually codes 8 hours at work.

The non-coding parts of work are necessary on oss projects too. In any case, programmers work being mostly coding + code review is pretty normal.

> Those two hours will be of a very different nature to "work coding" and this can lead you to learn things you wouldn't pick up at work.

That is nowhere near guaranteed and more likely to not be true. In particular, if you focus on maintaining the same software, it will be more of the same after a while.

[pydry]

>The non-coding parts of work are necessary on oss projects too.

IME a far greater % is coding. There's also a lot of OSS people involved who don't code who help out with the other stuff.

Moreover, a lot of the stuff that "isn't coding" is a strong quality signal - how the developer interacts with bug reports for instance.

>That is nowhere near guaranteed and more likely to not be true. In particular, if you focus on maintaining the same software.

It'll still be different to what you do at your day job and will necessitate picking up a different set of skills and a different perspective.

[silicon2401]

as someone heading towards 5 years developing, I'm not sure it's as straightforward as you think (and if it is, I'd love advice on how to improve). In my career so far my work has roughly gone in phases of backend, frontend, devops/infrastructure. I've been able to improve my soft skills of learning how different organizations work, learning how to network and collaborate, learning how to learn, etc, and improve my technical skills of development, learning about best practices, etc, based on the particular technologies I work with at a given time. But I haven't had the chance to just spend 5 years progressively leveling up my java backend or javascript frontend skills. As a result I don't think I would qualify for a senior developer level quite yet. But by that token, perhaps I'm also not the best person to say whether or not this is the typical path for a sr dev or not

[notsuoh]

I trust that all that practice would make someone interview really well, no need to look at how much practice they've had as a metric.

[pydry]

So you'd consider it anti-meritocratic?