HOME  → POSTS  → 2018

The Hiring Process, Part I : What I Look For in a CV/Résumé (Remastered)

Tech Industry2347 words12 minutes to read

Over my career, my job title has typically fallen into the baskets of: Front-End Web Developer, Software Engineer, or DevOps/SRE. I’ve done a lot of interviewing to try and find the right people to join the teams I’ve worked on, and I thought it might be helpful to share part of my process.

Remastered?

This is an updated and revised edition of my original piece from 2011, “The Hiring Process, Part I: What I Look For in a CV/Résumé”.

Over-arching Ideology

There’s a dynamite quote from the book The Laws of Simplicity:

Simplicity is about subtracting the obvious, and adding the meaningful.

I first read this book in 2006, and it has changed my perspective on so many things. But if there’s one single idea you take from this piece, it should be to substract the obvious and add the meaningful.

It begins with a stack of résumés…

Typically the process starts with a recruiter sending over a stack of résumés. There’s always some amount of time it takes to teach the recruiters how to identify what I’m looking for. My job is to make a determination as to whether or not this person is anything like what we’re looking to add to the team.

Now, I’m going to start by saying that my approach to résumés is greatly influenced by “A Glimpse and a Hook” and the follow-up, “A Brief Glimpse”. Like the author, I generally update my résumé every 6–9 months whether I’m looking for a new gig or not.

Your Name

There was a time where if you’ve done something notable on the HTML/CSS/JavaScript/PHP front, I’ve probably heard of you. However, in the intervening years since I transitioned from a Front-End Engineer → Application Engineer → Site Reliability Engineer, I’ve gotten busier, my kids have gotten older, and I quite frankly have other things to think about.

So, I may have heard of you, but don’t be offended or think I’m out-of-the-know if I haven’t.

Address and Phone Number vs. Your Blog, Twitter and GitHub

Address: I don’t need to know where you live. I don’t care. I’m not going to mail you a letter.

Email: An email address is good at the very least. Providing a contact phone number will probably save us a step, but isn’t strictly required.

However, I am keenly interested in where you live on the Internet. I want to see your personal website, your blog, your GitHub/GitLab/BitBucket account, your Twitter account. I like to know what you think about (Twitter), write about (Blog), and the kinds of problems you like to solve (GitHub).

Open Source or Free Software work is definitely a strong signal in your favor. Contributions to existing projects, or the open-sourcing of your own work — in non-trivial projects — is a very valuable skill to have. It shows me that you can play nicely inside an existing codebase. The fork-edit-PR workflow is an important part of how my team works, and having a background in that will make you more effective.

Objective

In my experience, this is near-universally worthless. It doesn’t tell me anything about you, and it’s usually either a mish-mash of bogus keywords or something so mind-numbingly obvious that you don’t need to waste the words on a page to tell me.

“To secure a position with a well established organization with a stable environment that will lead to a lasting relationship in the field of technology.”

Well, no shit.

Elevator Pitch

Your elevator pitch should summarize your value and experience in the length of a paragraph.

Assume that this is the only part of your résumé I’m going to read. What’s going to get my attention? I see a zillion résumés; what’s going to make me spend time with yours? Should it tell me every company you’ve worked for? No. You are not your job. Should it tell me about the kinds of problems you like to solve and the things you’re passionate about? Absolutely.

In all seriousness, the one résumé I’ve come across that has stuck out in my mind the most is Noah Stokes’ résumé. Now I’m certainly not recommending you make yours look like this, but think about the memorability factor. As a matter of fact, as I was writing this, I couldn’t remember Noah’s name. But I sure as heck remembered “ajax the shit out of your site”. A quick search, and his site came up and I remembered his name. Be that guy.

Some people have adoped the 1-pager style of résumé. I first came across this concept through my colleague Christen Dybenko, who in-turn got the idea from a post by David Seah. This idea has also been made popular by sites like CV Parade. It’s separate from your résumé, and is essentially treated as a list of highlights about you, your career and what you’re looking for.

It’s great interviewers with a short attention span, but that isn’t me. I’m looking to understand what you actually know. If you include it, that’s cool, but it’s not a replacement for a real résumé.

Skills and Software

Skills are more important than software.

Let me say that again: Skills are more important than software.

I care more about you being able to do something than I do about the tools you use to get there.

But even more than that, I want to know the difference between what you’re good at and what you’re not so good at. I’ve seen a lot of résumés that do little more than list out every single programming language they’ve ever heard of.

“Java, JavaScript, C#, ASP.net, PHP, Perl, Python, Ruby, Erlang and Haskell.”

Bullshit.

I recommend breaking your skills down into groups. The names of the groups don’t matter as much as how they’re classified. On a scale of one to ten, here’s how I group things:

  • 1–3: You have limited experience with these things — so I shouldn’t start firing a bunch of in-depth questions at you about them — but you’re interested in growing your skills in them over time, or they’re things that you’ve dabbled in and would like to dabble more.

  • 4–6: You’ve got a solid handle on these things, can answer questions about them, and would have no problem working with them on a regular basis.

  • 7–9: You have advanced abilities in these skills, teach other people how to do them, and can answer obscure or complex questions about them in an interview setting.

  • 10: You are an expert in your field. Not just in your company, but in your field. People on the internet know your name, and you get invited to join working groups or hold advisory positions about these topics. You could write (or have written) a book about the topic.

Most people should have their skills grouped into the first three groups. I personally give these groups the following names: Highly Proficient (7–9), Proficient (4–6), and Limited Experience Worth Mentioning (1–3). I’ve only interviewed an expert in their field once or twice in my career, so I’m certainly not expecting that out of you. But if I ask you how well you know a topic, and you say “10”, I’m going to drill you like a subject-matter expert.

Summary of Qualifications

I think Rands says it best in his aforementioned blog post:

[…] Here’s a good example from an imaginary résumé: “Proven success in leading technical problem solving situations”. This line tells me nothing. Yes, I know you’re trying to tell me that you’re strategic, but there is no way you’re going to convince me that you’re strategic in a résumé. I’m going to learn that from a phone screen and from an interview.

[…] When you write “Established track record for delivering measurable results under tight schedules”, I am going to ask you what the hell you mean on the phone and if your answer isn’t instant and insightful, I’ll know your qualifications are designed to be buzzword compliant and don’t actually define your qualifications.

Most of the time, this section doesn’t tell me anything because it tends to be packed with buzz-words or overzealous/unbelievable claims. I don’t care about stuff that doesn’t tell me anything. If I can’t discern your qualifications from your Elevator Pitch or your skill set, then you’re already in trouble.

Instead, I’d like to get a sense of what it would be like to work with you — warts and all. This is important because I believe that it’s important to know who you are and who you aren’t. If you feed me a line like “I work too hard” or “My work is too perfect”, I’m going to move onto the next résumé. Why? Because you just told me that you’re inefficient and you don’t know how to prioritize effectively.

Give me a sense of what it’s like to work with you. What kinds of things can I expect?

Work Experience

This is the meat and potatoes of your résumé. For most people this is just a bulleted list of things they did at the job. Again, I don’t care about that. There are a few specific things that I look at in this area:

  • I want to see what you accomplished (or where your focus was), what you learned, and how you’ve grown.

  • How long were you at the job? For a full-time gig, I’d expect to see at least a year. Anything shorter than that is a red flag.

  • At the same time, if I see that you’ve been at the same company for ten years, that’s also a red flag. How could you possibly grow in your career if you’ve had the same job for a decade? (Yes, I know it’s possible, but there’s going to be a burden of proof on you.)

  • Have you done any open-source work? Yes, that should go here too. This is work experience. Just because you may or may not have received a paycheck for it doesn’t mean it wasn’t work. Having good experience here would likely offset any red flags triggered by the previous points.

  • If you list an accomplishment like “raised revenues by 10%”, my very first question in the interview is going to be “how?” Be prepared to back up anything you claim on your résumé.

  • Are you passionate about what you do, and does that passion exude from your résumé (or blog, or Twitter, or open-source work)?

Now, I understand that some jobs just plain suck. I’ve had a couple of those myself. How did you make the best of them, and what were your take-aways?

References and Recommendations

In white-collar jobs, references have gone the way of the dodo bird.

The thing that services like LinkedIn have made more prevalent are recommendations. Without having to pick up a telephone and ask questions, what do your co-workers, managers, teammates, and other folks have to say about you? A link to your LinkedIn profile (or something similar) will do in a pinch.

Now, I understand that the whole purpose of a LinkedIn recommendation is to show that person in the best possible light. In that way, a lot of recommendations are junk. Knowing that, I’m less concerned about positive or negative spin and more concerned with what they write about you? What language do they use? How well does it seem like they know you, and what kinds of things do they bring up about you? Do I see a recurring theme throughout all of your recommendations? How well do they mesh with how you’ve described yourself?

Other Tips

Here are a few other things to think about:

Have some skin in the game: I’ve gotten jobs before because people knew of my work. They knew my reputation before they knew me. A huge bonus is if you’re already doing the thing that I’m trying to hire for.

Sound like a human being: If you say “planned, designed, and coordinated engineers efforts for the development of a mission critical system”, you sound like — no, just no. Only write stuff that will actually tell me something about you. Tell me about your process. Tell me about the issues you had to address. What kind of issues did you face?

Spelling and Grammar: If you misspell wrods (see what I did there?) or have generally poor grammar, I’m going to move on. You’re an adult, presumably you graduated from high school, and you should be able to speak and write effectively. This especially applies to the following areas:

  • Their, there, and they’re
  • Then and than
  • Lose and loose
  • Except and accept
  • Effect and affect
  • And brand/product names: “I-phone” (instead of iPhone) and “MAC” (instead of Mac, or Macintosh, or macOS) is very, very wrong.

If you’re not going to take the time to get your writing right (especially on a résumé), what else are you not going to take the time to do?

Conclusion

Now, I know that I don’t speak for everybody. Some people take a very different approach to reviewing résumés, and that’s fine. It’s also possible that I’m not the kind of person that you’d like to work with/for, and that’s fine too.

I know that facets of my approach are used by people that I consider some of the best in the industry, and as such I’ve tried to learn from the best ideas I’ve come across to make the most informed decisions possible when determining whether or not to schedule the next step (i.e., the phone interview).

If you’re involved in creating things for the web, take heed to my suggestions. Even if you don’t follow all of them, definitely make it a point to raise the quality of your résumé.

is an engineering manager with over 20 years of experience across software development, site reliability engineering, and security. He is the creator of SimplePie and AWS SDK for PHP, patented multifactor-authentication-as-a-service at WePay, defined much of the CI/CD and SRE disciplines at McGraw-Hill Education, and came up with the idea of “serverless, event-driven, responsive functions in the cloud” while at Amazon Web Services in 2010. Ryan's aptly-named blog, , is where he writes about ideas longer than . Ambivert. Curious. Not a coffee drinker.