Interviews with developers: you do it wrong
Stories about how people are interviewed at Google remind me of those days gone by when I worked in a startup. For ten years of conducting “modern” IT interviews, our company has not learned anything, and I have been a part of this problem for several years. I just copied the standard interview mechanism of those times, and thus made a big mistake. I think that performance problems in companies that put developers at the forefront are burned into their DNA by the process of hiring new employees - fundamentally flawed.
My co-founder and I created a small web studio in Germany. We literally started 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 easy to find new employees - we just invited our friends. Of course, this method did not scale, but it performed a very important function: it ensured that new people fit the company well, both on a professional and a personal level. But the day came when we had to look for people from outside.
')
One of the advantages of the German employment centers is that within 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. Along with the resume 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 most resembled an oral exam at the institute. I asked the applicants to encode algorithms for ordinary CS-problems, and I received answers of very different quality. Some gave pre-prepared answers with unreal speed - they were prepared just for such an interview. Others broke under "pressure" and could hardly continue the interview.
Honestly, when we started to apply such a scheme, I had to look through such puzzles in advance so as not to get confused myself. This should be the first sign that perhaps we are not testing the skills we needed. If these doubts and creep into my head, I quickly dismissed them - in the end, everyone conducted their interviews that way.
Of course, we hired a candidate with the smoothest answers. And the next times, too, until the company went bankrupt. Sounds familiar?
What were the people we hired? Very different. Many were middling, a few were simply gorgeous, and a few were absolutely monstrous (at least in their posts). At best, 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 important criteria for me:
Company culture
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, the standard interview rated it the worst. In interviews, people are not very similar to themselves - in fact, they are encouraged for it.
Programming skills
Oddly enough, code samples written during the interview are a poor indicator of programming skills. Real projects rarely require the implementation of a binary search without access to the parser or literature. It turned out that people who performed the test tasks perfectly could not always transform theoretical knowledge into practical solutions. Writing sorting algorithms on the board reveals people with good short-term memory who are preparing for exactly such questions. In our case, we needed programmers who were able to write neat, reliable and elegant software - and the interview process did not select them.
Project management
The people interviewed were not necessarily good team mates or good negotiators with clients. It turned out that the hour cracker recruitment requires completely different skills than coordinating with colleagues or people who pay bills. Similarly, the behavior at the interview does not correlate with the ability to write documentation or behave when communicating online.
Such a process of finding new employees was one of the factors responsible for our company’s loss 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 covered by the ability to submit bad results in good form and with a limp. The best people left because they were oppressed by the new atmosphere. The worst of my employees was the one who showed the best results at the interview and supported them with the best academic success.
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 exam part. Ask a few open 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?
- In which professional online communities do you participate?
- Tell us about a professional thing that makes you feel strong.
These questions will tell you a lot about the person sitting in front of you, whether he is interested in the same thing as you, whether you like his style of thinking, what his passion is about. The ability to program? After the interview, look at any candidate code — written for an open-source project or at a previous job, it does not matter — it will tell a lot more than the intricate codes from 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, so I'm with them."
Nice, but will not work for large companies - this idea does not scale
Why so? One interview takes the same amount of effort. As a result, the interviewer always takes a subjective decision, my method just allows me to get more relevant information for its adoption.
Best programmers do not do projects in their spare time
The most talented people I know work from 9 to 5, and then go home to watch football
My experience dictates the opposite. Not that a developer should not have a 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 that 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 exercises with the board correlate with general literacy in computer science, but show poorly the ability to program. I think that the interviews were conducted just for so many years due to the fact that they were simply carried out in this way, but the data obtained from them is, at best, irrelevant. We (as an industry) must switch to personalized interviews, allowing us to present the full range of skills of the candidate. It is much more efficient to evaluate the working code, rather than abstract tasks that are not related to real work. Finally, I am convinced that insight into the essence of the developer’s personality is just as important as a professional fitness check - one fly in the ointment can destroy the entire team.
It is not clear from the article why the author’s company closed and why the author blames the hiring process so confidently. In order to prove his thesis, it would be necessary to establish a second company, exactly the same, but with a different process, and compare the results.
How we did it
My co-founder and I created a small web studio in Germany. We literally started 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 easy to find new employees - we just invited our friends. Of course, this method did not scale, but it performed a very important function: it ensured that new people fit the company well, both on a professional and a personal level. But the day came when we had to look for people from outside.
')
One of the advantages of the German employment centers is that within 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. Along with the resume 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 most resembled an oral exam at the institute. I asked the applicants to encode algorithms for ordinary CS-problems, and I received answers of very different quality. Some gave pre-prepared answers with unreal speed - they were prepared just for such an interview. Others broke under "pressure" and could hardly continue the interview.
Honestly, when we started to apply such a scheme, I had to look through such puzzles in advance so as not to get confused myself. This should be the first sign that perhaps we are not testing the skills we needed. If these doubts and creep into my head, I quickly dismissed them - in the end, everyone conducted their interviews that way.
Of course, we hired a candidate with the smoothest answers. And the next times, too, until the company went bankrupt. Sounds familiar?
What came out of it
What were the people we hired? Very different. Many were middling, a few were simply gorgeous, and a few were absolutely monstrous (at least in their posts). At best, 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 important criteria for me:
Company culture
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, the standard interview rated it the worst. In interviews, people are not very similar to themselves - in fact, they are encouraged for it.
Programming skills
Oddly enough, code samples written during the interview are a poor indicator of programming skills. Real projects rarely require the implementation of a binary search without access to the parser or literature. It turned out that people who performed the test tasks perfectly could not always transform theoretical knowledge into practical solutions. Writing sorting algorithms on the board reveals people with good short-term memory who are preparing for exactly such questions. In our case, we needed programmers who were able to write neat, reliable and elegant software - and the interview process did not select them.
Project management
The people interviewed were not necessarily good team mates or good negotiators with clients. It turned out that the hour cracker recruitment requires completely different skills than coordinating with colleagues or people who pay bills. Similarly, the behavior at the interview does not correlate with the ability to write documentation or behave when communicating online.
Result
Such a process of finding new employees was one of the factors responsible for our company’s loss 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 covered by the ability to submit bad results in good form and with a limp. The best people left because they were oppressed by the new atmosphere. The worst of my employees was the one who showed the best results at the interview and supported them with the best academic success.
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 exam part. Ask a few open 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?
- In which professional online communities do you participate?
- Tell us about a professional thing that makes you feel strong.
These questions will tell you a lot about the person sitting in front of you, whether he is interested in the same thing as you, whether you like his style of thinking, what his passion is about. The ability to program? After the interview, look at any candidate code — written for an open-source project or at a previous job, it does not matter — it will tell a lot more than the intricate codes from 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, so I'm with them."
Nice, but will not work for large companies - this idea does not scale
Why so? One interview takes the same amount of effort. As a result, the interviewer always takes a subjective decision, my method just allows me to get more relevant information for its adoption.
Best programmers do not do projects in their spare time
The most talented people I know work from 9 to 5, and then go home to watch football
My experience dictates the opposite. Not that a developer should not have a 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 that 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 exercises with the board correlate with general literacy in computer science, but show poorly the ability to program. I think that the interviews were conducted just for so many years due to the fact that they were simply carried out in this way, but the data obtained from them is, at best, irrelevant. We (as an industry) must switch to personalized interviews, allowing us to present the full range of skills of the candidate. It is much more efficient to evaluate the working code, rather than abstract tasks that are not related to real work. Finally, I am convinced that insight into the essence of the developer’s personality is just as important as a professional fitness check - one fly in the ointment can destroy the entire team.
Translator comment
It is not clear from the article why the author’s company closed and why the author blames the hiring process so confidently. In order to prove his thesis, it would be necessary to establish a second company, exactly the same, but with a different process, and compare the results.
Source: https://habr.com/ru/post/285370/
All Articles