5 ms·

What undeniably would stand out, and speak for itself is a large portfolio of open-source contributions to widely-used projects. No personal projects. No libra

by vemv 9y ago

What undeniably would stand out, and speak for itself is a large portfolio of open-source contributions to widely-used projects. No personal projects. No libraries no-one-else uses. Real 1K+ stars projects in the niche/ecosystem you are targeting (Elixir? React Native?). Go for breadth rather than depth. Demonstrate you can get 20 PRs merged to 20 different top-tier projects, adapting to their needs, standards, understanding their codebases of course. Interacting with them in a polite, optimal manner. Mental exercise: think of one such contributor. Would you hire her? Of course you would, in a blink. No CV needed. I know it's easier said than done, but executed well, it will be level-up whichever salary you were making previously. (what to PR? Simply solve one of the many issues listed in a given project's tracker)

jmcphers 9y ago
> 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.
- Terr_ 9y ago
  > _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.
- vemv 9y ago
  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.
  - krageon 9y ago
    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).
FireBeyond 9y ago
> 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.
- vemv 9y ago
  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.
  - Can_Not 9y ago
    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.
ryandrake 9y ago
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.
- vemv 9y ago
  Good point! Anyway, my intent was to give an advice to developers rather than to employers.
yowlingcat 9y ago
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.
- vemv 9y ago
  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?)
  - watwut 9y ago
    Why the hell would company not give such job to internal people? At least in my experience, these kind of jobs is what you can get after you worked in a company for a while and company trusts you. Giving refactoring task to someone who is new strucks me as odd. Also, why are not people doing feature development tasks not allowed to create abstractions where appropriate? Or high profile bugs etc? That is another odd thing. If I would be hired and it turned out I don't have that freedom and the interesting bugs, I would leave the company fast - especially if someone new would suddenly get these normally learn-a-lot tasks and freedoms.
watwut 9y ago
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.
- vemv 9y ago
  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.
  - watwut 9y ago
    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?
    - vemv 9y ago
      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).

by vemv 9y ago

jmcphers 9y ago

> 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.

Terr_ 9y ago
> _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.
vemv 9y ago
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.
- krageon 9y ago
  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).

FireBeyond 9y ago

> 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.

vemv 9y ago
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.
- Can_Not 9y ago
  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.

ryandrake 9y ago

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.

vemv 9y ago
Good point! Anyway, my intent was to give an advice to developers rather than to employers.

yowlingcat 9y ago

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.

vemv 9y ago
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?)
- watwut 9y ago
  Why the hell would company not give such job to internal people? At least in my experience, these kind of jobs is what you can get after you worked in a company for a while and company trusts you. Giving refactoring task to someone who is new strucks me as odd. Also, why are not people doing feature development tasks not allowed to create abstractions where appropriate? Or high profile bugs etc? That is another odd thing. If I would be hired and it turned out I don't have that freedom and the interesting bugs, I would leave the company fast - especially if someone new would suddenly get these normally learn-a-lot tasks and freedoms.

watwut 9y ago

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.

vemv 9y ago
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.
- watwut 9y ago
  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?
  - vemv 9y ago
    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).