In my last post, I talked about how to setup your GitHub profile when looking for a job. Now that your GitHub profile page is looking good, shape up the details of your top repositories. You can customize the six popular repositories that appear on your profile page. These repositories should show off your best work and match the skills needed for the position you’re currently seeking.
When I’m reviewing a candidate, I sometimes skip the popular repositories and go to the repositories tab. I like to see what the candidate is currently doing. Projects appear in order by most recent commit on here. Since a recruiter or hiring manager might only look at one or two projects, be sure those at the top of the list look good.
Once I click on a project, it should be pretty easy to see what you’re trying to accomplish. Include a brief description at the top of the repo. Explain what the project does in simple terms. A few sentences is enough. You’ll provide complete details later in the README file.
Next, include a website. If this is a web application, this should probably be the address of a live demo. Even better, link to a post on your site that describes the project. That post should then link to the live demo. A demo running on a free Heroku site is fine.
As the reviewer scans down the list of files, there should be a clear structure. Most frameworks, such as Ruby on Rails, provide this structure for you. Things I look for include a breakdown of the application into components, usually following the model-view-controller pattern, and a test or spec directory.
After the list of files in the project, include a detailed README file. This is your chance to elaborate on the purpose of the project. What is special about this application? What technologies did you use to build it? What did you learn from this project?
Finally, explain how to run the project locally. What are the requirements, and how do I install the correct versions? Again, the framework and tools you use should make this easy. Hopefully everything is just a bundle or yarn command away.
Now that I know what your project is all about, it’s time to dig into the code. I’ll cover what I look for in a code review in my next post.