The Magic Of A Strong Portfolio

Having a strong portfolio is like bringing a bazooka to a knife fight.

When you show hiring managers what you can do instead of telling them, your lack of experience doesn’t really matter anymore.

The fact that you couldn’t solve their algorithm question in record time isn’t critical. And the fact that you didn’t go to Harvard isn’t a problem.

You have something better. You have proof that you can do the work.

I spent over 40 hours researching what makes a phenomenal portfolio for all types of different roles in tech: software, data science, product, UX, etc.

First, though, let’s address some misconceptions about portfolios.

Misconceptions

Misconception #1: Recruiters don’t have time to look at your portfolio

One of the biggest arguments against having a portfolio is that no one will look at it because recruiters have to forge through hundreds of applicants.

The portfolio is not for the recruiter. It’s for the hiring manager. And by the time you get to the hiring manager, he 100% has the time to look at your portfolio because it’s no longer 100 resumes (it’s like 10-15).

Misconception #2: Personal Website == Portfolio

Whilst it’s true that most portfolios are hosted on your personal website, they can be anywhere. A Github repo, a notion site, a mega article on Medium – as long the work you’ve done is on the internet and you are able to link to it, you have a portfolio.

You don’t need to spend hours on designing the “perfect” personal website. You technically don’t even need one.

Misconception #3: Portfolio is a “nice to have” and not something that can land me a job.

There’s plenty of people that have landed great jobs without a strong portfolio. But I think that the benefits of a strong portfolio extend way beyond just landing the “job”.

By working on projects you find interesting and sharing them with the world, you:

The above benefits extend into the long term and can be career defining.

Misconception #4: Only technical folks have a portfolio

In tech, the concept of a portfolio is generally tied to the following roles:

But I think that you can build a strong portfolio for any type of role. This includes non-technical roles like product and marketing.

This is because the best portfolio projects share a few themes.

And those themes can impress any hiring manager, no matter the field.

Anatomy of a strong portfolio project

The perfect portfolio project is:

  1. Fun
  2. Technically (or domain) relevant
  3. Explainable

A strong portfolio project only really needs to fulfill two of the above criteria.

Let’s walk through each one.

Fun

Most of your competition will just build clones of popular apps like Facebook or Reddit.

They’ll find the most popular Kaggle dataset and download the CSV file. Or they’ll write a case study on Web3 just because it’s in vogue.

We’re going to take a different approach. We’re going to work on a project that you find fun.

When you build something that you find fun, it means that you’re leveraging some domain knowledge you have or a competitive advantage of some sorts. And that makes you stand out.

For example, because I’ve spent the past two years writing this newsletter on tech careers, I find the data surrounding recruiting, the hiring market, and career progression really interesting.

And so it would be a competitive advantage for me to make a portfolio project in this space, as opposed to in a space like crypto which I don’t really care about.

The second aspect to building something fun is what’s in it for the hiring manager.

Let's say you want a job at Twitch. Don't just make a page that lists the top ten streamers.

Instead, make a page where people enter the name of two streamers and after your code has compared the stats of both streamers, a winner gets displayed in the style of a Mortal Kombat KO.

People like to do business with people they like. And if your portfolio project can convey a ton of your personality and energy, you’re going to have a much better chance of making an amazing impression.

Technically (or domain) Relevant

Use technologies that they have in their stack.

There are websites that help you find out what technologies companies are using to build their product. For client side code it's not very hard to find out by yourself: look at the source, look at the libraries that get loaded, beautify their code and have a look at what gets imported.

When building your project use as much of those technologies to show them that you are familiar with the technologies they use.

If your role is non-technical, just replace the word technical with domain. You want to build something that makes them think “Oh, X can already do the job because he knows so much about the field!”

Explainable

Hiring managers want you to be able to explain the decisions you made when building your project. Why did you use a monolith architecture stack instead of something else? Why did you decide to make the edges of the user’s profile box round instead of square?

Ideally, you start with some form of research question. This is your why. What do you hope to learn?

If you’re a data scientist, discuss your mode choice. It's fine to just use XGBoost for tabular data but at least discuss other choices that could be appropriate.

If you’re a product manager, set the scene: why did you solve this problem in the first place?

If you’re a marketer, identify the metric you’re trying to move: are you trying to increase traffic or improve conversion rate?

Examples

I’m going to give you examples of really strong portfolio projects.

Software Engineering: Frontend

Here are two really good ones:

I like the first site because it has a wow factor. Frontend designers can index really high on on that fun criteria.

When you take a look at the first site, you wished that your personal site looked like that. It reflects Peter’s creativity and the way he thinks about visual design.

Software Engineering: Backend

My favorite example of strong backend portfolio projects is the methodology that Launch School uses for their graduating Capstone students:

  1. Identify the types of skills the types of companies you want to work at are looking for
  2. Spend 3 months working intensely on building one “capstone” project that is levels above what your competition will produce along with teammates
  3. Write a technical case study about said project
  4. Market the project by presenting it at meetups or sending it out via email

Their projects index really high on the technically relevant and explainable factor.

Here are a few examples, in which we can see the technical relevance of the portfolio project mapped to the actual job the candidate ended up getting:

Backend Portfolio Projects

Data Science

I recommend:

  1. Choosing a project that leverages some prior domain knowledge you have within the field. This will allow you to differentiate your idea and separate you from the other off the shelf clone projects.
  2. Come up with a solid research requestion
  3. Hunting down data and wrangling it – don’t just download data_science_project.csv

Now that you have the data, you want to make sure that you fulfill the explainability criteria really well. Some things you can focus on:

Just like in the last section, there’s a lot of value in working backwards from the types of roles you want to target and working backwards to build certain types of portfolio projects.

We can split portfolio projects into two buckets: data cleaning and data storytelling.

The first type of projects, data cleaning, really focus on data collection.

Examples of good ones:

Whilst data storytelling projects also incorporate technical complexity, especially when it comes to data gathering, they make sure to include a compelling narrative.

Examples of good ones:

Both of these projects index high on the fun criteria as they tackle topics that are interesting.

Product Management

Let’s be clear: product managers don’t have “portfolios” in the same way that designers do. This is because as a designer, your portfolio reflects your skills directly.

But as a Product Manager, there’s no real “product” you can showcase because you build with your team. You didn’t develop or design the product, so taking screenshots of it is useless.

Instead, though, you can focus on the reasoning behind building the product, the challenges you encountered, the tradeoffs, etc.

Build a good set of stories. Show the conflict, choices, risks, decision, rationale, and results.

A case study that’s well written scores full marks on the explainability criteria. And in terms of domain relevance, setting the scene and discussing rationale should get you there.

Product Dribble Case Study

Some good examples of stories:

UX / Design

After combing through quite a few UX projects, I think the most important thing I want to highlight is that each designer will have his/her own strengths and weaknesses.

Your goal is to focus on your strengths. And use that to highlight whatever you build.

I think that the best portfolio project I’ve ever seen, never mind just UX or Design related, is Jason Yuan's redesign of Apple Music

The reason this is such a good case study is because it hits every index we discussed.

It’s fun in the sense that Apple’s rejection didn’t stop Jason from keeping getting better at his craft. That’s a storyline everyone can get behind and why his case study went viral.

The case study is also extremely good UX wise and is easy to follow.

But I think that the biggest lesson I want to highlight there is that the best portfolio projects have that X factor. They intrigue us, they make us want to reach out to the author, and they almost make us wish that we had built whatever they did.

And one last thing. Just like the other fields we discussed, your biggest competitive advantage is going to be working on a project that genuinely interests you.

UX and Product Designers come from all sorts of backgrounds. Some examples:

UX Portfolio Projects

Some good projects for inspiration:

Sharing your portfolio

You have a great portfolio. And now it’s time to share it with the world.

Sharing can mean many things. You can send it to hiring managers, post it on Linkedin, post it on Hacker News – but the keys to doing any of these things successfully is in answering two questions:

What did I build?

Why did I build it?

Some good examples of answering the first question are the Show HN posts on Hacker News:

HN Posts

For the second question, you want to tie it back to your interests and motivations. Sure, maybe you worked on that technology because your favorite company uses it and it will make you look good, but dig a bit deeper.

What excites you intellectually about the problem at hand? Why did you choose to explore the topic the way you did?

Your genuine interests here will shine and make you stand out.

***

Once you start to put work out there that you really care about, getting that dream job is literally only one of MANY amazing outcomes that could happen.

Until next time,

Shikhar



Get little knowledge packages sent to your inbox.

Read next

How I Flipped My Fears And Changed Jobs