What experienced developers do and don’t want to see on your resume

This article was originally published on .cult by Aphinya Dechalert. .cult is a Berlin community platform for developers. We write about all things career, make original documentaries, and share tons of other untold developer stories from around the world.

In most cases, experienced developers in the team conduct the interview. This is partly because HR doesn’t really know what to look for. You can brief them as much as you like, but there are some nuances in a candidate that only someone who really understands and knows the craft can really gauge.

As a senior developer, I’ve often been in situations where I take on the HR role and go through all the applications that come in.

Most of them go to the scrap pile.

The general advice when writing a resume is that you have 10 seconds to impress the person on the other side. This advice is certainly not wrong.

Why 10 seconds?

I remember when I was first given the task of looking at resumes. It was fun at first – until you realize you’ve just spent 30 minutes looking at two apps, there are at least a few other dozen to look at, and my actual job as a developer.

After realizing this, I became ruthless out of necessity and time pressure.

Every day I would spend a maximum of one hour a day for a whole week short-listing possible candidates. After the second day I noticed a trend. If an applicant falls into one of these categories, it goes immediately into the rejection pile.

  • mass application – Many candidates did not read the actual application and applied for every available position
  • Unjustified wall of acronyms– surely one of these will be applicable to the job, right?
  • Bar/Pie Charts– Apparently 85% JavaScript capable, but measured by what standard?
  • Font too small / difficult to read– if I can’t read it, I can’t read it. It’s not okay to send something in 5pt font just because you feel the need to fit everything on two pages.

What made it over the death pile?

There were a few gems that made it past the inbox stage and the decline button. The main common feature is that they all looked like they were written by humans and not bots.

A generic resume will get a generic response, and often that generic response comes in the form of a copy-pasted rejection email or nothing at all.

So how do you look different than everyone else? How do you get the time-saving attention of the person looking at your application?

The easiest way is to write like you would speak.

Ignore what you’ve read about cover letters and resume writing. It will distract you and make you think you have to follow the format you are looking at. Not only that, it will help you blend in with the bunch of uniformities you’re trying to avoid.

Here’s what to do instead.

This is how you actually write your resume

First, create a main document and list all the projects you’ve worked on. Document your role, your participation, the technology you used, and what you actually did.

Don’t worry about the length or number of pages. The goal is to capture your entire professional life in digital ink. If you’re new to the industry and don’t have a backlog of projects, you can use any side projects you’ve done. If you’re struggling to write something down, it means you haven’t really done much in your previous job and need to develop a roadmap to quickly build some prototype apps.

The second step to this is to shortlist the jobs that you like. No mass application.

Look closely at each job. Ask yourself these questions and answer them honestly:

  • Do I want to work here?
  • Why do I want to work here?
  • What is my current relevant experience? Does it fit the required briefing?
  • What gaps in experience do I have and what can I do about it?

You can include the first three answers in your cover letter. The last question can be part of your professional development section.

Many applicants feel compelled to enter a hobby section just because the generic templates suggest so. But you only have two pages at most (sometimes three), so use your real estate wisely. For this reason, it is better to have a professional development area where you can demonstrate your willingness to learn and fill in the gaps in your knowledge.

For your actual resume, copy the most relevant points from your master document and edit it to streamline your professional life story. The reader, on the other hand, doesn’t need to know everything about you—just the things that make sense to them.

Final Thoughts

A master document can help you keep track of what you’ve done in the past. The more detailed the better. You don’t have to be job hunting to start this document—but it’s pretty handy if you’re actively looking.

The job description is not a trap test where you have to cover every possible technology to be the chosen one. Sometimes it feels like this because employers are listing a variety of different technologies. But not everything is required. We understand if you are competent in one area but not in the other. We are developers too. We know how it is. We are humans, not bots.

What we are looking for is relevance. So provide relevant information about yourself, not a wall of text that lashes out at everything.

Leave a Reply

Your email address will not be published.