March 31, 2011 at 14:35Interviews with developers: you are doing it wrong
- Transfer
Stories of people interviewing Google remind me of the days gone by when I worked at a startup. For ten years of conducting “modern” IT interviews, our company has not learned anything, and I have been part of this problem for several years. I just copied the standard interview mechanism of those times, and made a big mistake. I think the performance problems in companies where developers are paramount are burnt in their DNA by the process of hiring new employees - fundamentally vicious.
My co-founder and I created a small web studio in Germany. We started literally in the basement of my friend’s house, but over time the company grew and we moved to a real office. At first, it was not difficult to look for new employees - we simply invited our friends. Of course, this method did not scale, but it performed a very important function: it ensured that new people are well suited for the company - both on a professional and personal level. But the day came when we had to look for people from outside.
One of the advantages of German employment centers is that a few hours after the request they will send you a whole stack of resumes; I was pleasantly surprised that we would not have to hire an agency for this. Together with the resumes sent through our website, we have a choice. As a result, we agreed on a dozen of the best candidates and invited them for an interview. From that moment on, everything went wrong.
The candidate came dressed in his best suit and tie, we sat down and talked. This conversation was most reminiscent of an oral exam at the institute. I asked the applicants to code the algorithms for ordinary CS problems, and I received answers of very different quality. Some gave pre-prepared answers at an unrealistic rate - they were being prepared just for such an interview. Others broke under “pressure” and could hardly continue the interview.
Honestly, when we started applying such a scheme, I had to look through such tasks in advance so as not to get confused myself. This should be the first sign that, perhaps, we are not testing the very skills that we needed. If these doubts crept into my head, I quickly dismissed them - in the end, everyone did their interviews like that.
Of course, we hired a candidate with the smoothest answers. And the next time, too, until the company went bankrupt. Sounds familiar?
What were the people we hired? Very different. Many were middle peasants, some were simply magnificent, and some were absolutely monstrous (at least in their posts). In the best case, the interview did not affect the quality of the people we chose, but, I am afraid, shifted the scale in favor of the worst.
What, in fact, is meant by “good” and “bad” in this context? Here are some criteria that are important to me:
Culture of the company
In retrospect, one of the most important qualities of a new employee was compatibility with the spirit of people who already work in the company. Obviously, a standard job interview rated this the worst. In an interview, people are not very similar to themselves - in fact, they are encouraged for this.
Programming skills
Oddly enough, the code examples written during the interview are a poor indicator of programming skills. Real projects rarely require binary search without access to the parser or literature. It turned out that people who perfectly completed the test tasks could not always convert theoretical knowledge into practical solutions. Writing sorting algorithms on the board reveals people with good short-term memory who are preparing for just such issues. In our case, we needed programmers who could write neat, reliable and elegant software - and the interview process did not select them.
Project management
The people interviewed were not necessarily good teammates or good negotiators with clients. It turned out that hourly recruitment of a recruiter requires completely different skills than coordinating with colleagues or people who pay bills. Similarly, interview behavior does not correlate with the ability to write documentation or behave when communicating online.
This process of finding new employees was one of the factors responsible for the loss by our company of its startup spirit and creative soul. Of course, the global failure was my fault, but because of the unsuccessful selection of people, the company could not produce high-quality software in the volumes that were needed to keep it afloat. Internal friction poisoned our teams. Incompetence was hid by the ability to give poor results in good shape and sneak. The best people left because they were oppressed by the new atmosphere. The worst of my staff was the one that showed the best results at the interview and backed them up with the best academic successes.
Of course, this is an extreme case - many companies succeed regardless of their hiring process. But I think a radical change in our methods will significantly increase the chances of finding good employees. In our case, this would change a lot.
What should the interview with the developer look like? Very simple: cross out the examination part. Ask a few open-ended questions that will allow candidates to talk about their work.
- What project did you work on in the previous company?
- Tell me about your favorite projects.
- What projects do you work on in your free time?
- What professional online communities do you participate in?
- Tell us about a professional thing that causes you strong feelings.
These questions will tell you a lot about the person sitting opposite you - is he interested in the same thing as you, do you like his style of thinking, what is his passion. Programming skills After the interview, look at some candidate code - written for an open-source project or at a previous job, it doesn’t matter - this will tell you more than the intricate codes of a dozen lines on the board.
Many people rush to defend the status quo, and this is a convenient position - without risks, and you can always resort to the argument "a lot of smart, rich and successful people do it this way, that's why I am with them."
Nice, but will not work for large companies - this idea does not scale.
Why? One interview takes as much effort. As a result, the interviewer always makes a subjective decision, my method simply allows you to get more relevant information for its adoption.
The best programmers do not do projects in their free time.
The most talented people I know work from 9 to 5, and then go home to watch football.
My experience tells me the opposite. Not that the developer should not have life - but he should have an enthusiasm for programming.
In my free time, I earn the next million for my company. And when I do not work for the company? This time I spend with family or friends.
Great - these people can show me something they are working on. But I regard the absence of my projects as a bad sign for some types of work.
Traditional developer interviews are not enough to find good candidates. Typical whiteboard exercises correlate with general computer literacy, but poorly show programming ability. I think that the interviews were conducted in this way for many years due to the fact that they are easy to conduct in this way, but the data obtained from them is at best irrelevant. We (as an industry) must switch to personalized interviews to present the full range of candidate skills. It’s much more efficient to evaluate working code, rather than abstract tasks that are not related to real work. Finally, I am convinced that insight into the personality of the developer is just as important as checking professional suitability - one fly in the ointment can destroy the whole team.
From the article it is not clear why the author’s company was closed and why the author so confidently blames the hiring process. To prove his thesis, a second company should be established, exactly the same, but with a different process, and compare the results.
How did we do it
My co-founder and I created a small web studio in Germany. We started literally in the basement of my friend’s house, but over time the company grew and we moved to a real office. At first, it was not difficult to look for new employees - we simply invited our friends. Of course, this method did not scale, but it performed a very important function: it ensured that new people are well suited for the company - both on a professional and personal level. But the day came when we had to look for people from outside.
One of the advantages of German employment centers is that a few hours after the request they will send you a whole stack of resumes; I was pleasantly surprised that we would not have to hire an agency for this. Together with the resumes sent through our website, we have a choice. As a result, we agreed on a dozen of the best candidates and invited them for an interview. From that moment on, everything went wrong.
Standard interview
The candidate came dressed in his best suit and tie, we sat down and talked. This conversation was most reminiscent of an oral exam at the institute. I asked the applicants to code the algorithms for ordinary CS problems, and I received answers of very different quality. Some gave pre-prepared answers at an unrealistic rate - they were being prepared just for such an interview. Others broke under “pressure” and could hardly continue the interview.
Honestly, when we started applying such a scheme, I had to look through such tasks in advance so as not to get confused myself. This should be the first sign that, perhaps, we are not testing the very skills that we needed. If these doubts crept into my head, I quickly dismissed them - in the end, everyone did their interviews like that.
Of course, we hired a candidate with the smoothest answers. And the next time, too, until the company went bankrupt. Sounds familiar?
What came of it
What were the people we hired? Very different. Many were middle peasants, some were simply magnificent, and some were absolutely monstrous (at least in their posts). In the best case, the interview did not affect the quality of the people we chose, but, I am afraid, shifted the scale in favor of the worst.
What, in fact, is meant by “good” and “bad” in this context? Here are some criteria that are important to me:
Culture of the company
In retrospect, one of the most important qualities of a new employee was compatibility with the spirit of people who already work in the company. Obviously, a standard job interview rated this the worst. In an interview, people are not very similar to themselves - in fact, they are encouraged for this.
Programming skills
Oddly enough, the code examples written during the interview are a poor indicator of programming skills. Real projects rarely require binary search without access to the parser or literature. It turned out that people who perfectly completed the test tasks could not always convert theoretical knowledge into practical solutions. Writing sorting algorithms on the board reveals people with good short-term memory who are preparing for just such issues. In our case, we needed programmers who could write neat, reliable and elegant software - and the interview process did not select them.
Project management
The people interviewed were not necessarily good teammates or good negotiators with clients. It turned out that hourly recruitment of a recruiter requires completely different skills than coordinating with colleagues or people who pay bills. Similarly, interview behavior does not correlate with the ability to write documentation or behave when communicating online.
Result
This process of finding new employees was one of the factors responsible for the loss by our company of its startup spirit and creative soul. Of course, the global failure was my fault, but because of the unsuccessful selection of people, the company could not produce high-quality software in the volumes that were needed to keep it afloat. Internal friction poisoned our teams. Incompetence was hid by the ability to give poor results in good shape and sneak. The best people left because they were oppressed by the new atmosphere. The worst of my staff was the one that showed the best results at the interview and backed them up with the best academic successes.
Of course, this is an extreme case - many companies succeed regardless of their hiring process. But I think a radical change in our methods will significantly increase the chances of finding good employees. In our case, this would change a lot.
Alternative
What should the interview with the developer look like? Very simple: cross out the examination part. Ask a few open-ended questions that will allow candidates to talk about their work.
- What project did you work on in the previous company?
- Tell me about your favorite projects.
- What projects do you work on in your free time?
- What professional online communities do you participate in?
- Tell us about a professional thing that causes you strong feelings.
These questions will tell you a lot about the person sitting opposite you - is he interested in the same thing as you, do you like his style of thinking, what is his passion. Programming skills After the interview, look at some candidate code - written for an open-source project or at a previous job, it doesn’t matter - this will tell you more than the intricate codes of a dozen lines on the board.
Negation
Many people rush to defend the status quo, and this is a convenient position - without risks, and you can always resort to the argument "a lot of smart, rich and successful people do it this way, that's why I am with them."
Nice, but will not work for large companies - this idea does not scale.
Why? One interview takes as much effort. As a result, the interviewer always makes a subjective decision, my method simply allows you to get more relevant information for its adoption.
The best programmers do not do projects in their free time.
The most talented people I know work from 9 to 5, and then go home to watch football.
My experience tells me the opposite. Not that the developer should not have life - but he should have an enthusiasm for programming.
In my free time, I earn the next million for my company. And when I do not work for the company? This time I spend with family or friends.
Great - these people can show me something they are working on. But I regard the absence of my projects as a bad sign for some types of work.
Final thoughts
Traditional developer interviews are not enough to find good candidates. Typical whiteboard exercises correlate with general computer literacy, but poorly show programming ability. I think that the interviews were conducted in this way for many years due to the fact that they are easy to conduct in this way, but the data obtained from them is at best irrelevant. We (as an industry) must switch to personalized interviews to present the full range of candidate skills. It’s much more efficient to evaluate working code, rather than abstract tasks that are not related to real work. Finally, I am convinced that insight into the personality of the developer is just as important as checking professional suitability - one fly in the ointment can destroy the whole team.
Translator Commentary
From the article it is not clear why the author’s company was closed and why the author so confidently blames the hiring process. To prove his thesis, a second company should be established, exactly the same, but with a different process, and compare the results.