{ The Rithm Blog. }

Four Software Engineering Portfolio Protips September 24, 2020

Whether you're looking for your first tech job or your 50th, you'll probably need to do some prep work before you start applying. Aside from studying data structures and algorithms, you may want to revise your personal website or start work on a new side project. 

In working with aspiring junior engineers, I've given feedback on many personal sites and portfolio projects. Most of the time I find myself giving very similar feedback. In this post, I'd like to share with you the most common advice I give to people when it comes to the work they want to share with future employers.

1. Show who you are.

By this, I don't mean that you should plaster your personal site with selfies. But you should strive to make an impression. Recruiters will spent very little time with your personal site, so do what you can to make yourself memorable. You could do this any number of ways: through a nice design, through imagery, or with a well-written (and concise!) bio. Play to your strengths.

This is also where people from non-traditional backgrounds often have an advantage. While you may have a bit of imposter syndrome if you don't have a CS degree or prior engineering experience, your unique history can often make it easier for you to set yourself apart. The key here is to frame that history in such a way that your transition to software engineering sounds like a natural one.

2. When it comes to design, less is more.

You have a lot to say and several great projects to show off. I get it. But very often when I look at a personal site or side project, my eyes glaze over and I get overwhelmed. It can be tempting to try to cram as much information as possible onto the page, but visitors to your site will have an easier time if there's less for them to process.

In terms of practical advice, usually this translates into a recommendation to embrace empty space. Not every inch of the screen has to have something on it. The more empty space, the easier on the eyes. You can still put a lot of information on your site if you choose, just make sure that it has room to breathe.

laptop on desk3. When it comes to functionality, less is more.

The last point was focused on how your sites look. Here I'd like to emphasize how they function.

Sometimes I work with people who have very ambitious plans for a portfolio project. They have a huge list of features, spend a long time building it, and then want to show off their hard work to potential employers.

While well-intentioned, this line of thought assumes that potential employers have the time to pore over every feature of your application. Typically, this is not the case. For the most part, people only have a few minutes to spend looking through your portfolio. Rather than completing a laundry list of features, I'd encouage you to focus on building projects that just do one or two things really well.

Here's an example: over the course of a few review sessions with a recently-graduated cohort, we built a small app that can display time in different colors, to help people who can't yet tell time know when a transition is coming. You can experiment with it here. I had the idea for this app when my pre-schooler started having difficulty leaving the house in the morning, and though this might help him (spoiler alert: it didn't). 

This color clock app has very few features. But what it does it does well, and since there's not much to do, it's harder to get confused.

Want another example? A former student of ours built a small mobile app that you could use to take pictures of food and learn if that food is paleo or not. She wrote about the experience here. Once again, in terms of features, this app doesn't do much. It just does one thing well. This makes it easier to understand, use, and discuss.

Assume that anyone who stumbles onto your side project won't spend more than a few minutes with it, and plan accordingly.

This brings us to our last tip.

4. Keep your audience in mind.

If you're building projects with the specific goal of getting hired, remember that there are two broad categories of people who will be looking at your work: technical and non-technical.

For the non-technical stakeholders, what's impressive to you isn't necessarily impressive to them. For example, suppose you decide to add the ability for people to sign up to your app using Facebook or Google. OAuth can be tricky to get working, especially the first time you do it, and you may find it takes a lot longer than you originally anticipated. 

When you finally get the feature working, you feel great. But to someone who's accustomed to seeing OAuth on practically every web app out there, this feature might not seem as impressive as you think it is, given the amount of time you spent on it.

In other words, try to spend your time building things that will impress people even if they won't understand the technical details of how you built them.

On the other side of the equation, once technical stakeholders start looking at your work, you want to be sure to impress them too. So make sure to invest some time behind the scenes working on aspects of the project that aren't readily apparent from looking at the finished product. Make sure your code is well-organized and easy to read. Include a thorough README on GitHub, one that includes setup instructions for anyone who wants to download your code. And most importantly, write tests!


When you're on the job market, it's important to put your best (virtual) foot forward. By clearly communicating who you are, highlighting a small number of tightly focused projects, sticking to a design that avoids clutter, and trying to impress both technical and non-technical stakeholders, you're more likely to create a strong first impression and make it through the first phase of the hiring process.

What other strategies have you found successful when looking for a job? Let us know!


Written by Matt

Back to all posts

Get Started with Rithm School