
Ask HN: Hiring managers of HN, what do you look for in a candidates GitHub repo? - polygot
For those that use a candidate&#x27;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?)
======
tedyoung
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).

