For those that use a candidate's GitHub profile as a factor in the hiring process, what things in their profile would make them more hirable (code quality, # of repos, followers, etc?)
Disclaimer: I don't need someone to have an active GitHub profile, and I wouldn't favor them over someone who didn't just because they did.
However, I would be only looking at the repo content -- I'm not concerned with popularity contests of stars or followers.
I'd bucket the repos into three categories:
1. A fork of another project, which would be further divided into:
a. Just a copy, didn't contribute very much -- perhaps a minor doc submission, or just a fork so they could make some minor changes on their own that wouldn't be submitted back.
b. Used to make non-trivial amount of contributions to the original project, in which case I'd be looking at their Pull Requests.
c. Fork to revive/carry on a project that is dead/dormant. This is interesting and I'd want to see in the README why this fork exists, why it should be used instead of the original, etc.
2. Personal projects that are either:
a. Throwaway/one-offs: where they wrote some example to play with a library or API; something for learning purposes, but isn't intended to be maintained or grow over time. These are somewhat interesting, but I wouldn't be paying too much attention to quality (e.g., tests) for these.
b. Projects for a very specific purpose that are maintained over time, but not meant for others to actively use or contribute to (that can be because it solves a very specific problem, or it's pretty complete and stable).
3. A project that has outside contributions and a community built around it. This is going to be much more rare than any of the above, so I'd be giving it much more scrutiny: how long have issues and (especially) PRs hung around with no activity? Do they treat other people (contributors, those who file issues, etc.) well? How's the documentation and onboarding experience? Does the project explain why it exists instead of contributing to other projects that might do the same thing?
When I look at the code in any of the above cases (except for 2a), I'm looking for how easy is it to see why changes were made, or the size of commits and the clarity of commit messages. Does it have continuous integration set up?
If the candidate then comes in for an interview, and has anything non-trivial in their repo, it would become a topic for discussion. If not, there are other projects we'd talk about (or write).
However, I would be only looking at the repo content -- I'm not concerned with popularity contests of stars or followers.
I'd bucket the repos into three categories:
1. A fork of another project, which would be further divided into:
a. Just a copy, didn't contribute very much -- perhaps a minor doc submission, or just a fork so they could make some minor changes on their own that wouldn't be submitted back.
b. Used to make non-trivial amount of contributions to the original project, in which case I'd be looking at their Pull Requests.
c. Fork to revive/carry on a project that is dead/dormant. This is interesting and I'd want to see in the README why this fork exists, why it should be used instead of the original, etc.
2. Personal projects that are either:
a. Throwaway/one-offs: where they wrote some example to play with a library or API; something for learning purposes, but isn't intended to be maintained or grow over time. These are somewhat interesting, but I wouldn't be paying too much attention to quality (e.g., tests) for these.
b. Projects for a very specific purpose that are maintained over time, but not meant for others to actively use or contribute to (that can be because it solves a very specific problem, or it's pretty complete and stable).
3. A project that has outside contributions and a community built around it. This is going to be much more rare than any of the above, so I'd be giving it much more scrutiny: how long have issues and (especially) PRs hung around with no activity? Do they treat other people (contributors, those who file issues, etc.) well? How's the documentation and onboarding experience? Does the project explain why it exists instead of contributing to other projects that might do the same thing?
When I look at the code in any of the above cases (except for 2a), I'm looking for how easy is it to see why changes were made, or the size of commits and the clarity of commit messages. Does it have continuous integration set up?
If the candidate then comes in for an interview, and has anything non-trivial in their repo, it would become a topic for discussion. If not, there are other projects we'd talk about (or write).