Oct 22, 2009

Firing a Bad Hire

I found this great article in TechRepublic's Blog regarding a first hand account from Benny Sisko on how he fired a bad hire. He listed 6 lessons learned on how to avoid having a bad hire and I interjected my ideas in some of the lessons.

1. Perform a two-part interview.
Interviews are best done more than once with two or more pairs of eyes and ears in each sessions. Each interviewer is coming to the session with his/her own biases and expectations and this ensures that all questions are covered with the applicant. If not all, at least the most critical ones. Some may consider this as a waste of time but compare it with the lost time in productivity and morale impact later on due to a bad hire, the extra time and effort is well worth it.

2. Test the candidate.
Match the technical tests as close as possible to your technical requirements. If the position requires web development using HTML, JavaScript and CSS, give the applicant a test on how to develop a sample website using these 3 technologies. This will give you a pretty good idea on the skill level of the applicant without asking too many questions. In fact you can even go deeper afterward and conduct a code analysis to further probe on the logic and rationale behind his coding practices and framework.

3. Get more references and then get more references.


4. If he does slip by, coach, coach, coach.
Actually, even if the new hire is not slipping, it is worth it to have monthly or even bimonthly sessions to be more proactive if he/she is already encountering difficulties or only seeing potential problems in the horizon. These sessions will also serve as excellent feedback mechanism to level any expectations or misconceptions regarding assigned responsibilities.

5. Listen to the team.

6. Take the probationary period seriously and make it known that I intend to do so.



No comments:

Post a Comment