Last week, I finally got a resume that looked as if it had been written by a competent, adult software engineer. Not only that, the resume was actually quite impressive. Interesting projects, long tenure, career advancement…all good. So, I set up a phone interview and spoke with this particular candidate for about 1.5 hours, carefully working through his work history. The candidate’s responses were articulate and satisfactory, and he was quite eager to add additional details to clarify what he did.
So we brought him in for an interview. The candidate was an extremely pleasant, calm, very senior developer. But there was one catch; namely, he failed the technical tests we administer to candidates. So here are a few points from that experience.
First, if you have a skills section on your resume, you should be prepared to be tested on those skills. If you have skills that aren’t current–say, perhaps you were a COBOL programmer back in the day–don’t put COBOL in your skills section.
Second, the deciding factor against proceeding with this candidate was a) his failure to answer a math problem and a thinking problem, and b) his giving up on trying to answer some of the programming questions. Even if you don’t get an answer correctly, it’s important to demonstrate how you think. Giving up on a problem in an interview is not a good choice.
Third, this incident is a clear reminder that there is no substitute for technical testing. I’m going to revise our hiring practices to include more tests and also to move from pen and paper tests to a basic computer environment with eclipse, etc. (the last time I wrote code on paper was in 1982–just before I coded it onto punch cards)
Of course, I realize that the candidate may not have expected to walk into a test, and perhaps he hadn’t been on an interview in over a decade. Some folks don’t necessarily interview or test as well as others. If this is you, make sure you find out what you are walking into so that you can prepare to the best of your ability.