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