How do I hire programmers

I wanted to write an article related to interview for a long time. Today, I saw an English article on how to interview programmers on the Internet, and found that there were many things that resonated with me, so I wrote this article based on its title and my own experience.

Work over the years, was interviewed, also interviewed people, for the programmer interview, experienced a very good interview, very professional interview, also experienced some BT and unpleasant interview, I personally feel that a good interview, the interviewer is important, therefore, this article from the perspective of “interviewer” to describe. So, with the following such an article, I hope this article is useful to your workplace experience, especially those who are recruiting and interviewing programmer friends, I think this article will have a lot of enlightenment for everyone. In addition, as a candidate for the interview, you may want to check out how Other Programmers read Your resume, Basic Skills for Programmers, 10 Habits of Great Programmers, and other articles about programmers on this website.

For recruiters, when it comes to hiring programmers, I suspect there are three main things they want to know when interviewing candidates:

1. Is the programmer smart enough?
2. Can the programmer get things done?
3. Can this programmer work with my team?

I believe that these are the three questions that all team managers need to think about when hiring, and that almost all questions revolve around these three questions. Sometimes, you might think that the technical skills of a programmer can solve all three problems at once, and that a person with good technical skills is necessarily a smart person who can get things done and work with a team. Yes, it feels that way, but it’s not. There are people who are really smart but can’t handle their work well. They should be your friend, your adviser, but not your employee. Someone who is nice and gets along with everyone on the team, but is not very smart, but works very hard and works very hard, can become your subordinate, for example, the assistant of a key subordinate, or the assistant of the whole team. If someone can’t work with the team, no matter how smart they are or how good they are at solving problems, you shouldn’t work with them. Everyone thinks that harmony of the team is the prerequisite of everything.

The traditional interview and recruitment process basically goes something like this:

1. Read the applicant’s resume and ask the applicant to introduce himself.
2. Ask difficult, highly detailed technical questions in a question-and-answer format.
3. Give the interviewer some and a few programming puzzles. (Like some weird algorithm problem)

I personally find this approach laughable and terrible, especially the latter two points. Usually, these interviews will only lead to nerds or tech geeks, so let me break down the drawbacks of each one.

1. It’s hard to get a sense of a person from their resume or self-introduction. Because these are written by the parties themselves, or explained by themselves. So, it’s not very accurate, you can only know very simple things from your resume, and that’s not enough to get on the team. By asking the candidate to introduce himself at the beginning of the interview, he or she will face the interview in a formal manner. When the interview process is very formal and very serious, it can be very confining. Actually, that’s not what we want. I want people to be authentic and natural, so that we can get the real thing.
2. Ask a few technical questions. For example: I personally experienced — “What does the -a parameter of PS mean?” “, “What is the command to delete newlines in vi?” “, “what is the C++ keyword explict,mutable for? Wait, wait, wait. As a candidate in the past, I hated this kind of question, because this kind of question can be seen in the manual. Was he asking for a dictionary manual? Not one person? What matters here is not the knowledge, but the ability to find it.
3. Give the candidate one or more difficult algorithms, give them ten minutes, and then ask the candidate to write down pseudocode or code. It is quite funny, can’t discuss check information, let a person be in a state of stress under the answer, it is not the actual work of the state, has become a kind of spite and our interview (I most abnormal experience is, when I put the code written in the book of the two pages to go up, next to the interviewer give its output computer programmer do check, the programmer said, Compilation error. So the interviewer says, “Unfortunately, maybe you haven’t written enough programs,” which is pretty ridiculous). At this point, the important thing is not the answer to the problem, but the idea and method of solving the problem.

I’ve done a lot of interviews in the past, and when tech people come to interview me, I find that the “tech mind” for some people can’t tell the difference between an interview and an exam. Subconsciously, a lot of the time, they are not interviewing the person, but giving them a hard time and demonstrating their skills. I personally think I’m a good programmer, but I can tell you I can’t get through an interview like that because that interview is for them, not for the candidate.

So, how do I go to the interview?

1. Confirm your resume. First of all, it is necessary to read the resume of others, from the resume, work experience, project experience, technical skills these three things you need to know. In general, you can call them to determine their work history, project history and technical skills, and then, if they are a match, call them in for a face-to-face interview. Don’t call someone in and say something about how your experience is different from what we do. (I once had an interview experience with a company that I will not say, but one that claims to need good communication. I was interviewed about 9 times, from general programmer, PM, manager to general manager, and the last time I was directly told that my previous experience was quite different from their requirements. I can’t help but ask, what have they been doing in the previous several interviews?

Two, the interview opening. Secondly, invite people to come to the company for an interview, it’s very important that you make sure that the interview process is casual and relaxed, just like a normal conversation or conversation between friends. This way the candidate will relax and come out with a real face to talk and chat with you and you will learn more in a very short period of time. The onus is on the employer to let the candidate off the hook and behave naturally. Never say that the other person is too nervous to perform well. Sometimes, the employer needs to think about their own problems.

Never ask the candidate to introduce himself or herself at the beginning of the interview, because the candidate has already sent you their resume and you have already called them. On the other hand, it makes the interview process too formal and serious. So, how did the candidate fare? How’s it going? You can also talk about general topics such as sports, music, movies, social issues and try to put everyone at ease without putting on a straight face. In addition, you can learn something about his/her interpersonal skills and personality. Also, don’t put a desk between you and the candidate, and make the environment casual.

Ask the applicant to tell more about his experience. Next, if you want to get a sense of whether this candidate is a problem solver, someone who can get things done, don’t ask what he or she can do, ask what he or she has done. What have you done? For a good programmer, it’s hard to imagine that you haven’t had some experience, even if you were in college. If you’re a problem solver, it’s clear that you solved a lot of problems and got things done today. Listen to the candidate’s story. (Don’t ask and answer. Ask the candidate to talk, listen and think more.)

As he talks about his projects, there are usually a few things you should pay attention to:

• Communication skills. Can the candidate make one thing clear? If this person is smart, he can explain a complicated matter in the simplest language. Moreover, this is the most basic ability of a good programmer. Also, you can have some good back and forth conversations with the candidate as they describe their experience, so you can get a sense of their communication skills and style, and get a sense of their character.
• Roles and positions. Maybe he was involved in a big project, but only in a very simple module. Therefore, it is very necessary to understand their role and position in the project. When using words like “we” or “you,” be specific and specific.
• What they have contributed and what they have solved. This is very important because it tells you whether the interviewer is smart, has the ability to solve problems, and has a good technical background.
• Demonstration. If possible, you can ask the candidate to show you some code, designs, or demos of programs he has written. (You can learn a lot about design, code style, reuse, and maintainability.)
• The basics. Get some basic knowledge of the technology the candidate is using in the project. For example, through the process, you can ask some basic knowledge of networks, languages, image objects, and systems. Basic knowledge is very important, which is directly related to his ability.
• Processes and tools. Understand the process of the project with which the candidate is familiar (silver Bullet, waterfall, Agile…) , some artifacts in the process (such as: requirements documents, design documents, test files, etc.), and tools used in the development process (memory testing, code inspection, BUG reports, version maintenance, development debugging…) (For basic skills for programmers, see Basic Skills for Programmers.)

One could say that a candidate’s story can be made up by claiming he did something he didn’t do. Yes, that’s a possibility. Don’t forget, however, that a lie is often accompanied by more lies, so you don’t have to worry about this. As long as you refine the questions in the description, you will know if the candidate is making up a story.

Keep these points in mind:

• Speak in a casual and natural style, not formal.
• Don’t get too invested in what the candidate has done in the past. Because recruiters are technical people, sometimes recruiters themselves are attracted to the technology in a candidate’s project.
• Pay attention to guide the candidates. Believe me, eight out of ten programmers who apply can’t explain what they did before. Because they skip right through the project context and what kind of problem to solve and go straight to the implementation.
• Don’t ask a question and answer, you should let the applicant talk more, so that you can know more about a person in all aspects.
• Understanding a person’s past, understanding a person’s done, is more important than what they can do.
• Understanding a person’s character, thoughts, thinking and behavior is more important than understanding their technical skills.
• Communication ability, expression ability, language organization ability, understanding ability, and other aspects of the ability to work with others.
• The basics are much more important than the drops of knowledge. You may not know all the C++ keywords, but you should be aware of C++ inheritance and polymorphism.
• Technical skills are important, of course, but more important than that is one’s ability to acquire knowledge, which is a must in an industry as rapidly changing as computing.
• Whether it can be cultivated is more important than the skills it has mastered.

Iv. Actual participation? This step may be difficult to implement. Because, this needs some applicants to pay a certain amount of time, if it is a graduate, that is no problem, let him come to the internship for a period of time. But if someone else has a job, it’s not good. That’s what probation is for, you might say. But, personally, I think you have to respect the candidate, they leave the job, come to you, three months on probation, if there is no principle problem, you as a recruiter back out, it is very bad. If this happens, it can only be the employer’s fault.

During the interview, some interviewer will let the candidates will play a game together, or have a debate competition, or the group a team to do a simple things, or even to please a day off to their own in the company to work with your team one day, and to accomplish a thing (or even to its setting, deadline), And through these to consider the applicant’s actual ability to participate.

Yes, it’s hard to get to know someone in a few hours of interviews without working together, without something real happening. There’s nothing wrong with setting up these interview sessions to learn everything about a candidate in as little time as possible. And sometimes you can get good results. Here, I just want to mention that sometimes the cycle is so long that the candidates have to pay a lot, which in turn can make the candidates feel disgusted and bored. In a sense, it is really disrespectful to the candidates.

I have always doubted this point, so I put two question marks after it. To be honest, my personal opinion about actually participating in the process is that enough is enough, because the time is so short that no matter what you do you will never get the full picture. If not, get what you need most, which is the three questions at the beginning of this article and the “third point” mentioned above.

(Full text)

Author: increasingly, blog: https://coolshell.cn/articles/18190.html