In the aftermath, you have to wonder about the quality of these hires. I've mentioned before that software engineer Dan Kegel, who's active in Linux projects, says companies are tired of interviewing programmers who can't code. A piece at TechCrunch today "Why The New Guy Can't Code" tackles the question of how he got hired in the first place. (Writer Jon Evans specifically says in a footnote that it's always a man. His words, not mine.)
He points to this post by Evan Carmi, a guy seeking an internship at Google, and this advice from a Google interviewer. And then there's this post, "How Effective are Technical Interviews?" by Jean Hsu, an Android developer who recently joined Pulse, which make an iPad reader. These three posts have long comment strings that really get into the problems with interviewing at tech companies.
... it's like the Oakland Raiders always drafting the fastest runners available, only to discover to their endless dismay that the NFL is not a foot race.
Actually it's worse than that. At least wide receivers have to run, whereas I can guarantee you, without fear of contradiction, that no software engineer will ever have to write a binary search after they are hired.
The questions posed in the interview often have nothing to do with the job. And one commenter described the difficulty and stress as "a fraternity hazing ritual" by brainiacs who survived this torture and now want to abuse the next candidate. Google reportedly has revamped its hiring process and it's a good thing. Former CEO Eric Schmidt has been quoted saying that Google has been known to bring in candidates as many as 16 times before ultimately rejecting them.
Evans recommends as a baseline for hiring that all candidates have past projects to bring to the table - a site, app or service with real-world users - even new college graduates. Employers want you to show, not tell about your skills.<br />
Recruiters already are looking for that evidence. When I was writing about "yes" and "no" camps on cover letters, Dave Garrett, president of gantthead.com, a site for project managers, replied to my query this way:
Recruiters search our site ... and use the social-networking links to see: what PMs have posted in discussions, what they are interested in, what projects they have worked on and more. They are very hungry for information that goes beyond the resume to indicate actual strengths and weaknesses. I've heard this described at least a couple of times as "cover letter + data."
... if you only interview people with accomplishments, then you have a much broader base to work from. ... have the interviewee show and tell their code, and explain their design decisions and what they would do differently now. Have them implement a feature or two while you watch, so you can see how they actually work, and how they think while working. That's what you want from a technical interview, not a measure of its subject's grasp of some antiquated algorithm or data structure. The world has moved on.
I'm interested in your thoughts about improving the process for both the company and the job candidate. What would you do differently? Please chime in with your comments below.