Short on time? Just hit up the headings!
— Love, Eric
I’ve been on a hiring spree this year trying to find new coworkers at CMN.
Last year (2014), I naively hoped that through connections, social networking, conferences, and meetups, I’d stumble across someone that’d love to work together.
I didn’t put in nearly the effort I should have, so both Eric Rasch & I are pulling a recruiting hat-trick with:
Going through dozens upon dozens of CVs, I’ve noticed a consistent trend with both good & bad résumé patterns.
I desperately want every candidate to work out.
I’m rooting for you. But, there are several résumé mistakes that you’ll spend the entire interview fighting against.
1. Listing technologies that you won’t take a job for.
My advice? Delete any technology you don’t like, even if you’ve used it.
Or, if you’re a technology hoarder and can’t let go of all of your accomplishments, create a special category for Experienced, but Unfavorable Tech. At least I can clearly discern from what you want to do and what you don’t.
2. Including tools that everyone is familiar with.
It’s your duty to ensure that your résumé distinguishes you from the crowd.
Prominently listing common tools (e.g. cURL, Gem, Bower, Yeoman, etc.) is a needless waste of space that implies an equal, cursory understanding of all other tech surrounding it.
If you list Yeoman, you should know how to write a Yeoman Generator.
If you list NPM, you should be able to explain how to develop packages locally and use it as a build tool.
3. Listing what you used at your previous jobs, but not why.
You’re being hired (and subsequently paid) to make a positive impact.
Every reference you have should clearly explain why the company is in a better place because of you.
You changed a blog platform from Drupal to WordPress? Why? For a 200+% increase in speed? Rapid iterations on features? A common, familiar platform that the team can cohesively develop on? Pick something.
I know that some jobs have throwaway work that you’re not proud of, or did not make a markedly good difference. Of course, not everything can be a winner.
But, surely there was some way you became a better programmer as a result, right?
1. Have a clear “Make me move” objective.
At the top of your résumé, clearly state how you would like to contribute to your next company & what you would like to be doing technologically.
Perhaps 1 in 10 people do this (or do it well), and it immediately warrants a 1st interview and a clear conversation path.
Either I have something to offer you or I don’t. Otherwise, we both spend the next 30-60 minutes feeling out if it’s good fit.
2. Listing any & all projects you’ve contributed to.
Some contributions are minor (e.g. fixing typos), but any real contribution (e.g. code or docs) warrants reference.
The fact that you’ve selflessly (or even selfishly) improved documentation, added a feature, or heck, even reported a bug is worthy fodder for discussion!
There’s no better public indicator of how you work with a team as open-source software.
Yes, the mantra of GitHub is your résumé is fallible. But, there has to be at least one open-source project you’ve used in the last year. The odds are very good you encountered either a bug, a missing feature, or some unclear documentation.
Before sending off that résumé, put on some music, uncork a bottle of wine, and hit up your favorite projects to contribute some docs, discuss some issues, or write tests for an outstanding issue (right after your second bottle).
3. Clearly indicating the positive impact they’ve had in the past.
Companies want to read your résumé and think…
I hope they can do for us what they did for them!
Personally, I’m a fan of anything that has a percentage sign or unit of measurement attached to it:
- Reduced application errors from 2.3% to 0.7% on a 30-day average.
- Decreased bounce-rate on checkout page from 62% to 48%.
- Reduced server-side response times from 650ms to 230ms.
Your résumé should not simply state what you did, but sell what you can do.