> I think this is also because no one really teaches you how to interview. Giving multiple interviews doesn't, at least IMHO make you knowledgeable to be on the other side.
This is something that I have ameliorated in my teams in the following way: When an Engineer is going to start interviewing people he goes through the following process:
0. Before starting, we provide some guidance on what we look in interviews and what we ask (1 hour meeting with the new wannabe interviewer and the manager)
1. First he shadows an interview done by a Tech Lead or Sr. Engineer (those are the ones that generally do the interviews)
2. Then he does two interviews, where he asks the questions but is shadowed by a Tech Lead of Sr. Engineer. He gets feedback about his interviews and is asked to explain his feedback and we tune it to the expectations from the team.
3. Finally he starts interviewing people on his own.
This has worked well enough for me, specially once we had a shared GDocs with a) The list of questions to ask (along with notes on what to look for and how to guide guys) and b) A "competency matrix" ( like http://sijinjoseph.com/programmer-competency-matrix/ ) tailored to what we were looking for.
Finally, one of the things I always emphazise the people that is interviewing for my team, is to remember how they felt during interviews. And be aware that as interviewer ALWAYS you have the upper hand. I hate being interviewed, I hate the feeling there, and the fact that you have 60-90 mintues to demonstrate that you know what the company is choosing to ask you, without regards of all other stuff you know that will be useful for the position, but they don't ask. And the nerves.
This is something that I have ameliorated in my teams in the following way: When an Engineer is going to start interviewing people he goes through the following process:
0. Before starting, we provide some guidance on what we look in interviews and what we ask (1 hour meeting with the new wannabe interviewer and the manager)
1. First he shadows an interview done by a Tech Lead or Sr. Engineer (those are the ones that generally do the interviews)
2. Then he does two interviews, where he asks the questions but is shadowed by a Tech Lead of Sr. Engineer. He gets feedback about his interviews and is asked to explain his feedback and we tune it to the expectations from the team.
3. Finally he starts interviewing people on his own.
This has worked well enough for me, specially once we had a shared GDocs with a) The list of questions to ask (along with notes on what to look for and how to guide guys) and b) A "competency matrix" ( like http://sijinjoseph.com/programmer-competency-matrix/ ) tailored to what we were looking for.
Finally, one of the things I always emphazise the people that is interviewing for my team, is to remember how they felt during interviews. And be aware that as interviewer ALWAYS you have the upper hand. I hate being interviewed, I hate the feeling there, and the fact that you have 60-90 mintues to demonstrate that you know what the company is choosing to ask you, without regards of all other stuff you know that will be useful for the position, but they don't ask. And the nerves.