I’m convinced that the technical interview process, the process that a software team uses to select good candidates to add to a project, is totally broken in our industry. It’s broken mainly because most technical interviews try to answer one aspect of a good software developer (Is he/she a good coder?), whereas software development requires skills well beyond just coding and those skills are completely ignored in most interviews.
First of all, we need to talk a little about what some characteristics of a good software developer are. The list might vary a little from person to person but overall I think most developers will agree with me with the following list:
- Great coder. Writes maintainable, testable code for others to read and understand.
- Passionate. Cares about the work and tries to produce the best work possible.
- Team player. Cares about team members, seeks help and provides help to the team as needed.
- Independent. Pulls his/her own weight and gets stuff done for the team.
- Takes initiative. Does not just try to cruise along.
- Great communicator. Communicates clearly and concisely both verbally and written.
- Fun to be around. He/she is someone you would like to hang out with after work.
Over the years, I found that rockstar developers have most, if not all, of the characteristics above. What’s alarming is that only the first point (great coder) is traditionally measured in technical interviews. A candidate goes through hours and hours of hard technical questions (that sometimes the interviewer does not know the answer to, happens more often than you think!) and while coding skills eat majority of the time, the rest non-technical skills are either completely ignored or at best guessed through a series of informal chatty questions.
But why is that? Why don’t interviews test non-technical skills that are just as important? The main answer I can give from my experience is the lack of time and effort. In a typical interview setting, one has 30 mins to 1 hour max to test out a candidate. That’s barely enough time to get to know the person and gauge his/her technical background. It’s hard to predict if someone is passionate or a team player in 30 minutes, there are no questions that can answer “Is this an independent person?”. The other part is that it’s much easier for developers to throw couple technical questions to a candidate than to really try to get to know the candidate. Coming up with good technical and behavioral questions is hard and most developers do not have time or willingness to put their day work aside (where they get assessed at the end of the year for bonus) and spend time for interview preparations (where they have no incentive for a bonus). As a result, short technical interviews are bound to fail because they can only test whether the person is a great coder or not and nothing else.
So, are technical interviews doomed? Not really, if we put more time and effort into the process. In one of the groups I was part of at Adobe, after the initial interview, we used to give candidates a 1-2 day programming exercise to complete at home. The exercise was deliberately vague in order to force the candidate to ask questions and communicate. After the exercise was complete, we’d go through the code, asking him/her to explain code. This was very valuable because we got to see the coding style, we got a sense of the design style, communication style and got a more thorough view, away from the pressures of a regular interview process.
The same idea could be extended even further. Why not bring candidates for a trial period for a week or two weeks to your project and ask them to fix something about your project? They get paid, of course, you get to work with them as if they are coworkers and let them show themselves in a natural setting rather than the interview setting. At the end of the trial period, the team decides whether they want to work with that person or not. There are practical limitations (what if the candidate is currently employed?) and this is definitely much harder and time consuming for the team than the traditional interview process but it could definitely be made to work and it’s much better than hiring the wrong candidate and having him/her quit in the middle of the project.
The success and failure of a project depends a lot on the people who are part of the project. If we don’t have a good process to select good candidates for our project, what chance do we have to create the best software we can possibly create as a team?
Mete Atamel 