I have been reading Joel on Software, which is Joel Spolsky's web site on programming, interviews, jobs, etc. (He is also the author of the book by that name.) Via one of his blogs, I found another site, Gayle Laakmann, who is an undergrad CS student at Penn. Both sites contain, among other things, interview questions given at companies like Google, Microsoft, etc.
Joel Spolsky's Guerrilla Guide to Interviewing contains a statement I wanted to comment on:
"An important thing to remember about interviewing is this: it is much better to reject a good candidate than to accept a bad candidate. A bad candidate will cost a lot of money and effort and waste other people's time fixing all their bugs. If you have any doubts whatsoever, No Hire."
I can accept that given the amount of competition for software jobs, some people will fall through the cracks. However, no one should be surprised if people who actually held software positions and were actually getting work done become discouraged and leave the field if they find themselves unable to pass these interviews. Since these interviews come fairly early in the evaluation process, there's nothing they can do to offset a poor performance that's not indicative of how well they'd actually do the job, such as using their references. (Although one could make the argument that references will generally say good things, so chances are you're not going to find many, if any weaknesses that way in candidates.)
cellio, you have been interviewing potential hires lately; are you finding that there is a strong correlation between performance on this type of interview and on the job?
Joel Spolsky's Guerrilla Guide to Interviewing contains a statement I wanted to comment on:
"An important thing to remember about interviewing is this: it is much better to reject a good candidate than to accept a bad candidate. A bad candidate will cost a lot of money and effort and waste other people's time fixing all their bugs. If you have any doubts whatsoever, No Hire."
I can accept that given the amount of competition for software jobs, some people will fall through the cracks. However, no one should be surprised if people who actually held software positions and were actually getting work done become discouraged and leave the field if they find themselves unable to pass these interviews. Since these interviews come fairly early in the evaluation process, there's nothing they can do to offset a poor performance that's not indicative of how well they'd actually do the job, such as using their references. (Although one could make the argument that references will generally say good things, so chances are you're not going to find many, if any weaknesses that way in candidates.)
cellio, you have been interviewing potential hires lately; are you finding that there is a strong correlation between performance on this type of interview and on the job?
Profile
- gregbo
- gregbo
- gregbo's homepage
Comments
Informal networking before the interview does help provide useful information. High-tech-wise, this is a small town; odds are good that someone here has worked with the person if he's local. If he's not local, I think some reference-checking happens before the expense of flying him in for an interview, but I could be wrong about that.
We aren't as hardcore as what Joel describes, by the way. And we deliberately spend a good chunk of time talking in a group setting about higher-level stuff and not code, so we can see how the person interacts with a group, talks about his methods, etc. And we want to make sure there's a good fit in both directions, so we talk about what he wants to do and what his ideal job is and so on and he asks us about the stuff that matters to him.
I didn't make it to the next cut of interviews, and I'm wondering in the case of people who did, what's the difference between them and me. I wouldn't think that something where all one needed to do was look something up, perhaps taking a couple of minutes, would be significant in terms of employee performance. And anyone can momentarily forget something like a port number or a program option. Perhaps the decision wasn't made on the basis of the interview per se, but on other things, e.g. other candidates were still working (and presumably "fresh"), or younger, or came from companies where they were able to focus on these types of problems more than I could. But there's nothing I can do about that.