his is a skill that most people believe they can do without training and yet most hiring managers do not get the results they desire.There are studies that show that unstructured interviews do worse than chance (most interviewers would be better off tossing a coin). The authors of these studies generally then go on to recommend some form of structured interviewing technique.
The main advice I would add would be to keep metrics on the success of your hiring process, continually refine the process based on those metrics and understand the needs of the role you are hiring for.I have been collecting metrics and statistics on not only my hiring decisions but my co-workers hiring decisions for 14 years and my personal experience is in total agreement with the scientific literature. Hiring is easy to get wrong and it is rare that hiring managers get any training.
Mistake 1: Trying to hire someone who would be good for any role - you need to start from a good understanding of the day to day needs of the role you are hiring for. Concentrating on the most common and most important and most error prone tasks.
Mistake 2: Choosing between soft and hard skills - The employee needs to both be able to do the job tasks AND to coordinate with their coworkers. Deciding based on one half of the equation and thinking you will train them up on the other is the road to heartbreak.
Mistake 3: Talking and not listening. If there is information they must know encourage them to ask questions. Their questions will tell you something. You talking will not.
Mistake 4: Assessing based on the type of questions you were assessed on at school. You are not interviewing them for the position of university student. The assessment needs to be as close to the real life tasks and behaviours the role requires as possible.
Mistake 5: Assessing on too many criteria - The passing grade for each criteria will be lowered and the time assessing fit for each criteria will be shortened if you try to fit to many in. Prioritise, Prioritise, Prioritise.
I usually go for a technical test that is realistic and as practical as possible for the hard skill component. In theory their is no difference between practise and theory but in practise there is.
Plus Behavioural Interviewing questions for the soft skills.
Failing on either the hard skills or soft skills is a fail.
I prefer depth to breadth. Hauling them over the coals on a few questions rather than let them bluff their way through a dozen. Remember in school how easy it was to bluff your teacher? Alternatively do you help your children with their homework and watch them bluff their way through? Be tough and drill down into the details.
.png)
- Recency Bias. People overestimate the frequency of events that are recent.
- Capturing everything. Some activities are more important than others. Some are easier to learn. Some are more frequent than others. Prioritise.
- Should do vs actually do. People will report that they are behaving the way they think they should behave rather than what they are actually doing. Sometimes their actual behaviour is more practical and productive than the rule they think they should be following. Either way encourage people to reflect on their experiences.
The biggest mistake of all - Thinking that you can not do better.
Related Posts
- Double Loop Learning - improvement & reassessing assumptions
- The Onboardees Checklist - The other side of the process
have released my first iOS App 
f you are like me, if you are like most people; you are plagued by a slew of irritations, annoyances and frustrations throughout your day. 
facilitated a brown bag lunch for my company's developers today. The topic for the brown bag was online resources that are useful for software developer in their work. We came up with a list of which I have recorded in the following section. It is far from a comprehensive list, however it contains some interesting and useful resources.
Yesterdays Scrum Event went very well with a record 70 people turning up. Craig did a splendid job of adjusting this planned talk on the fly to cope with the large number of Scrum beginners in the audience.
ome time ago I sat in on two iteration meetings for an adjacent team. There was a possibility that I would join the team on a part time basis, a possibility that never eventuated. 
was working with though some legacy code when I discovered that the original coder had