December 24, 2009 at 16:28How do I hire programmers
- Transfer
There are three questions that you need to know the answer to when you hire a programmer:
1) Is he smart?
2) Is he able to do the job?
3) Will I be able to work with him?
Someone smart but not able to do the job may be a good friend, but not an employee. You can discuss some problems with him while he is cooling down on his own work.
He who is capable of doing work but not smart is ineffective. Stupid people do work by brute force. Working with such people is slow and usually annoying.
With those with whom I cannot work, I cannot work.
Traditionally, the process of hiring a programmer consists of:
1) reading a resume;
2) a brief interview (by phone);
3) performing a test task.
In my opinion this is a terrible system. From the resume, as a rule, very little is understood, and during an interview a person is usually nervous. Programming is almost a creative process, to check for the ability to it under such pressure is by and large useless. In addition, questions for the interview usually turn out to be some kind of inexplicably cruel. I consider myself a good programmer, but I could never properly answer these interview questions.
Therefore, when I hire a person, I try to get an answer to these three questions.
To understand whether a person is capable of doing work, I just ask what he did. If a person is really capable of doing work, then he should already have something to tell about what he has already done. It is difficult to be a good programmer without practical experience, and today it is very easy to get such experience by participating in any open source project. I ask you to show a piece of program code and a demonstration of the project. Looking at this, you can understand a lot at once, because I look at the finished result of the work, and do not look for logic in the answers to the far-fetched interview questions. How concise, elegant, transparent is this code? Is this the kind of code I would like to see in my product?
To understand whether a person is smart, I just try to chat with him informally. I do everything possible so as not to put pressure on a person: make an appointment in a cafe, make it clear that this is not an interview, I do everything to be informal and friendly. In no case do I ask questions that are standard for an interview. I just chat with a person, like someone I met at a party (it’s a bad idea to ask about the “strengths and weaknesses of the person” or to give an estimate of the number of piano tuners in Chicago). In my opinion in a normal conversation it’s quite easy to understand how smart a person is. I constantly note about people how smart they are, just as we all notice how attractive a person is.
If you try to formalize what exactly makes a person smart, I would note three things.
First, does he know anything at all. I ask what he has been thinking about lately and then I ask about it. Does he really understand something in the subject, which he himself has chosen, whether he understands his details, whether he can clearly speak out on this subject. The ability to clearly state thoughts is a sign of a true understanding of the subject. Does a person know something about an object that I do not know.
Secondly, is he curious. Does he react with questions in my direction. Is he really interested or just trying to be polite. Does he ask questions about what I'm talking about, do his questions make me think.
Third, do he teach. At some point in the conversation, I usually explain something. Does he really understand the things I'm saying, or just nods and smiles? There are many people who really know a lot in some narrow area, but who do not show interest in others at all. There are people who are curious, but not at all trained: they ask a lot of questions, but do not listen to the answers.
I would like the answer to all three questions to be positive.
Finally, I have to understand if I can work with a person. To do this, I try to just spend time with him. Many people may look like diamonds for an hour, but in a couple of hours the situation can completely change. Therefore, after the conversation, I invite a person to have a bite with the rest of the team, or for some game in the office. It is important to keep the atmosphere as informal as possible. The point here is simply to see if a person is getting on my nerves.
If everything looks like I'm ready to hire a person, then as a last test, to make sure that I have not been fooled, I ask you to do some part of the work. Usually this means choosing a completely separate area of work, and asking the person to do it. If in this situation it is necessary to assess whether a person can work under pressure, you can limit it to a hard time. You can offer payment for this work, although usually this is not necessary, since most programmers do not mind performing a small piece of work, provided that the result remains open (open source). Such a check by means of completing a task does not work separately on its own, but if a person has passed the first three, then this is more than enough to be sure
I understand that a lot of people will say: “Why not just hire a person for a trial period and see how it goes?” In my opinion this just doesn’t work. If you are not able to form an opinion about a person after a small project, you will not be able to do this in a month. The end result is that you constantly hire people who are not good enough.
I am generally satisfied with this method. If I miss one of the parts, very often it turns out that I hired someone unsuccessfully, and I have to leave the person. But when I fully observe everything, I hire people who I really like and who it is very difficult to part with later. I am amazed that most companies use such stupid methods of hiring staff.
1) Is he smart?
2) Is he able to do the job?
3) Will I be able to work with him?
Someone smart but not able to do the job may be a good friend, but not an employee. You can discuss some problems with him while he is cooling down on his own work.
He who is capable of doing work but not smart is ineffective. Stupid people do work by brute force. Working with such people is slow and usually annoying.
With those with whom I cannot work, I cannot work.
Under the cut, continued article by Aaron Schwartz . I would rather be interviewed in this way than being studied by an OK employee girl who does not distinguish http from mp3.
Traditionally, the process of hiring a programmer consists of:
1) reading a resume;
2) a brief interview (by phone);
3) performing a test task.
In my opinion this is a terrible system. From the resume, as a rule, very little is understood, and during an interview a person is usually nervous. Programming is almost a creative process, to check for the ability to it under such pressure is by and large useless. In addition, questions for the interview usually turn out to be some kind of inexplicably cruel. I consider myself a good programmer, but I could never properly answer these interview questions.
Therefore, when I hire a person, I try to get an answer to these three questions.
To understand whether a person is capable of doing work, I just ask what he did. If a person is really capable of doing work, then he should already have something to tell about what he has already done. It is difficult to be a good programmer without practical experience, and today it is very easy to get such experience by participating in any open source project. I ask you to show a piece of program code and a demonstration of the project. Looking at this, you can understand a lot at once, because I look at the finished result of the work, and do not look for logic in the answers to the far-fetched interview questions. How concise, elegant, transparent is this code? Is this the kind of code I would like to see in my product?
To understand whether a person is smart, I just try to chat with him informally. I do everything possible so as not to put pressure on a person: make an appointment in a cafe, make it clear that this is not an interview, I do everything to be informal and friendly. In no case do I ask questions that are standard for an interview. I just chat with a person, like someone I met at a party (it’s a bad idea to ask about the “strengths and weaknesses of the person” or to give an estimate of the number of piano tuners in Chicago). In my opinion in a normal conversation it’s quite easy to understand how smart a person is. I constantly note about people how smart they are, just as we all notice how attractive a person is.
If you try to formalize what exactly makes a person smart, I would note three things.
First, does he know anything at all. I ask what he has been thinking about lately and then I ask about it. Does he really understand something in the subject, which he himself has chosen, whether he understands his details, whether he can clearly speak out on this subject. The ability to clearly state thoughts is a sign of a true understanding of the subject. Does a person know something about an object that I do not know.
Secondly, is he curious. Does he react with questions in my direction. Is he really interested or just trying to be polite. Does he ask questions about what I'm talking about, do his questions make me think.
Third, do he teach. At some point in the conversation, I usually explain something. Does he really understand the things I'm saying, or just nods and smiles? There are many people who really know a lot in some narrow area, but who do not show interest in others at all. There are people who are curious, but not at all trained: they ask a lot of questions, but do not listen to the answers.
I would like the answer to all three questions to be positive.
Finally, I have to understand if I can work with a person. To do this, I try to just spend time with him. Many people may look like diamonds for an hour, but in a couple of hours the situation can completely change. Therefore, after the conversation, I invite a person to have a bite with the rest of the team, or for some game in the office. It is important to keep the atmosphere as informal as possible. The point here is simply to see if a person is getting on my nerves.
If everything looks like I'm ready to hire a person, then as a last test, to make sure that I have not been fooled, I ask you to do some part of the work. Usually this means choosing a completely separate area of work, and asking the person to do it. If in this situation it is necessary to assess whether a person can work under pressure, you can limit it to a hard time. You can offer payment for this work, although usually this is not necessary, since most programmers do not mind performing a small piece of work, provided that the result remains open (open source). Such a check by means of completing a task does not work separately on its own, but if a person has passed the first three, then this is more than enough to be sure
I understand that a lot of people will say: “Why not just hire a person for a trial period and see how it goes?” In my opinion this just doesn’t work. If you are not able to form an opinion about a person after a small project, you will not be able to do this in a month. The end result is that you constantly hire people who are not good enough.
I am generally satisfied with this method. If I miss one of the parts, very often it turns out that I hired someone unsuccessfully, and I have to leave the person. But when I fully observe everything, I hire people who I really like and who it is very difficult to part with later. I am amazed that most companies use such stupid methods of hiring staff.
I’ll add that some parts of the approach cause rejection, especially an attempt to play informally in the office of the employer, I myself would run away from this, but this is an American approach, you don’t have to copy everything 1 in 1, repeating the mistakes of unlucky advertisers and marketers. Although the author alludes to errors in Google’s approach (about piano tuners, is it in their direction?), He uses part of Google’s approach himself: for example, when he concludes that the applicant’s ability to express his thoughts.
upd:
The task of tuning piano to google, it turns out, who just did not use. For example, they write about her here and even earlier she was mentioned in the book How to Move Mount Fuji. Thanks to those who corrected.