What to look for in a developer’s resume

So, the time has come to hire new developers, and excitement grows high. But, it’s not as high as the stacks of resumes that you have in front of you, each with its carefully crafted sentences that sometimes feel like they’re just about to overwhelm you.

That pile can get as big as hundreds, or thousands of pages that can squeeze the fun out of the hiring process faster than you'd imagine.

If you’re looking to hire tech experts for multiple programming languages or frameworks (JavaScript, TypeScript, Angular, Node.js, Python, PHP, you name it!), then you should carefully consider your options and devise a foolproof hiring plan.

The plan should be simple, but effective: are you looking for web developers, mobile developers, cloud-native development talent, or a little bit of everything at once? All of these variables can add an additional layer of complexity that recruiters and hiring managers will need to work through in order to make a quality hire.

But it doesn’t have to be that hard.

Let’s examine the ins and outs of this entire process and see how you can work the numbers to your advantage.

Follow the career path

Besides the programming skills and stack proficiency, the first thing to look for in a developer’s resume is a steady, consistent, and (hopefully) upward career trajectory. Good developers will be able to showcase a compelling career path that encompasses multiple job wins (promotions, rewards) over an extended period of time.

Additionally, some would argue to pay close attention to gaps in the resume template, and this is true—most of the time. However, I would also add that quality trumps quantity. Therefore, I’d urge you to be upfront with the candidate about the gaps in their work experience and have an honest conversation with them to clear out any potential misunderstandings.

Apart from that, you’d also want to see a steady improvement in the career trajectory over time (a sudden upward trend is great, but less likely). For example, a candidate should be moving from junior to senior developer positions, and hopefully not the other way around.

Be careful not to dismiss the developer entirely if you notice a backward career trend. Instead, talk with them openly and address the issues as they come up in the resume format.

Look for little personalization tidbits

Another, but an equally important thing to look for in resumes, is what I like to call personalization tidbits.

To better understand this, put yourself in the shoes of prospective applicants. If they’re doing nothing more than just dumping unproofed, cookie-cutter sentences into a generic resume template, would you be really looking forward to working with them on real-world problems?

Personalization doesn’t concern only the resume format, but it’s also a very important tell about the candidate’s behavior outside the working place as well. In other words: hobbies and personal projects are a direct reflection of the developer’s ability to think outside the box and successfully complete the summary or objective of any upcoming work engagement.

In fact, developers with plenty of personal projects to show for most likely means they are ready to take the initiative and go above and beyond the usual box-ticking paradigm. Box-tickers, in my workplace vocabulary, refers to people who just do what they’re told and nothing more.

Look for passionate applicants

In lieu of some of my previous thoughts, I think it’s not incorrect to assume that passion trumps, well, pretty much everything else.

Think about it this way: passionate people will always go the distance, even in times of intellectual recess or when the reward doesn’t justify the effort. This isn’t to say that you should take advantage of your most loyal and passionate personnel, but rather it’s a staple of their dedication and willingness to fully commit regardless of external circumstances, pun intended.

And how would you recognize passion in a resume? Look for languages, hobbies, the overall tone of the resume, and unpaid projects like internships or charity/volunteer work.

If the candidate happens to maintain a GitHub repository, that’s a telltale sign of a dedicated tech expert that is 100% fit for the role.

Use keywords

Before you delve into the pile of never-ending tech resumes, create a list of keywords for the specific developer role that you’re hiring for.

If you’re working with digital resumes, you can save a ton of time by creating an automated applicant tracking system that would only accept those resumes that contain a certain percentage of your previously-assigned keywords (it’s extra effort, but worth the time).

Also, don’t forget to consider all variations of a given keyword, including its synonyms or spelling variations.

Prioritize content over how the resume looks

It’s excellent if the developer sends over a resume with gorgeous fonts (comic sans excluded), a professional layout, or even a novel CV with skill bars and other bells and whistles.

However, if aesthetics overshadow the content, consider that a red flag. Sometimes, when applying for a job they desperately want, people will “blow up” the visual part of their resumes to hide the notion that they just don’t have the years of experience or expertise to back them up.

The ideal software engineer resume should strike a delicate balance between aesthetics and content, and no amount of shiny glitter will be enough to hide that fact.

Avoid resumes with typos

This should be accepted as HR gospel. Pay attention to resumes with typos, uneven bullet points, crooked job descriptions, the placement of more than two fonts, and anything that causes a redundant visual cacophony or looks unprofessional, to say the least.

The logic behind this lies not so much in avoiding pain from visual overstimulation (although, that’s also a thing), but to prevent mistakes before they even happen. If the prospective developer (backend, frontend, fullstack) leaves typos in their resumes, they’ll probably also leave them in the code as well.

Look for a unique file name

This might seem more like an annoyance than a real issue, but it makes perfect sense if you think about it for a minute. If everyone sends over a resume with a generic filename (such as resume.pdf), then you will have a hard time differentiating between the applicant and the dev position they’re applying for.

Experienced developers with great attention to detail will uniquely name their resume files to stand out from the crowd. Some examples of good resume naming conventions include name_language_profession (john_typescript_dev.pdf) or name_company (sam_proxify.pdf).

Following these guidelines indicates that the prospective developers are attentive, hard-working, and have a knack for looking ahead when problem-solving.

Even better: if you can build an automated system to sort out the resumes in your absence according to these parameters, give us a call to discuss a lucrative partnership opportunity.

Carefully consider the structure

A good resume should give off the impression of carefully assembled and presented expertise information. In other words, it should be organized very well, easy to read and grasp.

If you get CVs that look quite messy, then the former should soon find themselves set aside and not looked at again.

If you’re lucky, sometimes you will discover resumes that tell a specific story from beginning to end. Generally speaking, storytelling can be considered a management skill due to having to track multiple moving parts across a large pile of data.

Good storytellers are hard to come by, so, developers who present themselves as creative and open-minded could also end up filling leadership roles in a variety of tech companies that operate across multiple disciplines and fields.

Conclusion

When you’re dealing with mountains of digital or physical data, you need to develop a sorting system to help you push through the noise and find the right developer for you— – sooner rather than later.

Hopefully, some of the indicators listed here will help you to improve your hiring process and make it more efficient (and less time-consuming) in the long run.