Resumes that catch my eye (in a good way) May 23, 2011
In this post, I'll discuss some of the things I look for in a candidate and how a resume can communicate positive or negative relating to those things.
First, different positions require different personalities as well as different skills.
For example, if I'm hiring for a consultant-type person, I look for someone who likes to move around and likes diversity. This means that someone who has been at prior positions for a year or two is ideal for a consultant-type role. Folks who have been out of college for more than 5 years and have had more than 2 different jobs say, "I like diversity, but I may not be a 'sticker'." This kind of person would be ideal for consulting... either internally (a hit-squad that spends 3 to 15 months 'fixing' problems or kick-starting projects) or externally (going on client site). The consulting position, however, also requires a diplomat because making fundamental changes to systems or processes requires making the long terms owners of those systems to be comfortable with the changes. So, if I see the butterfly that flits from job to job, I'm going to look for words that indicate "boredom" with positions and with references that back that up, rather than someone who comes, see, aggravates and gets booted.
If I'm hiring for a long term position... a stable team member, I'm going to want to see someone who can make a long term commitment. This means a long term commitment to a team, a technology, and a company. Yeah, every team, technology, and company has its challenging aspects, but the long term team member has to be able to deal with the slings and arrows of whatever cruel fate awaits them. Every team, however, needs an explorer or two. These folks will try new technologies, methodologies, etc., and will get their team excited about the best of these technologies. If you're a long term team member who enjoys exploring new technology (the first kid on your block to do Agile, Ruby, Scala, Clojure, etc.), show how you were able introduce the best of those technologies to your team in a constructive way and have references that will back this up.
I always look for a finisher. It doesn't matter if you've won or lost, always finish. If you finished dead last, be ready to talk about what you learned. But each project that you start and don't see through is big negative in my evaluation. If the changes were beyond your control, either don't mention the project ("started XX, but senior management killed it because they were a bunch of toads, so we did YY to appease them" is worlds worse than "finished project YY" where YY is boring and old technology.)
Trying and failing. Are you someone who swings for the fences? "Founded a Google competitor, but get driven into the ground after 2 years." "Joined a team that built a better IDE, but couldn't find a business model to compete with Eclipse." This can be a cool thing, just like being an explorer on a team. I try to understand what you learned from each failure. If what you learned was, "it seemed easy when we started, but we quit when things got tough," that's a negative. If you went down with the ship and were the last one to turn off the lights and share your scars, that shows me courage and willingness to stick it out (or it means you're stupid like me and I'll bore you with tales of competing against Lotus in the spreadsheet market and selling OS/2 software after Windows 95 came out.) I'll also look to see if you can rein in the fence swinging when you join a team that has a different risk outlook than you do.
Your resume shouldn't be more than 1 page long in the tech field. Your resume should be a short story that tells me that you're a person who loves technology, works well with others... tells me the kind of thing that makes you really excited, and starts a conversation between us. I care about certain details (where did you work, what did you do there [DB, Lead Architect, Coder], what technology did you use [Java, .Net, etc.], what's your academic background.) But your resume is mostly a story that leads to a conversation between us.
One final thing, every person I've ever hired that has had a 3.6-3.9 GPA and was a material contributor to an open source project has worked out perfectly. That's my personal sweet spot.
Okay, one more final thing... being able to look at how you conduct yourself in open source communities tells me a lot about who you are. I won't hire people if they don't love technology enough to do it in their spare time (or find a way to weasel open source into their workday) and how they behave when they're not being paid for work is how they'll behave in the workplace.