Even in a field like web development where you have loads of opportunities (see Why Web Development Is a Great Career), competition for permanent positions is still fierce. Companies filter through tons of résumés for each opening. Most applicants get filtered out before they get a single interview. The only thing you want from your résumé is to get you through that initial filter so you can start getting interviews. Keep reading, and I’ll teach you how to write a résumé that gets through the filter and takes you one step closer to gainful employment.
After I decided to leave my last full-time gig, I thought I wanted to go directly into another one. Well, I thought that for a day, at least. 😜 On that day, I sent out one résumé, and I ended up doing four rounds of interviews with the company. I didn’t get the job, but the résumé certainly did its job by getting me into the building. Here’s the résumé I submitted:
I show this not as an example of the perfect résumé — it definitely isn’t — but as an example of one that worked. Let’s go through and examine the aspects of this particular resume that succeeded and those that could be improved.
My example résumé is a single page and glanceable. You can quickly see what tech I know, where I’ve worked, and what projects I’ve worked on. If you think from the perspective of the company who is trying to filter through 100-200 of these, this is exactly what you’d want to see.
I could have written several paragraphs of flowery prose about my career objectives, but that wouldn’t have made this any better. My goal is to communicate why I would be valuable without wasting people’s time.
I’ve been working since I was about 15 years old. I could have tried to catalog everything I’ve ever done in the “Experience” section. Instead, I included only what was relevant for the position I was applying for. They don’t care that I served time as a Walmart cashier or that I was paid to produce IDs for students at my high school.
One thing I might have done better is to break out individual projects I’ve done through RadWorks. As it’s written, my freelancing practice is a sort of black box where I did “front-end development,” whatever that means. I wish I had used the bullet points to point out specific projects that would have been interesting to them.
Let’s unpack that a little. Do you mean that you have no experience whatsoever that is relevant to the job you’re applying for, or do you mean that you don’t have professional experience (meaning you haven’t been paid for this kind of work)?
If your problem is that you don’t have professional experience, that’s fine. Instead of listing irrelevant work experience, list projects you’ve completed that are relevant. Provide links to code and working deployments of the projects if that’s practical.
If your problem is, in fact, that you have zero experience that’s relevant for this job, you probably need to fix that instead of applying. You can apply for this job anyway, but you’re unlikely to get it. Instead, go build a project or two that gets you some experience in the area of interest and list those on your next application for a similar opening. (You might be interested in reading about the best types of projects for learning and even getting some inspiration from my list of 10 sometimes wacky project ideas.)
It’s easy to get cynical and start poking fun at the fact that entry-level positions require 5 years of experience, but that won’t help you get hired. Think about this from the company’s perspective. They have a problem they need to solve or else they wouldn’t be hiring. You’re asking them to hire you even though you have no experience solving the problem they need solved. Meanwhile, they have a stack of résumés, many demonstrating the skills they need. Why would they even give you a second look?
You can mitigate some of this by starting your career with freelancing. The barriers to entry are lower, and you can do some learning on the job. It’s no silver bullet; you’re not going to quit your job driving a forklift today and set up shop freelancing tomorrow hoping to learn everything as you go. (If you want to give it a shot, though, take my free Freelancing Crash Course to get your business off the ground.)
Most developers focus on technology. The résumé is a contest to see who can list out the most languages and frameworks. That’s not going to do you any favors.
Your résumé should let people know that you’re proficient in the technologies they need (if, in fact, you are), but it shouldn’t list single technology you’ve ever touched unless that list is both short and relevant. My résumé does a good job of keeping it lean.
Instead, you should focus on what results you’ve created for you previous employers and clients. This is the weakest aspect of my résumé. It doesn’t really talk about results at all. A giant list of frameworks is meaningless. Does that mean you’re a master of all of those? Does it mean you’ve at least gone through a tutorial for each one? Maybe it just means you’ve heard of them all.
Results speak for themselves. If you built a new backend that allowed you to cut infrastructure costs in half or if you built a UI that reduced churn (customers canceling a service) by a quarter, those are powerful. They’re powerful because they equal more money for businesses you work with. Presenting them in your résumé is powerful because it shows you understand the value of the work you do.
You have to walk a fine line with this one. If you start telling about your weekly pick-up basketball game or listing your pet names, most people are going to get annoyed. Talk about interests or projects that aren’t strictly related to the stated job requirements but provide a fringe benefit to your prospective employer can help you stand out though.
In this résumé, I’ve done this with my side projects. I mentioned Rad Devon because I’d like them to know I enjoy mentoring new developers. I talked about my writing experience because I want them to know I’m good at communicating. I also drop the fact that I think a lot about writing readable, maintainable code, which is very important when you’re working on a team.
Most résumés are written for the writer. We compile a massive list of every job we’ve ever had and another of every skill we’ve ever encountered. We look at the 6-page document with a feeling of pride. Look at all we’ve accomplished and all we’ve created.
This makes the writer feel good, but it doesn’t accomplish the goal of getting the job. These are the résumés that go directly into the garbage. The résumé written for the reader is the résumé that gets you the interview. Some quick advice:
- Cut out anything that’s not relevant.
- Instead of writing the 6-pager, re-read the job posting. Most of them tell you exactly what they want from you.
- Make sure you tell them that you have those skills they want.
- If you can, share a result you generated with those skills.
- Share something about yourself that could be valuable in this position.
Writing for the reader is the advice that underlies all the other advice. If you can orient yourself around the goal of finding how you’re valuable to the company instead of the goal of getting the job, the job will follow.