I almost completely disagree with you. At a company I worked at, we made the mistake of hiring someone who was a core contributor to a language you have very likely heard of and just as likely have worked with. It didn't work out. The skills required to be a professional software engineer writing business logic are not identical to those required to write excellent core, library or framework code. Different beasts, and both should have respect for one another.

Conflate them at your own peril. Our experience with trying to make things work with this candidate was not very successful, and it was one of the two (out of dozens) of hires we made that we had trouble with.

Candidates should find sane companies that test based on competence and not on glorified SAT like algo teasers. Companies should find sane candidate who are competent at doing the job they need done. Many parties in both camps flop at this search process.

As for the mentioned case, perhaps there was a mismatch in expectations.

Personally I have witnessed an ex-employer hiring a truly world-class framework contributor. Of course we didn't give him 'feature development' tasks. In fact he was out of our scrum process.

Instead, he was given high-profile bugs, code analysis/refactoring tasks, and was given the freedom to create some cool abstractions.

That's precisely my kind of dream job! True consultancy.

(and yes, you can get those kind of gigs investing much less beforehand... you'll just get fewer, lower-profile ones?)

Perhaps I didn't explain it as well as I could have, but there was no mismatch. The contributor knew what they were getting into, but it just didn't end up being as great a fit for both parties involved. To give more context: I think there is a lot more space for these kinds of hacker types to fit in at a larger company where their skills can truly add value. But at a small to mid sized tech company where that's not the primary business focus, it's not going to work out so well. On the other hand, if you as an engineer want to write business logic, these kind of companies are great places to be.

I think you are not keeping in mind that these consultants aren't "someones", they are world-class experts. Often, team members know their names before they join the company (why? because FOSS contributions!).

Well I have seen it with my own eyes, so what can I say?

I specifically remember this guy who was really good debugging the 'undebuggable'. Perhaps more business-oriented bugs would indeed be assigned elsewhere, but more elusive stuff concerned with 'mechanisms', setup code, etc would be perfect for him.

I also have performed a similar role myself (just at a humbler team)

I hear you, but really, if my company would not assign such tasks to internal people, I would leave. Working there sounds like receipt for stagnation.

> Demonstrate you can get 20 PRs merged to 20 different top-tier projects, adapting to their needs...

This would be very impressive... but would also require _months_ of effort. I don't know any successful engineers who have that much time on their hands.

It's not uncommon to have a 'dev sabbatical'.

Neither is the notion of investing in one's skills beyond on-the-fly self-learning.

Some devs are able to save quite some money, or to work far less than 8h/d. I'd invite those to reinvest that time/money. Perhaps you can do it once every few years and ensure a truly remarkable career.

This might become more and more important as the market gets saturated with bootcampers, hustlers, or simply people who are junior today but will compete with you tomorrow.

It might not be uncommon in your neck of the woods, but where I exist this isn't common at all. Everyone has to work, and the luxury of being able to save "quite some money" (or work far less, which is more or less the same thing) definitely doesn't go to people who I'd call a "dev" (and not say, a consultant or upper management).

> _months_ of effort

And that's after the dev work, just convincing someone to care about your PR and its associated use-case or bug.

> Demonstrate you can get 20 PRs merged to 20 different top-tier projects

I really have a skepticism that many people, whatsoever, can get 20 _non-negligible_ PRs in 20 _top-tier_ projects in any meaningful time frame.

Not many, indeed. That's the reason why this approach makes you stand out - b/c it's not for everyone. I know a handful real cases of such FOSS work boosting one's hourly rate.

I'd take it as a matter of patience, habits and of course excellence.

Probably will execute this plan myself at some point.

If you consider the bottom tier of entry level people with weak or empty CVs, the difficulty from skill-set alone skyrockets before you factor in how privileged you'd have to be to do this for free in your spare time.

1.) I did not really seen employers to care about open source contributions all that much. It is a bit reassuring thing to have for people who did not work full-time, but for past full timer it did not seemed to matter much.

2.) Why would many shallow contributions be better then deeper involvement with one project? I don't get this one at all. Why would high-profile project be an advantage over less known one? Another thing I don't really see.

This sounds more like a dream of how it should work then reality I see around.

1) That's because average developers' FOSS contributions tend to be sparse and low-impact.

I have witnessed a number of companies throwing whatever money was needed to have language/framework/library authors working with them. I see no reason why the same principle shouldn't be more general.

2) Not necessarily shallow. You can create 1-2 big PRs per project (plus a few small ones), which amounts to 1 week of work per project.

The point of going for a variety of projects is that you demonstrate:

- proven skill/interest in a whole ecosystem (e.g. Elm)

- ability to read/maintain code (going for just one codebase is comparatively easier)

- ability to adapt to different standards and people

Lastly, high-profile projects have harder barriers-to-entry (therefore you demonstrate better skills), and are more likely to be known by the employer.

Parent said "Go for breadth rather than depth". I dont think multiple easy bug fixes are harder then deeper one. The reason most contributions are in sparse and low-impact is that it is easier and less time consuming.

Isn't ability to maintain code better proven by maintaining one codebase longer? Mostly because that is what maintennace is?

Sounds good and of course there's more than one approach to get comparable results.

Probably as a freelancer/consultant breadth is better than depth (proves you can solve whatever problem you may have with technology X), and vice versa for employees (depth shows commitment and an emphasis on maintainability).

This is good if used as one of many signals. If you rely too heavily on public projects you risk filtering out good people who, for example, are not permitted to work on open source in their free time due to their employment agreement.

Good point!

Anyway, my intent was to give an advice to developers rather than to employers.