How to Improve Technical Interviewing Skills - Things You're Likely Doing Wrong and How to Fix Them.
Are you good at technical interviewing? If not, you are not alone. Due to the long and incomplete feedback loop for interviewers, many people in the industry are following bad practices without realizing it. However, there is a way to break this cycle and improve your skills.
This long-lost-now-found video captures our talk at the 2013 ALM Summit in Redmond, WA. In this recording, my fellow Microsoft employee Jonathan Wanagel and I delivered a presentation titled “Technical Interviewing - You’re Doing it Wrong!”
Through this presentation, we hoped to inspire change in how technical interviews are conducted, ultimately leading to better hires and stronger teams. The response from attendees was encouraging and reaffirmed the importance of continuous improvement in the hiring process.
During the talk, we highlighted eight anti-patterns that interviewers should avoid. As mentioned by Jonathan, many of these practices may have originated at Microsoft, but they are commonly seen in companies around the world. Our goal was to explain why these patterns are detrimental and provide guidance on how to avoid them through forecasting and improving the candidate experience.
So, if you want to hire better candidates faster and have fewer of them declining your offers, watch this video!
Forecast
To forecast is to make a prediction in advance. When we hire people, we make predictions based on written and verbal communication as to whether a given person will be a good fit, both culturally and skillfully, in the company over a period of time. Although, some organizations do this by having a trial period, most companies in the tech industry hire solely based on the interview. That means the forecast made in the interview has to be fairly accurate. Yet this forecast is only as good as the common understanding of why and how they are hiring.
Skills, Competencies, or Both?
Let’s say your reason to hire is that you need more C# programmers. Most companies would screen prospective candidates based on that particular skill: Do they know C# or not? While that makes sense on the surface, it might not be the best way to make a hiring decision. Skills, after all, are easy to learn and can be picked up in a matter of months. A developer who knows java but has never tried C# will be able to pick up C# after a few months, especially when paired with an experienced C# programmer. This assumes, of course that the developer has an ability and willingness to learn, to ask questions, to share his strengths and weaknesses; to put his ego aside and have the courage to learn a new language in order to best help his team.
Let’s reverse that, then, and imagine we hire a very experienced C# programmer who is uncomfortable working in pairs. He doesn’t want to improve or branch out from C#, so can never be taught new languages. And he doesn’t enjoy mentoring others, so he cannot share his extensive skill set. No matter how senior or experienced this developer is, he would not be a good fit at Scott’s company, or on any agile team, because of the misalignment of values.
Based on those two scenarios, screening candidates should always include competencies—how a person thinks, how that person interacts with others, and what that person values. These will impact how quickly he can assimilate with a team and how rapidly he can learn new skills. After all, you might need that same person to learn yet another new language a few projects down the road. In general, you should hire for long-term fit, not for short-term expertise.