Everything wrong with using resumes for hiring software developers
Why am I writing about this?
I am fed up of the current recruiting system. From writing my own resume to reading others’ resume, I feel each bit of this process is a waste of time. There are umpteen number of short-comings in having resume as one of the most crucial parts of the recruitment process, and I am sure most of you would agree with the points that I would be discussing below, and yet the system is unchanged.
I would like to change this and am on a mission to achieve this. I currently am hiring for my tech team in my own start-up and although it’s an habit for the candidates to present the resumes, I am not considering them and instead looking for something else, which I would be summarizing at the end of this article. Before going there, I would be talking about some of the factors that have led me to disbelieve in this process.
Ever lied for scoring an interview?
The first and foremost problem with having just a document for enlisting all the achievements and their impacts, is that most of it is not verifiable. Even if something is verifiable, it is either not straight-forward, or consumes a lot of time, or involves more people whose testimonies are again unverifiable.
As a result, most people lie on their resume to add content that the employer is looking for (stats say that 78% people lie on their resume).
I am sure everyone gets extremely irritated while interviewing an individual whose resume stood out to them, but later finding out that it was all a bluff to land the interview. One would think if people end up getting rejected by lying on their resume, what’s the incentive for them to do so in the first place. The fact is — not all liars get rejected, some actually make it through.
In fact, this is the smarter pool of people who has a fair idea on how to crack the system to get to the interviews. They have good knowledge and curiosity to learn and achieve, but were bound by this vicious system as they might not have had an opportunity to work on the things they would have wished for.
Creativity in Resumes — Do we need it?
In my opinion, resume is nothing more than a cover letter, that lets the readers know very briefly, about your achievements and qualities. Yet, it is true that it is the “first impression” on the minds of the readers who would eventually be your recruiters if everything went well. So, how do you decide how much time and effort you should put towards creating your resume? Should you make it catchy so you can invite readers’ attention or should you keep it formal and make it look professional?
Are we looking for creative writers or software developers?
The evaluation of resumes are affected a lot more by aesthetics and storytelling. I know tons of developers who are brilliant at the work they do and have accomplished really good results in their past, but they do not possess the skill of presenting it well in their resume. The talent acquisition world demands creative writing skills from a core developer, whereas formatting, beautification and storytelling are not the skills that you actually care for in a software developer.
Standardized Creativity - Is it possible?
Everyone has a different way of writing their resume. Even with standardized resumes like a LinkedIn profile, the information about the impact and contributions of a developer can be written in such different ways that it ultimately needs a human to go through each resume manually to make sure that they haven’t misevaluated a profile.
This means that you are losing a lot of time in just evaluating resumes (2–5 minutes needed to properly evaluate a single resume on an average by one person.) Imagine the amount of time you would be wasting if you go through a 100 resumes. Mind that the average number of applicants to a software developer job is 118.
And no matter how you score the resumes, you cannot create an objective ranking out of it. On an average, out of 100+ applicants, companies still end up selecting 20+ applicants for the next round.
Some employers have come up with creative solutions where they examine candidates’ GitHub profiles to know the trend or frequency of their coding contribution. It is helpful that you can know from a filled up git profile that someone is actively contributing. Nevertheless, you can not judge otherwise if the heatmap is empty. In addition, people are smart and they always find a loophole to cheat the system. It is not surprising, how this system can be cheated by just adding a normal blog text in your website, not something that requires any coding skill. And yet, many employers try to look up candidates’ GitHub profiles to see if they can find anything valuable.
Procrastinating job search because of F.O.U.R.?
Fear Of Updating Resume — Creating or updating the resume is a very taxing process, and many employees who aren’t happy with their jobs don’t start looking just because of the inertia of updating their resumes. Here is a tweet that someone forwarded me where the person is experiencing a writer’s block while updating his resume! Just imagine what this system is doing to the developers!
What can be done?
As I said earlier, I am on a mission to derail the current system of relying on resumes, and replace it with something more reliable and suitable for all the software developers out there, who deserve to be judged on their coding skills rather than their writing skills.
As part of the hiring process in our startup “Vibinex”, our automation creates an objective profile of the candidate which uses their local ‘git’ repositories to generate a report of their contributions and skills offline, which makes it easier for them to showcase their achievements to us. Our automation not only looks at the candidate’s heatmap to understand how much and how actively a person is contributing, but also parses through their project folders to find text about their contribution, if it has been towards a blog or code pipelines. That’s not all, we are also designing metrics, like collaboration score, adaptability and degree of generalization, that would automatically neutralize such hacks. Although, we are still training and enriching our product to have better accuracy.
I would like to re-emphasize on the point that I am only talking about solving this problem for the software developers. Although, I understand that our solution would not completely solve the problem. I am very well aware that there are software positions where people don’t use git, and use other version control systems like Mercurial, Sapling and Piper that we don’t yet support. Some developers use tools that have their own versioning system that is not accessible publicly, and there are also software jobs like dev-ops and data engineering, which can be done without the need for any versioning at all. There could probably be an endless list of possibilities where our solution might not work, YET.
I am calling it “a mission” for a reason. I would ask you to join me in my mission and perhaps, one step at a time, we, you and me, can change the world of software development to a fairer, more-fruitful version of itself!