The Stupidity Of Interviews

Job interviews in this industry have definitely gone down hill in the past few years. What used to be about determining character fit and general programming ability has been reduced to single method writing, doing logic puzzles and API memorization.

Resumes seem to be mostly useless, virtually no one actually reads them before the interview and they seem mostly not believed. In this way resumes become a kind of worm to dangle in front of the recruiter or HR fish, just enough to hook some interest, but are discarded afterwards. The actual contents are expected to be padded or invented so they may as well just say "DUDE KNOWS CODE".

Talking with references, particularly former coworkers who might know the candidates best, almost never happens and certainly not before an interview. I can understand a fear of talking with former employers, who are reluctant to say anything concrete; but why also ignore references given by the employee? Sure, some might lie but not everyone.

Sometimes companies require a test before they will talk with you, most of them are either too simple or can be easily looked up on the internet. Tests rarely demonstrate ability other than memorization anyway; I've know people who aced certification tests and were utterly unable to develop any useful applications. Certifications themselves seem mostly ignored as well, probably for this good reason.

The job interview has become the sole determiner of whether to hire someone or not, based on no useful information whatsoever beyond the time spent interrogating the candidate. So people now ask for some code writing (write some useless method up on the whiteboard that any sane person would use a framework for), solving puzzles (falling into a blender or handing out gold to pirates) or ask for some specific API knowledge that generally appears in online documentation. Sometimes I wonder if the whole reason for the interview is to see if the user is a liar.

Of course to be be fair, there are a lot of people applying for jobs with no actual skills, a made-up (or doctored by the recruiter) resume, and a hope for a clueless interviewer. Basing everything on a single (or multiple or gang) interview usually done by people who hate doing it (other programmers) is likely to lose good candidates who don't feel comfortable in such a stressful environment, and hire people who talk good but can't perform. It's not enough data to determine a good fit. Even putting people through hours or interviews (all basically covering the same ground) is such a waste of time.

I have interviewed people for most of my career, and have never asked someone to write code on the wall or solve some unrelated logic puzzle. I want to know if the person I am interviewing has a clue about programming, can explain their work in detail, understands things not on their resume, and is able to explain the pros and cons of their technology background. In 10 minutes I can know whether they are worth considering. It's all in the way they communicate their knowledge, respond to specific questions on projects they claim to have worked on, and demonstrate a willingness to learn.

Of course a lot of people say "you are looking for a coder, shouldn't they have to code for you"? I would say no, unless its in front of a computer, using familiar tools and environments, and on something similar to what they would be working on (or have worked on). I personally never write code standing up in front of a whiteboard; I always write code a bit at a time, testing as I go, until I am comfortable knowing it works and all potential issues dealt with. It doesn't demo well on a whiteboard. Why should writing a single method be any more useful than asking about data structures? Would you hire a homebuilder on the basis of ability to hit a nail into a board?

I have often wished people could bring in something they wrote, and then ask them questions about why the wrote what they did (it's hard to fake that knowledge if you never wrote the code). To me that would be more useful than some random method.

Puzzle solving is a part of programming, but not random logic puzzles. I can just imagine a police department hiring a detective and then asking them to solve a sudoko puzzle; it's not really the same.

I want to know what they know about programming, how they think about programming, what they have done, what they have learned, how they work and in doing so, how they communicate.

The end result is not to find that one person with the exact resume matching a laundry list of technologies (they have 3.14159 years of JUnit!) but someone who can work successfully with the other team members, is capable of doing or learning anything required, knows how to think, and has some kind of track record of actual work.

I always wanted to apply for job with a resume saying "DUDE KNOWS CODE". Who knows, it might work these days.