I occasionally interview candidates for a small software team (less than 10 developers). When evaluating a candidate's GitHub account, I look for any non-forked

I occasionally interview candidates for a small software team (less than 10 developers). When evaluating a candidate's GitHub account, I look for any non-forked projects (projects that they created/own), then I look at the structure, code, documentation, and commit history of those projects. At that point, the quality of the project can either help or hurt the candidate: - The most important thing is that whatever project content they have, it is understandable. The ability to write sensible code that follows conventions and is well-documented (in code and commit history) is highly desirable. - Ideally, they'd have an open source project with recent releases, issues, milestones, contributors, PRs, etc. (basically all the signs of a healthy open-source project). If they had this, then they'd be way ahead of most candidates. - It's easier to evaluate docs and commit messages than it is to evaluate code quality, but I do try to pick out a few files and have a look to see if they make sense.