HOME  → POSTS  → 2011

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

Tech Industry2369 words12 minutes to read

Over my career, my job title has typically fallen into one of two baskets: Front-End Web Developer or Software Engineer. I’ve done a lot of interviewing over the past several years 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.


Typically the process starts with an in-house recruiter sending a stack of résumés to my manager. My managers have usually taken a swag at filtering out the ones that are clearly junk, and then pass them off to me to make a determination as to whether someone is worth a phone call for the position.

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 update my résumé every 3–6 months whether I’m looking for a new gig or not.

Your Name

I’ve been around. You might call me an Internet slut. If you’ve done something notable on the Front-End/HTML/CSS/JavaScript/PHP front, I’ve probably heard of you. That’s already going to be a plus.

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

I don’t need to know where you live. I don’t care. I’m not going to mail you a letter. 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/SourceForge/Google Code 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).

Not having these — as a Web or PHP developer — is a red flag for me. I wouldn’t necessarily expect someone with a Java or .NET background to use Twitter or GitHub (nothing against Java or .NET developers). But if you’re working in PHP, Ruby or the front-end, I expect to see these things otherwise I’m going to suspect that you’re out of touch with what’s happening right now.


If you have this on your résumé, get rid of it. It sucks. 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 Google, and his site came up and I remembered his name. Be that guy.

Alternatively, I’m also a fan of the 1-pager. 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 isn’t a résumé replacement, but it’s a good way for you to hook my interest.

Some sites make this easy for you; About.me and Zerply come immediately to mind.

Skills and Software

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.”


I recommend breaking your skills down into three 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.

  • 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.

If you bother to list software on your résumé, there should be a good reason for it. For example, I list things like find, grep, and other command-line tools available on Mac/Linux systems. This is useful because instead of saying “Mac OS X” or “Linux”, it tells me something more valuable.

And this is a personal pet peeve of mine: Don’t list Microsoft Office apps on your résumé. If your résumé is so bare that you have to list Microsoft Office apps, Adobe Acrobat or your preferred web browser, you’ve got bigger problems.

Summary of Qualifications

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

Similar to Skills, this is another skip section for me. 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.

Unlike Skills, which I find to be a total waste of time, I will go back to Summary of Qualifications if we end up talking. 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, it’s a bunch of junk that doesn’t tell me anything. 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.

Me? I have a strong personality and sometimes I steamroll over people if I’m not paying attention. If the team I’m applying for is comprised primarily of easy-going and/or delicate personalities, I probably won’t be a good fit for your team. But if you’re looking for someone who has the backbone to make a decision and commit, and have other people on the team with strong personalities who like to hash out ideas to find the best ones, then I’m likely a great fit.

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 accomlishment 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

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?


Generally, I completely skip this section. The only thing I check for is whether or not you have a Master’s degree. What my personal experience has taught me is that a Master’s degree means very little real-world experience, and the experience that they do have is generally pretty useless.

Now, if you have your Master’s degree and know your stuff, then that’s great. But understand that you’re in the minority.

Other Tips

Here are a few other things to think about:

GitHub > Résumé: A GitHub account is better than a résumé. I’ll learn more from looking at your code and the kinds of things you like to work on than I ever will by looking over your résumé.

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 a jargon machine more than a human being. Only write stuff that will actually tell me something about you. No mumbo-jumbo.

Spelling and Grammar: If you misspell something or have generally poor grammar, I’m going to move on. Sorry. This especially applies to the following areas:

  • Their, there, and they’re
  • Then and than
  • Lose and loose
  • And brand/product names: “I-phone” is very, very wrong.


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é.

Ryan Parman

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.