What HR Professionals Look For in a Programmer's Resume

Last week, I wrote about the resume mistakes that can give your job application a short trip to the recycle bin. That was mostly a list of DO NOT DO THIS, and I had plenty of leftovers in the DO THIS category. This week, as promised, I share the opinions of professional HR staff and tech recruiters about what they want to see — and too often do not.

John Nicholson now runs Resumes That Jump and previously worked at Brainbench, an IT certification company. He's found that the three critical things likely to be left off résumés are:

1. achievements
2. metrics
3. introductory summary

Most people spend their entire résumé talking about everyday job duties, says Nicholson, such as "analyzed requirements" or "fixed bugs." They fail to stand out because plenty of other résumés are full of those same duties. Yes, Nicholson says, cover your primary responsibilities, but do it concisely. "Focus instead on unique achievements — things you initiated, architected, built, or were selected for that had a lasting impact on the company," he advises.

One recruiter backed this up with a bit more passion, by saying she dumps applications listing duties or tasks in lieu of real accomplishments. "So you just showed up to work for the last five years and only did exactly what you were told? There are another 100 people in line behind you, some of whom could actually tell me how they could be useful," she writes.

The best way is to highlight achievements with numbers. It's especially helpful to use numbers that have business meaning. An HR person doesn't need to be a techie to understand "saved company $2 million" or "reduced hours by 70%." Quantify your duties, too, such as number of people managed or number of projects led. Numbers do three great things, says Nicholson. They act as "slow down signs" to readers, they add credibility and uniqueness, and they show you understand and value business results. "Quantification is more challenging for programmers than, say, salespeople, but it's very do-able," he say. "I almost never see an IT résumé with enough numbers."

A related mistake is describing your organization rather than what you did personally. One recruiter discards résumés that tell her all about the company where you you worked and what they produced, instead of describing what you did to contribute. "I see this more on résumés with little experience in an attempt to make the resume bigger," she says. "When a résumé lists what the company does, what the application does and what the group was responsible for, one has to ask the question, 'What the heck did you do?'"

Do include an introduction in your résumé. Instead of jumping straight from name and contact information to chronological work experience, start instead with a title or header ("Senior Java Developer"), a compelling summary paragraph, and scan-able list of skills or core competencies, Nicholson says. Done well, the introduction gives readers context and makes them want to read more.

Don't make that list of buzzwords generic. Marsh Sutherland, president of Walden Recruiting, says technologies listed should include a self-rating of Beginner, Intermediate, and Expert and years of experience. Certainly, "5 years of J2EE" is more appealing than "J2EE," no? It's also helpful to include the year you last used the technology, says Sutherland.

Be sure to reconcile technologies you list in the summary to specific positions on your résumé. Each job description should include a "Technical environment included" section as the last bullet, listing all the technologies you worked with in that role, says Sutherland. If you really want to stand out, he says, include sample code; naturally, it should be well-documented with instructions and it should actually work. (I have to assume that this applies only when the submission process makes it possible to provide sample code; most of those annoying online application systems — which have you upload your résumé and then make you re-enter everything again — don't make it easy to upload any extras.)

We already know that HR pros and recruiters really love to see technology certifications, especially from the vendor of the technologies. If you have a choice (which I think generally means, "an existing employer who'll pay for it," right?) go for certification from the vendor. "Brainbench certification is nice and better than no certification, but not as good as a certification from the technology vendor themselves," advises Sutherland.

One unique situation that the HR people barely touched on — somewhat surprisingly, to me — is the expertise a developer gains on her own. I've long been a proponent of teaching yourself new, marketable skills by getting involved in an open source community. In addition to helping to improve the world in some way, you can gain skills worth marketing elsewhere. Want to learn a new language, add a new platform to your arsenal, take on a new kind of responsibility? Pick an open source project, and dive right in. I'm sure this is happening far more often than most recruiters realize (especially if you include your FOSS experience as a job, which I've seen often on LinkedIn). Yet the only specific advice I was given in this regard is "Separate your professional experience from your personal/academic experience." And even then, it was in a training and back-up-assertions context; the HR pro wrote, "Just because you took a single .Net class, you're still considered a Mainframe developer if that's what your experience is in." I dare say I could research another entire blog post on "how to present your open source experience in a résumé," especially as more developers successfully use the FOSS-gained skills in open source jobs.

You should follow me on Twitter.