The Worst Developer Resume in the World
As someone who has been recruiting in the software industry for nearly 20 years, I’ve read perhaps tens of thousands of résumés. Good and bad. My experience prompted me to launch a part-time résumé review and writing business (Résumé Raiders if you must know), as I found that résumé services were both grossly overpriced and of poor quality.
There is one résumé type that I get at least once a day, and it’s unreadable. It is immediately recognizable once I open the document and see the first page, and my suspicions are confirmed when my eyes wander to the bottom and see the dreaded “Page 1 of 7”.
I’m not sure as to why, but I belive this style is more common among Java developers – although admittedly my sample size for Java is larger than for other language communities.
The Résumé
It starts with a “summary”…
So the résumé’s summary is a half page long? The writer regurgitates every single technology they’ve ever used, puts them into bullet points, and has the audacity to call it a summary? This creates what we call a signal-to-noise problem, where the sheer volume of content makes it impossible for a reader to decipher what is important information and what is not.
I preach to all my résumé clients that a summary is the most important part. Why? Résumés are often initially reviewed by recruiters, many of whom are inexperienced and not the best at identifying talent. The summary is an opportunity to tell the reader exactly who you are without having to let the reader interpret your experience.
You want to hire a Python developer with at least five years of experience? If a summary starts with “Python Developer with five years of experience…”, that doesn’t give even the most incompetent recruiter the chance of missing the qualification. Keeping the summary clear and concise is the key.
So what’s next?
Thanks…but didn’t we just do this??? We’ve now read the first page of the résumé, and the applicant has mentioned every technical skill at least twice. I know what you’re thinking. This is an attempt to get the attention of those ATS’s (applicant tracking system) we keep hearing about. When it is assumed that the reader is not human, some may choose to repeat keywords in an SEO-like attempt to game the system. Does it work? Probably not, but I don’t think that is the reason behind this.
But let’s keep reading…
After starting off with a summary which was really a set of bulleted lists containing buzzwords, followed by a skills section which was just a categorized list of the same buzzwords, we come to the experience section which is the same list of buzzwords accompanied by a short description of what those buzzwords do.
The Problems
There are a couple problems here.
The first is that the reader is looking to quickly qualify or disqualify an applicant. When the reader discovers that the résumé is seven pages that seems to mostly be lists of buzzwords, that doesn’t provide much incentive to read it. The size is intimidating to a reader, which gives a negative instinctual reaction. Imagine a friend is relocating and asks if you can help with the move, and on arrival you see a garage full of barbells and bags of sand.
Even if it’s part of the recruiter’s job to review résumés and make a yes/no decision, this style résumé is a lazy excuse to just say “no”.
The biggest problem, for both the applicants and the industry at large, is that these résumés sometimes belong to good developers. I’m a strong résumé writer but a weak coder, and there are likely thousands of people who are strong coders that have no idea about résumés.
If your résumé bears any resemblance to what I’ve described above, do yourself a favor and fix it ASAP.
Perhaps you could’ve say how to fix the problems. I’m sure that with your 20 years of experience on the field you should know at least some guidelines of what works and what doesn’t.
Making a post of just “This is wrong, don’t do it.” But not giving possible solutions I think it’s just frustrating.
Thanks for reading, and you aren’t the first person to ask “what should we do?”. For most of the problems I list, it’s as simple as doing the opposite. “Don’t write a half page summary with 50 bullets”, “Don’t list every technology you’ve ever heard of”.
I’m actually writing a follow-up post now which may be helpful and give some best practices, and this should be ready in a day or two. Stay tuned.