Open-source skills best hope for landing a good job | Hacker News Reader

Open-source skills best hope for landing a good job

theregister.co.uk

83 pointsabhishektwr17 comments

The second-last paragraph makes a point I've seen touched on a few times but never fully developed: That the labor of software developers is an economic complement to code. When developers write code and release it for free, we are commoditizing our complements [1]. Operating systems, libraries, frameworks and the like increase the productivity of developers, so by making those widely available, the demand for developers is increased.

Calling open source a "labor movement" as the OP mentions is not far off, considering its effects on control of the means of production.

[1]http://www.joelonsoftware.com/articles/StrategyLetterV.html

Question to all those in a hiring position: when looking at a candidates' purported open-source credentials, how closely do you inspect the work? Enough to tell if the improvement was fluff? Or a rehash of other code? If it looks like said candidate has a lot of commits, how do you discern the ratio of quality commits?

While my hiring manager experience predates GitHub, I would be more concerned in verifying that they actually did what they claimed than that I agreed with the specifics of their commits. If they got the the tasks completed, that's a Good Sign.

People lie horribly on resumes. I would not be surprised in the least to see people claiming GitHub accounts that are not their own. I have seen LinkedIn career logs from MSFT with people claiming to have done things that _I_ did back when I worked there. One of the most annoying things about phone screens was the huge number of them where it turned out the person was a complete, total liar. I spent much more time on verification than details.

After all, most decisions in the small only make sense in the context of the whole program, history, backwards compatibility needs, project plans, etc. and it would be pretty arrogant to second-guess somebody's patches to a large system without the greater context.

There are often too many applicants to spend more than 5-10 minutes looking at any one person's resume and open source projects. I usually spend a few minutes on the resume looking for interesting projects or relevant work experience, and then a few minutes looking at an applicant's GitHub page (if it's provided).

Things I look at on a GitHub page:

- # of projects that are not forks. The person might have done a lot of work on the forks, but it's too time-consuming to figure out what code is theirs and what code is pulled from someone else.

- The nature of the projects. Are they mostly trivial ("My .bashrc file") or awesome ("In-memory distributed search engine with replication")?

- Whether the person has good documentation skills. I look at a few sample commit messages, project README files, docs within a few random source files, etc.

- Good coding skills: decent style, no red flags in terms of quality, well-polished code, decent error-handling, etc.

From my perspective, a bad job on open source projects is a red flag, a good job can really help you distinguish yourself, and anything else doesn't significantly help or hurt your application.

The Impact graph on the Stats & Graphs page gives a quick summary of recent major contributors to a repository. However, if you want to gauge the total contribution of a person across all projects, you have to check the impact graphs individually for each repository. Still no search for commits, it seems.

> # of projects that are not forks. I think forks are important as well. The more number of active forks, the more the person is actually working with other people on a project.

Personally, I'm always pleased to see an open source project on a candidate's resume (provided they contributed significantly to it, of course). It's always a good way to evaluate a candidate's skills outside of a technical interview.

I am just curios, how you evaluate the "contributed significantly" especially if someone is contributing to documentation side of the project?

I'd argue that is a significant contribution. How many open-source projects are well-documented? Very few!

Granted, I'd personally prefer to be able to view a candidate's coding style, but I would certainly not ignore a candidate who contributed to documentation on a project. I'd just make the tech interview a little harder ;)

I would highly welcome a candidate who has proven clear documentation abilities.

As would I!

Documentation won't necessarily let you see someone's coding quality, but like technical blogging it will give you an insight into the level of technical capability the person has and their ability to speak clearly on technical subjects. All of which are very critical skills on the job.

The appeal of hiring someone who is actively involved with open source tech has less to do with heroic coding skills and more to do with identifying someone who is a curious, enthusiastic, and community-minded problem solver.

Exactly! If you have an open source (or any other!) portfolio, you're already ahead of 99% of the people I interview. Odds are that I won't actually look at your code. Instead I'll ask you technical questions during the interview about the project itself: architecture, design, problems you ran into and how you solved them. How you handle bug reports, etc.

Pretty much the same thing I do with other projects on a resume, but much more focused.

Is this the difference between US and UK market?

I remember reading something different for US:

http://articles.businessinsider.com/2011-10-06/tech/30250041...

Most open source applications would include "Windows" in the skillset, so the compariosn doesnt really hold. jQuery is crossplatform. They should have compared "python, php" to "c#, java".

I don't see how this article demonstrated its claim in the least.

Reply on news.ycombinator.com