Your Portfolio Could Probably Be Stronger
Getting your first job as a software developer is not easy. Getting your first job as a software developer right out of a bootcamp is friggin' hard.
Sure, you keep hearing statistics about how engineers are now more in-demand than ever before (they're true!), and sure, your bootcamp guaranteed that you'd find a job within six weeks, and sure, every company has a dozen job listings and half of them even have "junior" in the title... but somehow it's still not easy.
Why? Because developers are expensive. And to most non-developers, they're mysterious. Hiring managers want to know that if they're shelling out $70-110k/yr for a developer, they're going to be good. And especially if the hiring manager is non-technical, it's very hard for them to know that. The truth is, it's hard to interview for engineering talent. We can make as many tests and challenges as we want, but there just aren't that many valuable signals for estimating a developer's performance, short of working with them directly for a week or two—and that's challenging for all parties involved.
So, hiring managers tend to focus on the variables they can control. They bias towards people with a work history and recommendations. Or people who have a 4-year degree. Or people who are well-known in the developer community. But what if you're not any of those things?
What if all you have is a graduation certificate and a hunger to keep learning and building cool stuff? It's true: you're in a tough spot. You don't have that many options. But you do have one option: the portfolio project.
No, what I'm telling you isn't groundbreaking or revolutionary. Yes, this is what your bootcamp instructor has been telling you all along. Yes, I'm sure you've read a half dozen blogs about the topic. But keep reading, because here's the kicker: most portfolio projects suck.
That's right: well over four in five portfolio projects are garbage. And the truth is, having a bad portfolio project is much worse than not having any at all. Too many people treat portfolio projects as a bonus, as a cherry on top of their education, or a bow tied onto their resume.
If you don't have any work history, your portfolio project is the only thing that matters. As someone who has reviewed hundreds (if not thousands!) of resumes, I cannot stress their importance enough.
So here's the million-dollar question: how do you make your portfolio projects not suck?
1. Build for your audience
Maybe your portfolio project is a yelp clone. Your audience is the hiring manager.
Maybe your portfolio project is a social network. Your audience is the hiring manager.
Maybe your portfolio project is an e-commerce site. Your audience is the hiring manager.
It doesn't matter what your portfolio project is. Your audience is the hiring manager.
What this means is you should make it very, very, very easy for the hiring manager to see your best work.
Let me tell you a list of things that your hiring manager does not want to do:
- Download your app. Make your portfolio app run in a browser.
- Build your app. Your app should be hosted and ready-to-go.
- Guess what your app does. It should be obvious what your app does, who it's for (other than the hiring manager), and how to use it. If this means popping a modal the first time someone hits a page that says, "Welcome! This app was build for XXX to help them YYY by doing ZZZ", then pop a modal the first time someone hits the page.
- Create an account, especially with email verification. If you want to show that you can build a sign-in flow, great. More power to you. But for Christ's sake, please add a "Log In As Guest" option. I can't tell you how often I open a portfolio project only to immediately close it because I don't want to make an account.
- Input data to see functionality. Your app should already have good, readable dummy data in it. Don't make your potential hiring manager make three accounts just so they can see how your group messaging app works.
I know that all of this is tough. Once you finally finish your app, the last thing you want to do is find a hosting service, create a permanent test account, and populate a bunch of dummy data. But I can't stress how important it is to do these things: if you neglect any of these steps, you immediately, dramatically increase the chance that the hiring manager will never see what you built.
2. Invest in design
If your portfolio project is some kind of website or app, you need to worry about design.
Don't protest. Don't tell me "I'm not a designer", or "in the real world I'd be working from comps". This is the real world. Your portfolio will be evaluated against real portfolios from real professional engineers who have worked with real professional designers. Their apps are crisp and snappy and clean. Yours should be too.
Depending on your skills and ability, this might just mean spending more time sweating the details in your UI. Spending just an hour focussing on things like color, typography, and layout can make a big difference. Better yet, start all of your projects by making them with a design prototyping tool. It's a good skill to learn anyway.
But if you don't want to do that, just hire a designer. That's not cheating, it's smart. Just be transparent about it.
I know: it sounds like a real hassle, and it sounds expensive. But, believe it or not, there are tens of thousands of designers out there who make their own portfolio projects, who would love to have an eager developer execute them. Do this: go to dribble and search for any project you'd like to work on. Hell, search for a project you've already built. Nine times out of ten you'll find those, too. Then, contact the designer—most would be thrilled to provide detailed comps for a nominal amount, and I'm sure many would even be happy to collaborate as long as you take care of hosting the app and they can put it in their portfolio, too.
I get alot of pushback on this point. People tell me that they're engineers, not designers, so they shouldn't be evaluated as designers. That's fine and well, but your portfolio project is the only thing I know about you. Your hiring manger can't evaluate you just as an engineer. There just aren't enough data points. Then can only evaluate you based on what you give them—so it's really in your best interest to make sure every part of every thing you're giving them is great. First impressions count.
3. Don't build a friggin' to-do app
I don't care if it's React, or Ember, or Angular 19. I don't care if it's responsive or works on your Apple TV. I don't care if you built the whole thing in Canvas (why??) or if it has multi-language support or pomodoro timers built in. It's boring.
I have seen one million to-do apps. No matter what you've made, it will be boring.
Even worse than that, it screams "I am a new developer". What is the first project a developer works on? A to-do app. Why would you want to broadcast that you've done a single project? That message is not reassuring to me. For my sake and for yours, skip the to-do app.
4. Showcase your best work
Here's the thing about new developers: they're still learning alot. They're learning quickly, they're learning hungrily, they're getting better every day.
The result of this, though, is that all too often bootcamp grads have three or four projects in their portfolio, and each one is significantly better than the last. Or, seen in the opposite order: each one is worse than the last.
When you're selecting which projects to put in your portfolio, it's important to remember that the hiring manager is trying to answer two questions:
- "How will this person help my team succeed?"
- "How risky is hiring this person?"
By showcasing your best work, you help the hiring manager answer Question 1. But showing mediocre work does not solidify that answer—all that does is raise red flags around Question 2. Here's the litmus test: review each of the projects in your portfolio. If you feel like you could re-do any of the projects and achieve a better outcome, remove them. They're not indicative of your abilities now, so they don't belong in your portfolio.
5. Invest in complexity
This is a big one. The trouble with bootcamps is that they're on an aggressive schedule, and they optimize for quantity. They promise you you'll graduate with three or four finished projects, but the inevitable side effect is that each of the projects is relatively simple. Simple CRUD operations, maybe some local storage, maybe a redis datastore. It's just not realistic to build anything else that quickly.
In the real world, though, applications are big and ugly. There are dozens of engineers touching any given part of a codebase, and data is manipulated and filtered and piped all about. Systems have synchronous elements and asynchronous elements and components depend on data from multiple sources.
My point here is that a CRUD application is not the best proxy for the work you'll be doing, and so CRUD portfolio projects aren't the best way to convince your hiring manager than you are not a high-risk candidate. So, two options:
- Instead of building many projects, focus on one robust one (see above, "Less is more")
- Collaborate on open-source projects
Getting involved with bigger open source projects is hard for the exact same reasons that getting involved with bigger open source projects is valuable. There are lots of moving pieces, a whole ecosystem to understand, and rigorous code quality standards. It can be intimidating.
But as long as you remember that intimidating !== impossible, you'll be fine: start with a small PR, build up your understanding of the codebase, make some friends in the community. Without a doubt, this is the best way for new developers to demonstrate that they can and will be useful when diving into a new project.
Following these five steps will not make you a better developer. They won't make you a strong engineer, and they won't guarantee you a job. But they are the best way for you to put your best foot forward, and to make sure that the skills you do have are properly evaluated, not ignored for reasons you can easily remedy. Good luck!