There is a massive confusion that up-and-coming developers have about what it takes to get a job as a developer. People believe that a professional portfolio site will help them land a job as a web developer – and this belief couldn’t be farther from the truth.

In fact, while aspiring developers are spending countless hours making their portfolio sites pixel perfect, experienced developers are busy ridiculing how utterly pointless portfolios are. Developer portfolios are taken about as seriously as most people took Jar Jar Binks in Star Wars: The Phantom Menace.

I get it. As an aspiring developer who doesn’t have a history of previous web development jobs, proving your skill and aptitude can be hard. But please trust me when I tell you that the people who are reviewing you as a candidate don’t care about what your portfolio looks like.

You could have the flashiest portfolio on the planet. Or your website could look like Richard Stallman’s— an architect of compilers, debuggers and text editors, representing the leader of an open-source movement and one of the world’s most prolific programmers of our time. Developers don’t care.

Instead, hiring teams spend their time complaining about how 199 out of 200 applicants for a programming position can’t even do basic programming. Regardless of how well-designed a portfolio page is, or how many apps a candidate has built, nothing changes the fact that the only thing employers care about is how skilled candidates are at the craft of programming.

So stop worrying about stuff nobody cares about. Instead, focus 100% of your effort on showing that you’re an adaptable programmer who is capable of writing complex programs.

If a portfolio isn’t a good tool for that job… what is?

Showcase your code

The code you write will speak for itself – use this to your advantage. It will convey exactly what your process and skill level are. Given the limited amount of time you’ll have to impress a potential dev team – you should spend 100% of your time showing off your code.

Your code samples will be the answer to the questions: “What does the code that this candidate writes look like?” and “What type of code can this candidate potentially write for me?” This is what the team hiring a new developer really cares about.

So instead of talking about portfolios, let’s drop down, flip it and reverse it, and talk about the best way to showcase your code.

GitHub

In most cases, your code will exist on GitHub – a web application that allows people to collaborate on the same project. Your code on GitHub is what dev teams will care about.

When you work on a team of people – and are using git in a more advanced mode than you generally would when working on projects by yourself – you’ll find yourself using something called a pull request quite often. A pull request (or what developers sometimes abbreviate as a PR) is a proposal to make a certain code change.

You will want to find a pull request you’ve made that you feel most proud of, and showcase that one. Sharing a link to that pull request in a cover letter is a better idea than sending whoever is reading your cover letter to a wishy-washy portfolio page.

The anatomy of a pull request

In general, a pull request is used to propose an added feature or bug fix to a project that’s being developed by a team. Here’s an example of one. You’ll notice it includes a title and a description.

Having a smart title and description that succinctly describe what your code is doing and why it’s important will give the person reviewing it (the one considering hiring you) an idea of how you’ll propose code changes on their product.

That gives invaluable context and provides an idea of what to expect.

Conversations and feedback

Most software teams and projects care a lot about code quality and want to make sure everything that gets added to their project is a good idea – a process called code reviewing. To promote this, GitHub allows people to have conversations about the code right on the platform.

How you react to feedback on a pull request will show an employer how you take criticism of your code – something that will happen on a regular basis. Are you the type of person who says, “it’s my way or the highway” or do you work well with feedback?

The actual code

And finally – the part of the pull request that matters the most. What actual code did you write? This is where people will spend most of their time looking. On GitHub, there is a tab on the pull request which will take you to the code:

GitHub will show you the code in a format that is a bit tricky to read at first, but it gets easier to read with experience. It shows the “diff.”

A code diff represents the differences, or basically the lines you added and the lines you removed. We don’t live in a perfect world, and bad stuff will probably end up in all code bases, but what you will be judged on is how you incrementally change the code base: did you leave the code in a better or a worse state?

The lines you added will be in green. And if you removed any lines of code, they will be listed in red.

These lines of code are what you’ll be judged on, so focus on becoming a solid developer and writing the best code you can. At the end of the day, it’s really the only thing that matters.

Here’s how your code will be judged!

Here’s what development teams will judge you on.

How complex is the feature you added? If you’re showcasing a pull request that isn’t complicated or that most developers would be able to do quickly, dev teams will probably assume you aren’t capable of building complex logic.

Instead, make sure to focus on complicated code that’s beyond the typical and simple web application stuff that other junior developers are capable of. By doing this, you’re showing that you can handle the hard stuff!

Do you follow ‘best practices’? Best practices are the methods that developers have decided are generally a good idea. For example, did you write automated software tests for the features you added? (These are often called Test Driven Development.) Code that is well-tested is better than code that isn’t tested at all.

There are certain patterns of where things should go in a web application (often called MVC in Rails). Are you putting the code you’re writing in the right spot, or shoehorning it someplace to get it to work?

Do you follow a style guide? When it comes to coding, it’s often said, “there is more than one way to do it” aka TIMTOWTDI (pronounced Tim Toady). Even though there are many ways to do things, consistency is usually a good idea.

Most programming languages have Style Guides, which suggest how to write code in a clean and consistent way. If your code follows a style guide, it will be easier to read and people will generally consider it to be better. There are tools like RuboCop and JSLint that automatically check to make sure your code is good.

Do you use style guides with your code to make sure you’re writing the best code you can, or are you just happy that your code works?

Is your indentation proper? In a text editor, using a tab will look about the same as using 2 spaces. And in ruby, indentation doesn’t matter. But on GitHub, the difference between tabs and spaces is huge!

Having messed up indentation on the pull request that you’re featuring is one of the easiest ways to lose credibility as a programmer, even though it’s something silly that won’t impact how the code actually runs.

Being judged on your code is a great thing!

The idea that the perfect portfolio will help you land a job as a developer makes sense, it just isn’t substantiated by reality. Everyone wants a silver bullet that solves all of their problems, and a beautiful portfolio seems like a nice way to put lipstick on a pig. Luckily for us as developers, superficial things like building a portfolio are not important.

Instead, what really matters are the hard skills in coding, the ability to tackle complex problems, and the style of the code you write. While you can build a portfolio in several hours, what hirers will actually measure is your skill level – which will be constantly improving throughout your entire career.

Do you know someone who really needs to read this? Be a good friend and share this post with them!