From Slashdot again - an interesting topic - how to recognize good programmers. While I strongly agree with most of the conclusions, in particular, passion as in how many side projects, or programming someone is doing just for fun, or investigation, or analysis of what is going on in the industry.
- I'd like to also point out that during an interview getting someone to dig and explain his/her work (the so what?, and how so?, how did you do it?) will help assess if this person understands what work he/she has done. One pattern I've found over the years is, how easily senior guys can answer the technical questions you ask them, they've been there done that. If one doesn't corroborate those answers with the person hands on experience and understanding of it - the risk are high that you're hiring process is letting in the wrong people.
- The candidate MUST be doing 80% of the talking during the interview, otherwise you are speaking too much!
- Don't hesitate to interrupt if an answer is not going where you want - you only have so much time.
- But you have to be willing to tolerate silence, so that what you hear from the candidate comes from the candidate, and not the answers you want to hear.
- Assess the people fit - the performance of your team is highly dependant on how well the team gels, hiring people that will fit in your culture is key. So when talking about past experience listen in carefully how the candidate speaks of his past bosses, colleagues?
- The people doing the interviews must be a good representation of what you're looking for. They will know what to look for, with much better ease.
- Remember the saying as well "A programmers hire A type programmers, B programmers hire B programmers, and C programmers have no idea who they hire"
From there you're done with Step one of Demarco's description of a manager's job (If my memory serves me well!)
- Hire the right people
- match the right people to the right jobs
- make sure the team gels!