Write a Resume that Doesn’t Suck

For developers today they have a lot of things to consider when applying for their first few jobs. Do they build a great portfolio? Do they invest in curating a great GitHub profile? Do they update their resume? Should they craft an ideal cover letter?

The bottom line is that in almost every scenario, a developer will have to send in a resume for a job. If they have a great Github profile they’ll have to send a resume along. A resume will have to be sent even if a friend within the company is making a recommendation. Got a gorgeous portfolio? That’s great, send along your resume to start the process!

Writing a great resume is foundational to the job search process. It is a currency that is passed along that can exclude you from opportunities and distinguish you from the pile of other resumes.

My Story

I completed my B.S. in Computer Science and then moved to Japan for a year. When I came back I began my job search in software development. Nobody would hire me.

I had the resume that I wrote in some class in college. My resume was some terrible thing that I slapped together to complete an assignment. I set to work on making my resume less repulsive.

A few months later, almost every time I sent a resume I received a request for an interview. This was with no software experience.

Know your audience

People will read a resume for up to 90 seconds. Often they will look less than that. Think of the challenge this way: You have 90 seconds to convince them to interview you instead of someone else.

You have to convince someone in HR and a development manager.

You have 90 seconds to convince them to spend time finding out if you’re worth it.

As you read my advice, think about what these people may want to see in a resume. How easy can you make it for them to say, “Yes,” to you?

Skills

The basic structure I’ve used for years begins with a section highlighting my skills.

I start here because the first person to read my resume will often be someone in HR. They don’t understand software development. They have a job listing that was written by someone else that they are trying to match against. They will do this at a very shallow level. That means they will look for keywords that match.

If a job posting lists Java, it sits first in my list of skills.

When someone in HR reads my resume they’ll match most of the keywords and that will put me in the pile to be passed along to the next person.

When you write your resume, put the keywords that you have front and center in your skills section.

Maybe as a note about when you can and cannot put those skills on your resume. There is no magic person who gives you permission to put things on your resume. Put whatever you want. If you lie, you’ll get caught.

If you lie and get caught, it will follow you around. You’ll find out in your career in development that there are only so many of us, and we will easily remember that one kid who lied about some skill. When we see them again that’s the first thing that will come to our minds. Will I consider spending time on them again after they lied the first time?

I’m not saying you have to be an expert in everything you list, but you do need to talk through and demonstrate some ability in those skills.

Experience

The second section and the meat of the resume is my experience. Starting off this can be pretty thin or really hard to conjure up.

For each job or piece of experience that you list, include these elements: Company name, years worked, and the value you created.

Note I didn’t say to include your title. I also didn’t say to list what you did at your job.

Many people fall into the trap of listing their job duties in their experience. Guess what the job duty of a software developer is? Building software. Skip that. Skip the part where you did architecture. Skip the parts where you documented, designed, tested, refactored. That is literally what everyone has on their resume. It also tells me nothing other than you showed up to work and did the minimum of your duties.

What you write about instead is the impact you had, the outcomes you delivered, or the value you brought. This takes some practice to come up with. Here’s a contrived example:

From: “Built a web application using react, node, and Postgres.” To: “Built an application that led to 1.2 million in revenue.”

Wanna guess who will get called in based on those two statements? It won’t be the person who listed react.

Feel free to highlight certain things that you want to pull the development manager’s attention. Weave your skills into these things, but stay focused on the outcomes. Listing a skill in these bullet points is something you do to blow their mind. If you know they are using specific technology and called out scale, for example, then that is a perfect opportunity to describe a scaling problem you solved with that technology.

Otherwise, stay value focused.

You may have noticed I put a number in that example. Numbers hook people’s attention. They will want to know the story behind it in the interview. This is great for two reasons. First, you have their attention which improves your chances of interviewing. Second, you’re increasing the chances that you know what they may ask you in the interview. You can practice your story behind it in anticipation of the question.

As for why I recommend not listing titles. You’ll likely get asked to add them in by recruiters. I recommend not listing them unless asked because not all titles mean the same things to the same companies. If my company doesn’t have the title Junior Developer, but that’s what your title was, I now have to reconcile that concept. Who will this Junior person be here? Are they not ready?

As for how many bullets to add per block of experience I’d say to focus on 3 to 5 per company.

Non-Development Experience

What about that experience that isn’t software development related? Well, those other jobs taught you valuable things that you’ll bring with you for the rest of your life. Your ability to deliver value wherever you go is worth bringing forward. Look at those earlier non-development jobs as opportunities to highlighting all the other non-development things you bring to the job.

Do you have a job that you can use to highlight working on a high-performing team? Great! Do you have a job where you can talk about accomplishing an ambitious goal or project? Great! Got a job where you can highlight skills in communication, facilitation, teaching, mentoring, design, marketing, advertising, finance, etc? Great! Put that down. Show them you are unique and bring more to the table than writing code.

Summary

By focusing your resume on your audience and maximizing the impact you have in 90 seconds you can distinguish yourself in a way that lands the interview more often than not.

Make your skills easy to find for HR so they can pass you along. Include skills that you can speak to or demonstrate.

For your experience list the company and dates. Put 3-5 bullets that show the value and outcome you delivered. Forget putting down your duties and tasks.

Don’t be afraid to list non-development experience. It’s an opportunity to show all of the other skills you bring on top of your development ability. Stay value and outcome focused.

I used every technique I mentioned to build my resume. Even when I had no, “Experience,” these techniques helped me consistently get interviews and get jobs.

If you want help getting your resume together, let me know!