Most of the time, senior developers in the team conduct the interview. In part, this is because HR doesn’t really know what they’re supposed to be looking for. You can brief them as much as you want but there are some nuances to a candidate that only someone who actually understands and knows the trade can actually make a proper judgment on.
As a senior dev, I’ve often been in situations where I play the role of HR and shift through all resumes that come through.
Most of them go into the rejected pile.
The general resume writing advice 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 first got the task of looking at resumes. It was fun at first — until you realise that you’ve just spent 30 minutes looking at two applications, there’s still at least a few other dozen to look at and my actual day job as a developer.
After that realisation, I became ruthless out of necessity and time constraints.
Every day, I’d dedicate a maximum of 1 hour per day for an entire week to create a shortlist of possible candidates. After the second day, I started to notice a trend. If an applicant fell into any one of these categories, they immediately went into the rejected pile.
Mass application - a lot of candidates didn’t read the actual job application and was applying to every position available
Unjustified wall of acronyms - surely, one of these will be applicable to the job, right?
Bar/pie graphs - 85% proficient in JavaScript, apparently, but measured against what standard?
Font too small / too hard to read - if I can’t read it, I can’t read it. It’s not ok to send through something in 5pt font just because you feel compelled to fit everything on 2 pages.
What made it past the death pile?
There were a few gems that made it past the inbox stage and beyond the reject button. The main common trait is that they all looked like they were written by humans and not bots.
A generic resume will receive a generic response, and often times that generic response comes in the form of a copy-paste rejection email or nothing at all.
So how do you look different from all the rest? How do you capture the time sparse attention of the person looking at your application?
The easiest way is to write how you’d speak.
Ignore what you’ve read about cover letters and how to write resumes. It’ll side-track you and make you think that you have to follow the format you’re looking at. Not only that, it’ll help you melt into the pile of sameness that you want to avoid.
Here’s what to do instead.
How to actually write your resume
Start by creating a master document and list out 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 put down your entire professional life into digital ink. If you’re new to the industry and don’t have a backlog of projects, you can use whatever side projects you’ve done. If you’re struggling to write anything down then it means you haven’t really done much at all at your previous job and you need to strategise a game plan to quickly create some prototype apps.
The second step to this is to shortlist the jobs you like. Don’t mass apply.
Look at each job carefully, ask yourself these questions and answer them honestly:
Do I want to work here?
Why do I want to work here?
What are my current relevant experiences? does it fit with the required brief
What are the gaps in my experiences and what can I do about it?
The first three answers can be turned into your cover letter. The final question can be part of your ‘professional development’ section.
Many applicants feel compelled to put in a hobbies section simply because the generic templates suggest that you should. But you’ve only got a maximum of two pages (sometimes three) so use your real estate wisely. That’s why it’s better to have a professional development section where you can showcase your willingness to learn and improve on a knowledge gap.
For your actual resume, copy and paste the most relevant points from your master document and edit it to tighten up your professional life story. The reader on the other side doesn’t have to know everything about you — just the things that make sense to them.
Final thoughts
Having 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 searching to start this document — but it comes in rather handy when you are actively looking.
The job description is not a trap test where you have to cover every possible technology in order to be the chosen one. Sometimes it feels like it because employers list a host of different tech. But not everything is required. We understand if you’re skilled in one area but not the other. We’re developers too. We know what it’s like. We’re humans, not bots.
What we’re looking for is relevance. So give relevant information about yourself, not a wall of text that’s punching at everything.
