There’s been a lot of buzz surrounding Joel Spolsky’s recent article on writing résumés, so I thought I’d chime in with my experiences and another article I found.
A few months ago, we went looking for a web developer to help with our online banking redesign project. We wanted a contract-to-hire ASP.NET developer. I was fortunate enough to have had a hand in crafting the job description that went out with the posting and was asked to participate in the final interviews. I took the challenge seriously because whoever was hired was someone that I’d have to work with closely and it would be very difficult to get the person fired if he or she didn’t work out—as some unfortunate experiences with previous co-workers indicated.
First let me address some annoying things I saw in the résumés that were submitted:<ul><li>Try to limit your résumé to a single page or two at the most. One guy, who wasn’t hired, submitted a seven-page beast that went on forever. It was a pain wading through it and it didn’t speak well for a parsimonious mind.</li><li>Proofread your résumé and have other people proofread it to. Oh, and run it through the spell checker. There were many people who obviously didn’t do that. There were odd capitalizations of technologies aplenty: if you’re applying for an ASP.NET job, don’t capitalize it Asp.Net or Asp.net—it’s a little thing, to be sure, but if you’re deficient on details while trying to get hired then I’m skeptical about what we’ll get if we do hire you.</li><li>List certifications that are relevant to the job at hand and don’t put them in the most prominent place. You’d think that someone applying for an ASP.NET job would know that we don’t care about your Cisco certification, but people think that they have to put them in there since they went to the trouble of obtaining them. The guy with the seven-page résumé had 29 certifications and he listed them all. Color me not impressed.</li><li>If a job description emphasizes web application development in an object-oriented model exclusively, don’t apply if you’re a Web designer or procedural coder. You’re wasting our time and we’ll probably be enjoying a laugh at your expense.</li><li>As a corollary of the above, don’t shovel in every technology that you’ve used, read about, or heard of in an effort to defeat the mythical HR filtering software. We didn’t have anything of the kind and it really came across as unbelievable. If you feel the urge to pile this stuff in, check with the company to see if they use filtering software.</li></ul>When I participated in the interviews, I came up with a set of ten questions of a general programming nature to try to get a sense of the interviewee’s programming chops. My co-worker’s list consisted of technical questions specific to ASP.NET. By balancing these two areas, we really ran the interviewees through the ringer and I think it worked out pretty well. I’ll post an update tomorrow with the actual questions I asked. That said, here’s some things I encountered during the interviews:<ul><li>Don’t be late.</li><li>If you’re going to be late, call well in advance and have a good reason. Reschedule if necessary.</li><li>If you call in advance and notify the interviewers that you’ll be late, don’t be late to that.</li><li>Don’t bring copies of your 29 certifications to the interview.</li><li>Listen to the questions asked and answer them. Or ask clarifying questions until you feel you understand what the interviewer is seeking.</li><li>Appear decisive when answering questions. Don’t hemm and haw or change directions in mid-sentence.</li><li>Think about your answers if you have to. No one will think ill of you if you ask for a minute to consider the question. No, really. If that’s what it takes to give a representative answer, they’ll thank you for it.</li><li>If you’re not familiar with some particular programming construct that popped up in a question, don’t pretend like you are and answer with what you think it might do. No, really. Don’t. Say that you’re not familiar with that and that you’d probably check the online help in Visual Studio.NET or do a quick Google search on the construct. Show that you’ve got a plan of how to acquire new knowledge; no one expects you to know everything. Chances are good that the obscurity of the construct was designed to test whether you’re blowing smoke or not.</li></ul>Well, that’s about all the advice that I accumulated from my recent interviewery. I’m sure there’s more that I’ve forgotten; I’ll post an update if I think of any more.