The Worst Developer Resume in the World
The Worst Developer Resume in the World
Anyone hiring developers has seen this style of résumé, and it hurts both the applicant and the industry at large.
Join the DZone community and get the full member experience.Join For Free
Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies.
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.
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.
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.
Opinions expressed by DZone contributors are their own.