Reprinted by Mr Chen Hao and talked about "How do I recruit programmers?" (I)

Author's original blog address: http://coolshell.cn/articles/4506.html

I have previously written an article "How do I recruit programmers?" (many people have replied to this article on csdn ). Today, I want to talk about recruitment and interview for the following reasons:

· I have been engaged in a lot of recruitment work for nearly half a year and have some new experiences in the interview.

· Cool shell recently published several interesting interview questions (interview question 1, interview question 2, and interview question 3), which gave me some thoughts from the reply.

· One of my colleagues recently interviewed a company. He shared his interview with a doctoral expert and gave me some thoughts.

· On Douban, I saw "zhihu's experience of someone writing an interview with Douban's product manager is a pleasure" (the highlight is that the interviewer appeared to know and answered in person)

So I want to write down my new ideas again. As before, this article is also for the interviewer. In my opinion, the quality of the interview lies in the interviewer rather than the interviewer. The following are some of my enhanced views on how I recruit programmers. (For some comments, please refer to the next article)

In order to ensure the continuity of my article, let me reiterate the important points mentioned above.

· Only the real and natural performance of the applicant can learn the most authentic things.

· What matters is not knowledge, but the ability to search for knowledge.

· What is important is not the answer to the problem, but the ideas and methods for solving the problem.

Operation, knowledge, experience, and capability

We have a lot of interviewers who seem to be confused about what is operational ability, what is knowledge, what is experience, what is ability, which leads our interviewers to often mistakenly draw conclusions on the subject, I don't think anyone who can tell the story is qualified to be an interviewer. Therefore, it is necessary for me to clarify this question first.

· Operation. Our interviewers cannot tell what operation skills are, what is knowledge, and what they even think operation skills are knowledge or even experience. For example, they will ask the following question: what does final in Java mean? How can I view the CPU usage of a process? How to compile an MPS queue? How can I view the program path of a process? What is the copy and paste command in VI? Including what is the object-oriented XX model. And so on. I thought that the operations manuals or google-related information can only describe the technical skills of this person, but not the knowledge or experience of this person.

· Knowledge. Knowledge is the embodiment of a person's cognition and learning. It may be some basic concepts and knowledge. For example, the advantages and disadvantages of TCP and UDP are compared, and the advantages and disadvantages of linked list and hash table are compared. What is heap? What is stack? How does one communicate with each other? What are the advantages and disadvantages of processes and threads? What are the advantages and disadvantages of synchronization and Asynchronization? What are the main principles of the object-oriented XX design model. I thought that "knowing what it is" is only an operating technology, and "knowing what it is" is a real knowledge. A lack of knowledge does not mean that he cannot work and can cope with his work only by operating skills. However, lack of knowledge will definitely limit your experience and abilities, and will also affect the quality of your development.

· Experience. Experience is usually related to one person's experience. The scope of a person's knowledge, the things that a person has experienced, usually become a manifestation of a person's experience. During the test, we will ask these questions: What are the most difficult problems you have solved? How did you design this system? How did you debug and test your program? How do you optimize performance? What kind of code is good code? And so on. For people who have not been working for a long time, experience and what they have done will indeed become the main factor in their experience, especially those with an industry background. However, I think that experience may be more about your use and control of knowledge. It is your reflection and summarization of what you have done, and your learning of others, observe and communicate.

· Capability. A person's ability is not capable of knowing little or having no experience. A person's ability is an attitude, character, idea, idea, behavior, method, and style of doing things. As long as you have enthusiasm, ideas, good behavior methods, and good behavior style, knowledge and experience are just a matter of time for him. For example: learning ability, professional research spirit, analysis ability, communication ability, organizational ability, problem investigation ability, cooperation ability, etc. Therefore, for a newbie, his knowledge and experience may be limited, but it does not mean that he has problems with his ability. But for a veteran, if he has problems with lack of knowledge and experience, it is usually a problem of its ability. You may not be lucky for the moment, but I don't believe you will be lucky for a long time. If so, you will inevitably have some problems that will make your capabilities unavailable. At this time, "No experience" is only an excuse for "no ability.

I do not deny that these four things are important to a good programmer. However, through the above analysis, we can know that capabilities, experience, and knowledge need to be treated separately. Of course, these things complement each other. Your abilities allow you to gain knowledge, your knowledge gives you more experience, and your experience changes your thoughts and ideas, to improve your capabilities. During the interview, we need to clearly understand that the applicant's operation skills, knowledge, and experience are only necessary for his or her ability, and they are not sufficient, we should focus more on the abilities of candidates.

· If the interview only tests the individual's operation skills, the interview will fail completely. This is an unqualified interviewer.

· If the interview is just about to examine the knowledge and experience of this person, the interview will be half successful. Because you understand basic knowledge and what you have done, it does not mean that you fully understand his true abilities.

· If you are able to focus on your abilities (attitudes, personalities, thoughts, ideas, behaviors, methods, and styles) when learning about your knowledge and experience ), if you can correctly assess your abilities, your interview will be very successful.

It may not be appropriate to use these four words to describe a set of things, but I believe you understand what I want to express.

Do not give a superficial understanding of algorithm questions and smart questions

Many companies will give some algorithm questions, some mental questions, or some design questions during the interview. I believe that algorithm questions or mental questions are the most annoying thing for programmers during the interview. Many people are very BS. The interviewer asks algorithm questions because they think these algorithm questions or smart questions are not used in actual work. However, I would like to say that there is nothing wrong with difficult questions about algorithms and wisdom. Many of the wrong interviewers simply understand the difficult questions in the interview with superficial or wrong purposes. They believe that the person who can make algorithm questions and smart questions is the smart person and the competent person. This idea is really superficial.

Actually, being able to solve a problem does not mean that this person is able to solve the problem at work. You can think about it. Primary school Mathematical Olympiad questions may be more difficult than these questions, but it does not mean that the Olympics experts have practical work capabilities. You may think that the students with high scores in your class are not necessarily smart or competent. On the contrary, this kind of person is often a nerd trained under exam-oriented education.

Therefore, I think the process of solving the problem is more important. You should mainly view the ideas, methods, and knowledge of the candidate through solving the problem. Do you have any experience, whether the interaction and communication with you are smooth, etc. These are the key points to be observed. Of course, the answer is eventually to be found.

I think the real idea for the interviewer to solve a problem is:

· Look at his knowledge application and understanding. For example, will he use some basic data structures and algorithms to solve algorithm problems?

· Let's take a look at his entire problem-solving ideas and ideas. The answer is secondary. his thoughts and actions are important.

· Let's see how he discussed it with you. Take the interviewer as your future colleague, take it as your work partner, solve the problem together, and discuss it together so that you can see if everyone can work together.

These aspects are the ability to examine candidates (ideas, methods, attitudes, personality, etc.), and take into account the experience and knowledge of the interviewees. Below are some interview points:

· Will candidates break down or simplify this problem when solving algorithm questions. This is the analysis capability.

· Will the applicant use basic knowledge, such as data structures and basic algorithms, when solving algorithm questions. This is knowledge.

· Do you feel the professional research spirit and good communication skills of the candidates during the discussion with you.

· The applicant's mentality and attitude towards this algorithm question. For example, whether there is fear in the interview.

· Is the candidate's ideas and methods suitable for solving problems? Is it a scientific method?

· And so on.

In the process of solving the problem, it is the ultimate goal to examine the candidate's abilities, rather than making it difficult for the candidate. Otherwise, you are just an arrogant and ignorant interviewer.

Simulate challenges and capabilities in practice

As an interviewer, you should think more about your work and your growth experience. This will be very helpful for your interview. What is the actual situation for you to solve the problem at work? What is the actual situation of your code writing? What is your growth experience? How do you acquire knowledge and abilities? Who do you like to work? I believe that it is not difficult for you to find that the actual situation in your work is exactly the same as the interview situation. How can you evaluate a person's abilities with an interview that is different from the actual situation?

Therefore, the ideal interview is to work together for a period of time. Of course, this is almost impossible in the recruitment process. Therefore, our interviewer is required to simulate the interview process as much as possible. We will discuss and solve a problem, review what he has done with the applicant, and discuss and learn from each other in the course of the Foundation. The following is an example.

We know that it is not difficult to develop software for software development. The following are the challenges:

1. the maintenance cost of the software is much higher than the development cost of the software.

2. the quality of software is becoming more and more important, so testing is becoming more and more important.

3. The demand for software is always changing, and the demand for software is always increasing at 1.1 points.

4. A large amount of code in the program is processing incorrect or abnormal processes.

So why can't we simulate this process when we examine the candidate's code capabilities? For example, it is very easy to implement a atoi () function for a candidate, and then add new requirements or cases continuously, such as processing symbols, processing Non-numeric letters, processing space, processing hexadecimal, processing binary, processing comma, etc. We need to see how the applicant modifies his code, how to Write test cases, how to refactor, and whether his code is still so easy to read and clear as more and more things are being processed. If you only want to examine the encoding capability, it is sufficient to ask this question when it is small. Real Programmers are dealing with such things every day.

If you want to examine the design capabilities of candidates, you can also do the same. Constantly add new capabilities and new demands. Let's take a look at the interviewer's ideas, ideas, analysis methods, and whether your discussions are smooth. If you don't say that you are at the point, your thoughts are unclear and what kind of knowledge will be applied, what is his experience in designing this system? Is his design still so good in the face of constant changes and increasingly complex requirements?

Of course, because the time is short, you cannot have too many complicated problems. This requires you to carefully design some representative problems.