I recently found myself at a Meetup where half of the attendees were from a local front-end bootcamp class. They were connecting, looking for future job prospects, and practicing their soft skills. They came off as energetic, engaged, and hopeful.

And somehow I found myself inspired to give advice that I’ve built up over the last decade or more of screening resumes and candidates. I hope they put the advice to good use. Now, I couldn’t give them all the tips I would like to. I would have bored them to tears with my talk. However, I want to share my thoughts with a wider audience.

I want to share these tips with you, the recent college or bootcamp grad, that doesn’t know how to stand out from his or her classmates that worked on exactly the same projects. It’s tough. And as bootcamp grads, or college grads, at least 70% of your GitHub repositories look exactly the same.

And that’s the problem. When you evaluate entry-level software developers, you need to find what makes one candidate stick out over another in just a couple of minutes. But when everyone does the same thing, it becomes more of a coin toss.

So what can you, an entry-level developer do? Do you need to spend months writing large projects or create amazing new applications? No. But you do need to take steps to improve your GitHub repos.

For today’s post, I’m going to take you through some examples of what I consider when reviewing your GitHub repo. These things may not be what all hiring managers or leads look for, but I know I’m not alone. And most of these suggestions won’t take months to implement.

Now let’s get started.

Do Your Repositories Stand Out?

Earlier I mentioned that 80% of repositories and GitHub profiles look the same. I made that number up based on my personal experience, but I don’t think I’m too far off the mark.

Don’t believe me? Just do a search for repos with something like “Lab 1” or “Lab 16” in the name. Then go to the owner’s profile and take a look around. Even though languages and problems vary, most of them look the same. So how can we make ours stand out? Let’s review the following tips.

1. Rename Your Repos

I get it, the instructors want your repos named with a lab or exercise number. However future employers don’t know what to do with this. We’ll maybe click in one or two of them to see if we can decipher what the code does and then give up and move onto another candidate.

For this, you have two options. First, you could append a meaningful name to the lab or exercise number. For example, instead of Lab 1, use Lab 1 – String Calculator.

Second, once your bootcamp class completes, feel free to rename your repos so that the name denotes what the program does.

Either way, you’re helping software developers that review your GitHub so we can drill into some of the more interesting examples.

2. Update Your README

Most lab examples don’t even include a README. However, in the real world README’s provide critical information on the usage of applications. Take a look at some examples of software libraries you’ve used to see what the README’s should contain.

For example, head on over to the Vue.js and see how much information gets put in there. As another example, head over to the Joda-Time GitHub repo for a shorter version of a README. Since Jada-Time is much smaller than Vue.js, less documentation is necessary.

Now you don’t need as much information as larger projects. But at the very minimum, add a short README and make it descriptive.

In other words, don’t create a README with just this:

Countries Application

But instead, do this:

An application that allows users to display lists of countries from a text file.

To build the application, clone the repository and run `mvn build`

To run the application, type mvn exec:java

3. Pin Your Best Work

When I look at your GitHub profile, your page displays a list of your most popular repositories. These may not be the projects you want your future employer to review.

Pick out your favorites and make sure they’re showing off your best work. Then pin them to your profile to make sure everyone sees what you want them to see on your profile.

4. Add Tests

Most companies now have some level of automated testing. If you want to stand out, show off some of your skills by adding a few unit tests to your repositories. It will let your future employers know that you’re at least familiar with basic testing concepts. Therefore, they know you’ll be able to hit the ground running faster than candidates that don’t use unit tests.

A word of caution here, however. I’ve seen many Java Spring projects where the developer used Spring’s initializer to create a basic template of the project. Part of that initial code includes a default contextLoads test. The only code this tests is whether your app can start or not. It does not give you any points.

You see, when I look at a project that has a test folder, I get my hopes. And I dive into it hoping to find something good. But I just end up seeing nothing but autogenerated code. Yuck!

Any amount of testing trumps no testing. Just put in a little effort and your repository will shine.

5. Use Configuration Properly

Another one of my pet peeves involves seeing code like this Java example:

private static final String JDBC_URL = "jdbc:postgresql://localhost:5432/my_awesome_db";
private static final String JDBC_USER = "myAwesomeUser";
private static final String JDBC_PASSWORD = "87654321";

There are actually a few problems here. First, these values don’t belong in your source code. They belong in configuration files or, in the case of the user id and password, in a system designed to store secrets.

At a minimum, pull those properties from a configuration file. Additionally, don’t ever store secrets in your GitHub repository. For the Java example above, let’s assume we’re using Spring. So we can add the following to our application.properties with placeholders for our secrets. Even if the user id and password aren’t real, treat them as if they were.

app.jdbc.url: "jdbc:postgresql://localhost:5432/web_lab_db"
app.jdbc.user: “<INSERT USER HERE>”
app.jdbc.password: “<INSERT PASSWORD HERE>”

This shows prospective employers that you understand what configuration does and that you understand at least a bit of security.

6. Use a Linter And Style Formatter

Code that follows a common practice looks cleaner and more professional. Additionally, using a linter ensures that you’re not making any common mistakes. Am I going to dig through your code looking for mistakes? No. But if you can reduce the amount of poor formatting and common mistakes, why not do it?

An additional note about formatting and style. Years ago I worked in an organization with a programmer that never indented things. Now, I understand that this is a really bad outlier, but it enforces my point. I struggled taking his code seriously. How can anyone appreciate his algorithmic knowledge when his code was unreadable?

7. Use .gitignore

Let’s look at a short list of folders and files that shouldn’t be committed in your git repository:

1. Operating system files: .DS_Store, Thumbs.db
2. IDE files like .idea
3. Language and framework files: jars, wars, and other executables
4. Directories of compiled code: target, bin, classes
5. Files from package managers like node_modules
6. Credentials and secrets Again, like other points on this list, knowing how to use your .gitignore properly will give you an edge over your competition.

8. Use folders and packages

A small percentage of repositories I review have no folders. They’re just repositories with 20 files and no organization. Unless there’s something else amazing about the candidate, these applications get thrown out.

Most types of applications use a standard folder structure. Look up what it should be for your language or framework and follow it.

Get A Leg Up On Your Competition

You’ve made it through my list. Congrats!

And you may have noticed that many of these items don’t have too much to do with the code itself. You’re an entry-level dev. Your code will not be as complex or performant as many applications. And that’s OK. We’re not looking for senior-level programming for entry-level positions.

But we still want to see something that stands out. Show your future employer a level of professionalism that doesn’t exist in many lab-type repositories. Show that you’re a professional that cares about standards and does more than just “make it work.”