How (not) to ruin your résumé

I suspect that in the rush to pigeonhole candidates, recruitment agencies and the whole HR machine have taken résumé writing to absurd lengths. You usually get at least four densely packed pages with every acronym you've ever heard. On top of that, most candidates know at least four programming languages, three databases and two operating systems, to say nothing of eighteen frameworks. That impressive collection of knowledge usually comes with a sprinkling of training courses and webinars. Anyone unfamiliar with how things work would get the impression from these résumés that only superhumans turn up for interviews. I don't mean to offend anyone. I've embellished my own résumé a few times. The preceding lines might suggest otherwise, but a résumé is still worth more than the A4 paper it's printed on. From experience, I'd follow a few simple practices when writing one.

If you list a language, framework or technology on your résumé, assume someone may ask you about it in an interview. The line between really knowing a technology and putting it on your résumé to make your profile look better is often a single question. Excuses like “I used it briefly,” “I tried writing something in it at home,” or “I read about it” sound rather funny. A small improvement might be to give your own estimate of how well you know it. But I'd prefer a section called “Interests” where you can list everything that interests you.

If someone says what matters is the number of technologies you list on your résumé, be wary. Variety matters, but I wouldn't give it too much weight. You can achieve the same effect another way. Surprisingly few people list technical books that made an impression on them, or more generally the sources they use to learn and get new ideas. If someone who considers themselves a Java programmer can't name a single source they learn from, whether it's a website, a podcast, a blog or something else, I find that odd. One factor I consider crucial in an interview, and weigh more heavily than knowledge of the technology itself, is a willingness to learn new things. Something I'd call, poetically, an open mind. Especially in a field that changes as quickly as IT.

I like to ask candidates what they read last or which technology or idea caught their attention. That tells me much more than a densely packed résumé. It also feels more like a conversation than an interrogation when we talk about the subject. I don't like interviews that feel like school exams. Unfortunately that's exactly where résumés crammed with acronyms and technologies lead.

Another often underrated part of the résumé is the section on interests and hobbies. If someone's applying for a programming job, I probably won't care whether they have a category B driver's license. It isn't proof of anything, but someone who plays a team sport probably has little trouble getting along with people. If someone is an athlete or pursues another activity, they can probably cope with the hardships that come with sport. Those are all little pieces of the picture I'm putting together of that person. If I had to boil it down to one piece of advice, don't underestimate the details.

Of course, a résumé written this way doesn't guarantee success. Then again, is it worth wasting time on companies and recruitment agencies that favor quantity in the form of acronyms and formulaic résumés?