Hot take 🔥: The projects section of your resume is the likeliest to be skipped over by both the recruiter and interviewers. This is especially true if you have decent size education and work sections above. In some cases, it make sense to remove your projects section altogether.
Before tweaking your resume, it is important to remember the purpose of your resume and also the purpose of the projects section. Let’s discuss that first.
Prefer to watch a video instead?
The purpose of your resume
As I talked about in this video (will open YouTube in a new tab) is two fold:
- Paint a succinct picture of you so that a recruiter can quickly determine if you’re a good match.
- Guide the conversation with your interviewers.
If the recruiter can not quickly tell that you’re a good match, then you will be skipped over. The goal is not to have a ___ (insert whatever) resume. The goal is to get a call back. Every section and every word on your resume needs to be intentional.
The purpose of the projects section on your resume
Every section of your resume is there to fulfil the overarching purpose of your resume ☝. The purpose of the projects sections is no different: paint a succinct picture of you and guide the conversation. This means the projects you list need to be challenging and highlight a strength or a skill relevant to the position you’re applying for. Better yet, turn your project into a business. More on that later.
Okay Roman, what if I got enough other experience on my resume already or my existing projects do not meet criteria described above? Then consider removing the projects section 👇.
Ditch the projects section
If your work experience speaks for itself and the role you are applying for is a clear match — I would remove the projects section from your resume. This section is not mandatory. If you can’t make it work in your favor, get rid of it. Extra fluff on your resume is not going to do you any favors. At best it will be ignored and at worst it will annoy whoever is reading it.
Projects that go in this sections
- Personal projects.
- Unpaid software projects done for others.
- School projects that are complex, relevant, and unique. Be careful with this one though (see section below 👇).
Projects not to list
- Anything from “tutorial hell”.
- School assignments that everyone in your class completed. These are not unique or challenging enough.
- Team projects where you didn’t do much. Don’t do it.
Choosing a project
When choosing a project, I recommend working backwards from the market needs. Pick your top 3 job listings and take notes. What kind of technology do they use? Now pick a stack 📚. This will vary wildly depending on your subfield of software engineering. Someone applying to Stripe, Visa, and PayPal as a front end SWE will obviously have very different projects to choose from than someone applying to Tesla, John Deere, and Ford as an embedded SWE.
With that in mind, there are some general skills that will be appreciated by most companies. For example:
- Use git.
- Host your source code on GitHub because many companies already use GitHub.
- Learn the basics of CI/CD.
If you need inspiration, check out my archive of random ideas 😁.
Make it look good
The presentation matters. It’s always a good idea to make your project easy to understand and review. Both technical and non technical people will appreciate an easy to understand project. This is not to be confused with a simple project. In theory, a perfect project will be very difficult to do but very easy to understand at a high level and be relevant to the job you’re applying for.
This is difficult to achieve for some projects so consider how you’re going to present it while evaluating potential project ideas. For example, a full stack website that’s ready to use is going to be easier to present than a niche database tool that requires you to spin up a Docker image.
I don’t want to discourage you from building something that you’re passionate about. This is not the point. What I am trying to say is that no one is going to spend hours digging through your GitHub repository trying to understand what is going on. You will have to come up with a way to showcase your project quickly. Write an excellent readme, record a demo video, make gifs, and take screenshots.
TL;DR: someone in the embedded software space does not need to build a fancy front end in React for their RTOS watchdog driver. Just do you best to showcase your project. A simple static webpage containing all the details is a great way to do this.
Projects in production are more impressive
Maintaining projects in production is hard. Once you have active users, making changes is not as easy and real world bugs will inevitably bubble to the top. This is what you will be working on in the real world (in most cases) which is why showcasing production projects on your resume is gold. There is so much experience to be gained from running in production.
I would go as far as saying that sacrificing complexity in order to get your project up and running in real world is a worthwhile trade off. When it comes to gaining real world experience, a small project that’s used by 1 person is light years ahead of a project that’s used by 0 people.
Projects are not about the code
Projects are not just about your ability to code. Software engineers do a lot more than writing code. We write documentation, record presentations, organize projects, plan upcoming features, prioritize bugs, debug unfamiliar code, participate in code reviews, train junior team members, communicate complex ideas to both technical & non-technical people, conduct interviews, and so much more. The more experience you have, the less code you will actually write.
The projects section of your resume is an excellent place to showcase that you can do more than simply committing undocumented code while also adding a touch of your personality and creativity to the mix.
Idea 💡
Have you seen people list their hobbies on a resume? 🏂 Build a project related to your hobby instead. This way if your interviewer does not share the same hobbies and interests, they can still appreciate what you’ve done from a technical perspective.
Style and size matters
Your project section should be below education and work experience sections. It should look very similar to your work experience section. The consistency is very important since it makes it easier on the reader. I recommend something like this:
| Descriptive Project Name | Project Dates |
| * Bullet point 1 | |
| * Bullet point 2 |
Start with a descriptive project name and dates. Yes, dates are important as they tell a story on their own:
- How long did the project take?
- Is the applicant still working on this project?
- Is the project stale or recent?
Note: I would avoid listing old (stale) projects because it may be more trouble than it’s worth for you. You need to be prepared to talk about your project at length and in depth. If you plan to list an old project, you might as well revisit that project, refamiliarize yourself with it, and even make some fresh updates. Flip the perspective: would you hire someone who can’t answer questions about their own project which they have willingly and intentionally listed on their resume? 🤔
Keyword opportunity
This section is an excellent place to pack with relevant keywords for the Applicant Tracking System (ATS) and fill the gaps in your experience. It can make or break your resume if you’re switching subfields (for example: going from webdev to embedded). Good news is that packing this section with keywords should be natural if you followed my advice on picking your project based on the market needs above 😉.
TL;DR
The projects section is an excellent way to showcase your creativity and unique interests. It is not a mandatory section so do not feel obligated to include it on your resume. It should be the last section on your resume. Choose your projects wisely 🧙♂️.
