10 Programming projects to boost your resume (you can do this weekend)

Written by Eric Normand. Published: September 11, 2016. Updated: February 4, 2019.

Eric Normand's Newsletter

Software design, functional programming, and software engineering practices

Over 5,000 subscribers

Personal programing projects may get you your next job.

But they're not right for everybody.

This guide will tell you everything you need to know about using programming projects in your resume to help you get a job.

How to tell if coding projects will help your resume
How to pinpoint the skill to use in your personal projects?
4 qualities interviewers look for in a personal project
4 characteristics to bake into your programming projects to maximize success
When is the best time to work on personal coding projects?
10 personal programming projects you can start this weekend
Managing your time
How to present your project online and in your resume

How to tell if coding projects will help your resume

Put yourself in your interviewer's shoes. Chance are, you are one of hundreds of applicants for this job. The interviewer is tired. They have limited time and energy to spend on each applicant. They probably won't read your resume before the interview.

What are they worried about? Themselves. Their status. How they look to others.

Specifically, they are worried about hiring an unqualified person and looking like a fool.

Your #1 job in the interview is to appear highly qualified for that job. And to do so quickly and clearly, because the interviewer does not have time to check if you really are qualified. I'm not saying you should lie. What you should do is make the truth clear. Your resume needs to highlight interesting facts from your life that make it obvious you would do well in this job.

So that brings us to the question: should you include programming projects in your resume?

Yes, if they clearly and quickly contribute to the picture that you are qualified for the position.

Examples

Do any of these people fit your situation? See if you can figure out whether personal projects will help each person.

Jill is a new graduate looking for her first job as a programmer. She has some work experience, but it's mostly helping people fix their websites. It's relevant, but she wants to show that she can code more sophisticated applications so she can work in the finance industry. Are personal Computer Science projects a good idea for Jill?

Yes! Jill has little work experience. Personal coding projects will show:

She has the skills
She has the motivation
She can learn new things
She has resolve to finish
She has something interesting to talk about during the interview

The next question for Jill is what skill she would like to develop in the project. Then she'll need to choose a project. We'll talk about that in a later section.

For now, let's move on to Bill.

Bill has been working as a software tester for 5 years. He is familiar with software and wants to make the leap to programming for the better pay and more freedom. Will cool programming projects help him make the switch?

Yes! Bill has more experience than Jill, but it's in a different field. An interviewer might wonder whether Bill really was ready. How much training would he need? Personal projects on his resume can help answer that question.

Bill's next question should be to figure out how to translate the job listing he's targeting into skills he can demonstrate. We'll get to that.

But before we do, let's look and Colleen.

Colleen has been working in software for ten years on a successful product. She's now looking to change companies. She basically wants to continue to work in software. She knows the tech stack of her employer, but she's concerned that any new company will have a different stack. Should she do some programming projects to prove that she can learn new things?

No! As an experienced professional programmer, nothing she could do in her spare time would compare to the magnitude of working on the same software for ten years. She should focus on highlighting aspects of that software that could be interesting to an interviewer at her target company. Think about it: you work on an e-commerce system for ten years. How is a tiny blog engine you wrote one afternoon going to compare to that? It won't seem serious and it won't be worth talking about in the interview.

And what about that new tech stack? Read a book, try to set it up, and mention your opinions on it in the interview. Just to be clear, when I say tech stack, I'm talking about the combination of database, operating system, and other services that make up the software. Because they are combinations, there are millions of them. No two companies have exactly the same setup. Companies expect that it will take some time to learn, so if you don't know everything in the stack, that's okay.

Tech stack is one thing, but what about programming language? Or even programming language paradigm? Let's take a look at John.

John is a JavaScript programmer, but after a few years of professional experience, he's feeling like JavaScript is not for him. He's heard lots of exciting things about Clojure and Elm. They fit the way he thinks. He wants to apply for jobs where they use functional programming. Should John do some side CS projects?

Yes! Since he doesn't have professional experience in functional programming, a couple of coding projects showing he can make the paradigm shift will be helpful. Plus, knowing multiple languages will always put you above someone who only knows one.

I hope these examples made it easy to understand how to think about this. The main question is: will this help my interviewer see that I am the right person for this job? Just answer that question for yourself.

If you've determined that you need some personal projects, how do you go about choosing them? There is one more question you should ask before you start designing the project.

What skill should you use in your personal programming projects?

If you're making a career move, you should plan your personal projects with the career move in mind. So how do you do that? The first step is to read the job listing. The job listing often lists technical skills they are looking for. You probably won't be able to do all of them in your coding projects. Pick ones that can supplement your other experience.

When is the best time to work on personal programming projects?

Let me ask you this: when is the best time to learn to cook a new style of food? When you're hungry? For the important dinner with your boyfriend's parents? No.

The best time to learn to cook is when you're not hungry. When the meal is not that important. A lot can go wrong. But the risk is not the most important part of the equation.

Learning something new takes experimentation. It takes time. And it takes a certain amount of leisure. You can't get that leisure when you're under the pressure of an important deadline like a mealtime or because you really need the functionality.

So to answer the question: you should start your personal projects now. Don't wait until you desperately need a job. Take a good look at your career and start building projects that lead that way, on the side, starting now.

4 qualities of a good personal coding project

Remember, your interview er is looking for something to make you stand out. They want to find someone who is unlikely to embarrass them. Here are the things an interviewer is looking for.

It uses a relevant skill
It is complete
It is interesting
It is realistic

Let's go through these, shall we?

1. Relevance

This one is pretty obvious, so I put it first to get it out of the way.

The project should use skills that you will need on the job. You should highlight those skills. For instance, if the job says "SQL skills are required", mention that you use Postgres in your project. Did you have to do anything interesting? Did you use an obscure feature? Did you hand-roll your SQL? For a good reason? Put that in the resume.

Relevant is a key term. It doesn't have to be exactly the same skills. For instance, if they use Apache and you've used nginx, that's probably okay. They're both web servers. Just make sure you could justify the difference.

2. Complete

Starting lots of projects and never finishing them is a bad sign to interviewers. Why didn't you finish? Did you give up when it got tough? Are you disorganized? Do you lack focus? Those are the thoughts that are going to spring to the interviewer's mind. Don't put projects on your resume that don't have some kind of completeness.

Let me be clear: software is never done. But software does get deployed. Does your Twitter bot tweet? Does your weather app show the weather? Does your blog serve pages to the public internet? You're looking for something that shows that it works, it serves a purpose, and you didn't give up.

I've hired people in the past myself. The #1 problem I've encountered with bad employees is that they give up too soon. Sticking to it is especially important for programmers. There are many, many challenges in the life of a software project. Showing that you can carry on is really important. Plus, it can make for some interesting stories to talk about in your interview.

Your best bet for completing the project is to make it small. It's so important, we'll go over that soon.

3. Interesting

Remember that the interviewer is tired. They've looked at hundreds of resumes very similar to yours. They've talked to candidates just like you. They want something to help energize them and motivate them to talk to you about your projects. That's why you want to make them interesting.

There are a lot of ways your project could be interesting. One is if it gets really popular. "Developed a library used by 100,000 people". That would be a great line on the resume. Unfortunately, that's not likely to happen. Stay realistic.

Another way is for someone to lend credibility. "Rich Hickey and Jose Valím both personally reviewed the code and publicly praised the craftsmanship." That would be awesome! But also unrealistic.

Your best bet is to go with something whimsical. That will require some explanation, which we'll go over soon.

4. Realistic

Your interviewer wants to know that you can solve real world problems. It's all too easy to avoid problems when building a side project. You could avoid writing a GUI by making a terminal app. You can avoid using a database by writing to files. You can avoid making it fast because it's just one user.

Avoiding problems is a useful skill! But so is bravely facing them and overcoming them. Your interviewer might be impressed by your ability to sidestep issues, but they know their customer-facing application needs a GUI. They use a database. And it needs to be fast. Those features, or a list like it, might be non-negotiable. Have you dealt with those kinds of real-world constraints? Show the interviewer you're capable of facing real-world challenges by making your software realistic.

I think an example would help.

Let's say you build an application to catalogue your reptile pet collection. You start easy: it's just a web server you run locally that stores all of its data in-memory. How can you make this more realistic?

Deploy it on the open web
Use a database instead of in-memory storage
Add a user management system
Talk to a 3rd-party API

All of these things force you to face real-world issues. Luckily, these will also coincide with the skills you would like to showcase.

4 characteristics to bake into your personal projects to maximize success

I have a warning: it's easy to overcomplicate these things. Your goal is to present something finished and deployed. If you're trying to learn a new language, or you want to learn some new aspect of it, by all means work on a project. But don't make it something so vital that you can't afford to mess up. You will struggle and maybe wind up hating the language. The best thing to do is something small and whimsical.

1. Small

Grand adventures start with a bold, but tiny, first step. Hello, World! Is a good first program for a reason. There's so much to learn at first. The build tool, the command to run it, input + output, so much! At the beginning, getting all of that settled is hard enough without dealing with bugs in your program.

Of course, you'll want something slightly bigger than Hello, World! on the command line. But think for a moment: what's the equivalent of Hello, World! for web apps? What's the equivalent for Twitter Bots? That's what you should build first. Deploying something small is much better than never deploying anything. You can always add to it later if you need to.

2. Whimsical

The most impressive early works of artists come out of a very free exploration of a medium. Sure, masters can make even ugly colors look beautiful. But let's face it. At the beginning, we're all bad at that. The reason Hello, World! Is so great is that it captures that frivolous spirit of the artist. What could be more unnecessary than a program that says "Hello"?

The whimsy is what lets you produce something, anything, even if it's worthless. Deploying something that works is better than a failed grand vision that doesn't do anything. Whimsy is what lets you change course when you realize your idea won't work. What's something silly that could work? Whimsy avoids boredom and dead ends. It dodges perfectionism and welcomes serendipity. And after the fact, nobody knows what you had planned to do before you started.

3. Familiar +1

Chances are, you're probably aspiring for a job just outside your skillset. You can use your projects to try out the new stuff you'll need for the job. If you still like it, you'll also have proof that you can work with the tech. However, what you don't want is to bite off more than you can chew. Seriously, build something you know how to build, with one extra thing you've never used.

What do I mean? If you are familiar with traditional web apps, build a web app, but in a new language. The familiar is the web app, the +1 is the new language. Or build a web app in a language you know, but with a new database. You don't want the project to fail because you hit too many roadblocks. Remember, you can always add more stuff later. Which brings me to ...

4. Expandable

The best place to be is to have a stable, working, deployed project that you can add features to whenever you want to learn a new skill. Maybe you've got a small blog engine that you can add user login to. Or a Re-frame frontend. Or a spellchecker. Or AI categorization. Each of those features is digestible on the weekend. But if you tried to do them all at once, you'd probably never finish. Build your project in pieces. But first, your main goal is to get something small and basic working and deployed.

10 personal programming projects you can start this weekend

Okay! With that out of the way, here are ten projects you can keep small and probably do over a weekend. But each can then be a platform for adding to later, if needed. I've also included the skills that each project demonstrates and some possibilities for expansion. Keep in mind that you have a choice for the platform these run on. For instance, your weather app could be a mobile app or a web app.

1. Blog

This is a classic exercise from the early days of the we b. Serve pages out of a database based on the URL.

Skills: Database, HTTP server, HTML
Expansion: User login, frontend editing, build an API, search, link analysis

2. Twitter Bot

Build a program that submits new status messages to Twitter.

Skills: API access (including OAuth), error handling
Expansion: Generate Markov statuses, use a database of pre-written tweets, timing, respond to other users' messages

3. Weather App

Use the Forecast.io api to display the weather near you.

Skills: API access
Expansion: User can interact with weather over time, notify you of bad weather

4. GitHub Notifier

Listen for events from GitHub and notify you.

Skills: HTTP server (for post hooks)
Expansion: Rules engine for deciding when to notify you, GUI, database for history

5. TODO App

The classic app keeps track of a list of items and their status.

Skills: UI work
Expansion: Backend (api design), database, social sharing, real-time collaboration

6. Twilio Bot

Twilio is an API for text messages and phone calls. Make a bot you can call that will tell a joke.

Skills: API access
Expansion: Connect it to TODO list, Connect to GitHub Notifier, Connect to Weather App

7. Meme generator

Basically, put text onto an image!

Skills: Graphics, file IO
Expansion: Preview, submission to social networks, GUI

8. RSS aggregator

Poll RSS feeds for new articles and make a new feed that combines them.

Skills: XML, database
Expansion: Frontend (add new feeds, list of article titles), filtering, saving for later, share buttons

9. Food log

Keep track of everything you eat with a simple submission form.

Skills: Database
Expansion: Show trends, search, filter by date, database of known foods, calorie counting

10. Google Map

Make a website that shows places on a Google Map.

Skills: JavaScript interop
Expansion: UI to add/remove places, database for saving places

These are just some projects doable in a weekend. Remember to keep them small and whimsical. If you're serious about your functional career, you're going to do better with some support. Sign up for PurelyFunctional.tv and you'll get step-by-step lessons teaching you the skills you need to build real projects to prove you can ship with Functional Programming.

Managing your time

Many people give up on side projects because of lack of time. The reason? They don't manage their time well. Here are some things to maximize your success.

Carve out one 3-hour block on the weekend. Ask your significant other for uninterrupted time. Make sure the kids can't distract you. Leave the house if you have to. The goal is to feel like you've got the mental space to focus 100% on it and achieve success in those 3 hours.

**Plan out a small, achievable goal for those 3 hours. **During the week, make notes about what you plan to achieve. It needs to be small. You want those three hours to result in something tangible, however insignificant it may seem.

For example, your goal may be to start with the Luminus template and deploy it to the web unmodified using a build pipeline. That may seem insignificant, but many issues can pop up. I've gotten stuck with lost passwords to Heroku, a spotty internet connection, and a typo in a config file. You can waste an hour just on those things. You want the margin of error so you are guaranteed to succeed.

Plan out some small extras you can add if you have time. If you don't finish these, it's okay. It's still a success. But you want to be able to play with your project once you've achieved your objective.

Use the time during the week to guarantee success. It may seem like you don't have time, but you probably do have a few minutes here and there. I'm not saying act frantically and non-stop. We need rest and breaks. What I am saying is if y ou're thinking about your weekend project, you should be focusing on success. Don't dream up all the features you could possibly have. I've done that and it only stresses me out that I'll never finish. Instead, use your time to make your project easier and smaller.

Can you eliminate a risky piece of the puzzle? Do it. Can you double check your Heroku credentials ahead of time? Do you have the tools you need installed? Those things will keep the project front of mind and maximize those three hours you've got blocked off.

Remember: the goal is to have a basic platform for adding features to. You'd be surprised how much you can add to a basic, working product. Once you've got the basic platform working and solid, adding a new feature can be as simple as pulling out your laptop and experimenting. If it works, commit it. Otherwise, oh well! The hardest part is getting all the tools set up.

How to present your project online and in your resume

Okay, once you've got something to show, you've got to present it to the world. I like to host my code on GitHub.

GitHub README

And one great thing about GitHub is that it shows the README file front-and-center when you load the repo. That means you can leverage the README to showcase what makes your project special.

Here's the minimum the README should contain:

What does the project do?
Who is the project for?
Why is it different?
How do I use it? (installation instructions)
How does it work?

Code quality

If you expect someone to read your code, make sure that it's well-formatted and readable. Spend some time renaming functions and consider the reader. What will help them navigate? Where should they start?

In the resume

If you're putting it in your resume, make a new section for Personal Projects. List them similar to how you list your jobs and education. You want one sentence for what it does, a line of technologies that are relevant to the job, and one interesting tidbit. I also like to include a "what I learned" se ntence that lets me highlight me as someone who learns from experience.

For example, here's what I would write for my blog engine I wrote about 7 years ago:

Tiberius - Personal static blog engine Python, Pandoc, Markdown, S3 - 100-line Python script to publish a blog - an exercise in the power of simplicity Taught me to appreciate constraints. Robustness comes from eliminating the unnecessary.

The Personal Projects section needs to go in your resume where it makes the most sense. The most important section should be at the top. If you want to highlight your professional experience, put that at the top. If you want to show your academic achievements, that goes first. But if you think academic and professional are less relevant than your personal projects, move the personal projects to the top.

10 Programming projects to boost your resume

Table of contents

More posts in the Career Guide