45 minutes seems too short to me. I'm guessing its 45 minutes because the candidate goes thru a series of interviews. I think this is a mistake as well-- the third time explaining the same thing about his past experience, the candidate has a lot of trouble remembering what he's already told you, vs the guy he saw less than an hour ago.
I think a much better method would be to have 3 interviewers maximum, though fewer is better, have them spend an extended period of time with the candidate (preferably all at once, not in series) and to develop a rapport with the candidate.
Sure, interviews are intimidating, and if you're having trouble getting them to open up, introducing a programming question isn't going to make it easier. A programming question with a time limit, to boot.
I've been asked a lot of programming questions in my career, and back when I worked for other people, I'd generally go on 5 interviews and get four offers and a callback. Figure 20-40 programming questions every job hunt.
When I didn't get an offer, or it was clear that the interviewer was not satisfied, it was nearly always because the interviewer did an incompetent job. Maybe %5 of the time the question just stumped me. But I've seen a lot of people with really heavy accents who get visibly upset when you ask them to repeat what they said, and when they do repeat it they use exactly the same words and don't try to explain it in a different way. Often interviewers leave out key concepts or requirements when presenting the question because they've presented it so many times they forget. I've had interviewers explain it wrong, and many times I've had to correct the interviewer because I recognized the question they were actually asking.
Now I wonder, how many of these people who fail, or "don't know what a for loop is" are really failing, or not just reflecting poor interviewing skills on the part of the person asking the question?
Its really easy to have a high failure rate when you leave out a key requirement. (and then what's the candidate going to say "you never said that"?)
I've met a lot of interviewers that really weren't competent themselves. I tend to ask them questions (though I never got cheeky enough to demand that they program for me as well) and a surprisingly high percentage of them are trained coders who know one particular area, and seem prone to judge candidates by their knowledge in that area. I didn't get a job once because I was asked about assembly language and explained that I'd only had experience with 6502, Z80 and 8080, which the interviewer thought was the same as 8088 and therefore I should be able to write code in the modern intel instruction set, in assembly. This was for a company doing a social voice web app widget!
And don't get me started on interviewers asking me to write code but who won't shut up long enough for me to finish a complete thought in my head.
If you get someone to write fizz buzz for you, and your company is developing software more complicated than fizz buzz, then you haven't really learned anything from it.
If they "can't" write fizz buzz, how did they get in the room with you in the first place? Think they spent the last several years writing software but somehow lost the ability when placed on the spot in an interview? (I'm not being sarcastic, I genuinely am curious about this.)
I think there's a lot of people with a machismo complex, certainly I've been the subject of them, who are up for the same position, or wanted it, or think that nobody measures up to them, or just delight in seeing failure, or have such a narrow view of things that if you can't write assembly in a win32 environment, you're no good writing web apps either.
I think a much better method would be to have 3 interviewers maximum, though fewer is better, have them spend an extended period of time with the candidate (preferably all at once, not in series) and to develop a rapport with the candidate.
Sure, interviews are intimidating, and if you're having trouble getting them to open up, introducing a programming question isn't going to make it easier. A programming question with a time limit, to boot.
I've been asked a lot of programming questions in my career, and back when I worked for other people, I'd generally go on 5 interviews and get four offers and a callback. Figure 20-40 programming questions every job hunt.
When I didn't get an offer, or it was clear that the interviewer was not satisfied, it was nearly always because the interviewer did an incompetent job. Maybe %5 of the time the question just stumped me. But I've seen a lot of people with really heavy accents who get visibly upset when you ask them to repeat what they said, and when they do repeat it they use exactly the same words and don't try to explain it in a different way. Often interviewers leave out key concepts or requirements when presenting the question because they've presented it so many times they forget. I've had interviewers explain it wrong, and many times I've had to correct the interviewer because I recognized the question they were actually asking.
Now I wonder, how many of these people who fail, or "don't know what a for loop is" are really failing, or not just reflecting poor interviewing skills on the part of the person asking the question?
Its really easy to have a high failure rate when you leave out a key requirement. (and then what's the candidate going to say "you never said that"?)
I've met a lot of interviewers that really weren't competent themselves. I tend to ask them questions (though I never got cheeky enough to demand that they program for me as well) and a surprisingly high percentage of them are trained coders who know one particular area, and seem prone to judge candidates by their knowledge in that area. I didn't get a job once because I was asked about assembly language and explained that I'd only had experience with 6502, Z80 and 8080, which the interviewer thought was the same as 8088 and therefore I should be able to write code in the modern intel instruction set, in assembly. This was for a company doing a social voice web app widget!
And don't get me started on interviewers asking me to write code but who won't shut up long enough for me to finish a complete thought in my head.
If you get someone to write fizz buzz for you, and your company is developing software more complicated than fizz buzz, then you haven't really learned anything from it.
If they "can't" write fizz buzz, how did they get in the room with you in the first place? Think they spent the last several years writing software but somehow lost the ability when placed on the spot in an interview? (I'm not being sarcastic, I genuinely am curious about this.)
I think there's a lot of people with a machismo complex, certainly I've been the subject of them, who are up for the same position, or wanted it, or think that nobody measures up to them, or just delight in seeing failure, or have such a narrow view of things that if you can't write assembly in a win32 environment, you're no good writing web apps either.