A picture with a friendly smile can help recruiters make a connection with you but it isn’t mandatory. If you’re not using a picture of yourself be sure to include a picture that somehow captures your personality. But nothing crude.
Below is some general information and a link to his email and twitter profile. Recruiters can look through your tweets to get a sense of the things you are interested in.
The descriptions are nice so that we know what these repositories are for. Having an impressive list of contributions to repositories. This is a clear indication that you are involved in collaborating with others on open source software. Employers can look through your contributions to judge how well you work on a team.
This is one of the first things a hiring manager is going to look at. Each square is a day. The darkness of the green indicates how many contributions were made on that day. It’s pretty clear when someone spends a lot of time working with code. A good sign to a recruiter. The heat map with the activity gives a really good sense if people are passionate about coding. It doesn’t have to be all the time but here it is: People who love to code have steady patterns that correlates with the success in the workplace.
A well written ReadMe is one of the most important parts of a good repository. The reading is necessary for others because it tells people:
- What the code is for
- How to build / install the code
- How to contribute
This is an important skill. You should learn how to write documentation for humans.
Commit messages are essential for communicating why your code was changed. This is for your coworkers or collaborators, and also for your future self. Let’s go through some best practices for writing commit messages.
Here is a message format you can use:
type: subjectbodyfooter
The first line is the subject. This should be a short description of what changed. Nothing like fixed it or did something, these need to be clear and informative, and try to avoid profanity. The subject should be 50 characters or less, with the first letter capitalised, and end without a period. You should also include a short annotation about the type of the commit, if it is a bug fix, a feature, change to the documentation, etc.
The body is next, this is where you give a more detailed description of why you made the change. The body should typically have around 72 characters per line. This is to ensure that the message fits into a terminal window when using git on the command line. You’ll also need to make sure there is a blank line between the subject line and the body. You can also add bullet points, using asterisks or dashes, when you need to make a list. Some commits don’t require a body in the message. If you fix a typo for example, it’s okay to only have a subject line. You can also include a footer, typically this will be used to indicate which issues or bugs the commit addresses. A more fleshed out example looks like this:
feat: Summarise changes in around 50 characters or lessMore detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of the commit and the rest of the text as the body. The
blank line separating the summary from the body is critical (unless
you omit the body entirely); various tools like `log`, `shortlog`
and `rebase` can get confused if you run the two together.Explain the problem that this commit is solving. Focus on why you
are making this change as opposed to how (the code explains that).
Are there side effects or other unintuitive consequences of this
change? Here's the place to explain them.Further paragraphs come after blank lines. - Bullet points are okay, too - Typically a hyphen or asterisk is used for the bullet, preceded
by a single space, with blank lines in between, but conventions
vary hereIf you use an issue tracker, put references to them at the bottom,
like this:Resolves: #123
See also: #456, #789This does come with an exception of course.
If you are working on an open source project, be sure to follow the message format for that project. This will make the maintainers happy and increase the chance your pull request is accepted.
As a programmer, you’re often going to be working with others on a shared code. So employers want to see that you can collaborate. By contributing to open source projects, you can demonstrate how well you work with others. It also shows that you’re helpful and love working with code.
Apply these best GitHub practices moving forward and attract the attention of recruiters and senior software engineers.
You’ll want to:
- Commit every week, at minimum
- Get 2–4 weeks streaks
A personal side-project may grow into something bigger. You can’t always predict what will catch the eye of a recruiter or senior software engineer, but when it does, you want to showcase your best work.
Once you’ve implemented the necessary changes to make your profile more professional, remember to maintain activity by regularly making commits on GitHub.
Good luck & Happy Coding! 
