Programmer interviewing has been a popular topic for community discussion

　　 I own since 2006 internships, has gone through four software companies, all foreign companies, including Fortune 500 communications company, engaged in futures options trading in Europe medium-sized financial companies, but also promising major car manufacturers to develop Android Emerging companies in smart cars . Since entering the IT industry , I have been interviewed for many times during the job search process. In the past two years, I have also had many interviews with other people's experiences. I feel now to express my views on this issue, this article is I stand in the interviewer point of view for a programmer interview questions and a summary of the lessons learned.

aims

I believe many friends, like, with a few years of work experience to become Senior began interviewing others experience. In the first phase of this interview, I just "found a good programmer", "I found a programmer with good algorithmic ability" and "I found a programmer with Android development experience" according to my own imagination. However, the actual experience tells me that in particular, people who are recruited on the basis of the goals of "basic good" and "good arithmetic" do not work well in the end. For example, some interviewees have a good knowledge of basic knowledge and algorithms, clear concepts of processes, threads, and memories. Basic data structures and algorithms such as Hash, binary tree, and quick sorting are also familiar, but when they enter a company, they perform in actual work very bad. Later, I realized that it was a problem with my interview goal. My original interview method was more like a university algorithm or an OS final exam. In this way, many unfit people passed the interview and possibly Missed many suitable people.

Later, my reflection was that from the company's point of view, the fundamental purpose of the interview was to find someone who "could do a good job," while "highly educated," "good at algorithms," "fundamentally good," and "experienced." It is appearance rather than foundation, and they can not be directly equated with "good work".

method

The goal is clear, but the question then is to assume that the interviewer is a black-box system and that "good work" is not a direct observable variable. The variables you can directly observe are basic, algorithmic, empirical, academic, personality, and many more. So, in fact, you can only guess the probability of "good work" from the amount that can be directly observed, such as "good foundation" and "good algorithm," which is a conditional probability of "working well" under "X good" Question: P (Good job | X good).

According to this model, what aspects of the interview should be investigated is obvious, that is to choose the most discriminating aspects to examine. For example, looking at the size and shape of the interviewer does not make much sense because the probabilities of P (work well | high), P (work good | short), P (work good | fat), P (work good | lean) Therefore, body characteristics are not distinguishable, this is not the interview should be concerned about.

The interviewer should make it clear which factors have a good distinction based on the job requirements. For example, if you want to recruit a 3D game engine development engineer with a high technical threshold, interviewer A has 3D game engine development experience, but performs generally in terms of basic knowledge and algorithm interviewing; interviewer B in contrast, basic knowledge and algorithm interviewing Good performance, but no game development experience, and you can only choose one. In fact, this is the two conditional probability problems P (work well, good experience, basic, general algorithm) and P (work well, no experience, good foundation, good algorithm). This question is left to the interviewer to judge. Personally, I personally prefer interviewer A to a position that requires technical accumulation with a high threshold of technology. Experience is more indicative of the problem.

Next, I will combine my own experience to talk about the common view of the interview.

algorithm

The algorithm is the focus of an interview with big companies such as Google and MS. I personally like the algorithm, I have participated in the ACM / ICPC held in Beijing Division 13. However, as a personal experience, the vast majority of development positions I have worked with are not suitable algorithms as a major factor in examining the pros and cons of interviewers. For ordinary non-algorithmic development positions, examining the interviewer's algorithm is equivalent to examining his ability to play ping-pong, and his relevance to the goal of "working well" is too low. In my personal experience, almost P (Good job | Good algorithm) = 50%, that is, there is not much difference in algorithmic interview.

There is even one very bad situation that particularly appearing on the algorithm's good interviewer, which I call "sharpening only, not chopping wood." What does it mean? There are people interested only in what A * algorithm, asynchronous programming, JVM class loading mechanism pure technical issues, no interest in the realization of user needs. Such people seem to have a certain technical capacity, but the contribution to the company is very limited, not even as technical but serious and responsible person. So, once the interviewer algorithm is good, I pay special attention to inspection will be this "only sharpening, not cutting wood" people.

And while I personally do not know Google and MS, I'm skeptical about the interview strategy that places special emphasis on algorithmic capabilities. Even in such a world-class company, although the algorithm is important, it is conceivable that algorithm problems will not be the main bottleneck most of the time during project implementation, and will not be the main bottleneck that requires everyone Are the master of the algorithm. In fact, the real difficulty of most projects is not one or two algorithm bottlenecks, nor even a single point of technical bottlenecks, but systematic organization, coordination, design, development issues, a large number of seemingly not so technical content There are also many problems that can be overcome due to lack of information and not technical skills. A team best complementary advantages, some strong algorithm, some business analysis ability, someone good at back-end service, some people are good at front-end interface, it was smart, some people practical, this is the best. If you follow the "algorithm is good," a single standard selection, will certainly reject many outstanding talent.

basis

Basic interview refers to the interview such as the use of pointers, the concept of process threads and other basic knowledge of the interview, is very similar to the university final exam questions. I used to think that basic interviewing is very important, but I do not think so. The basis of the job is indeed important, but in the interview process, it must be distinguishable meaningless, that is to say P (good job | basic good) the probability of high, then examine the use of pointers, process threads to distinguish such The basic topic has its meaning. My practical experience is that basic interviews are not very distinguishable and, like algorithms, they are almost P (good job | basic good) = 50%. At the same time, the basic interview is the easiest preparation, Chinese people have long-term examination-oriented education experience, to prepare a few to play the pointer problem is too easy.

I have met such interviewer, his C language foundation and compilation, links and other principles have very good grasp, left a deep impression on me, I give the interview conclusion is: knowledge is not wide, only C Language, but the foundation is solid, it is recommended hiring. Later things proved that the first half of that conclusion was correct, but "hiring" was wrong. He did a mess in his practical work, did not understand the needs, did not understand the overall architecture; the same time, working hours are not spent on the project, but spent on reading such as "programmers self-cultivation" books. Finally, the colleague left the company for a long period of "not living".

Basis is not insignificant, but "good foundation" is not enough to show that the interviewer can do a good job, because the foundation is part of the knowledge, and the actual work needs comprehensive ability, both differ greatly. C language, the operating system can test high scores, but people who do not write programs in the University we see less? Software development is like building a house, the overall ability to design and take the skeleton, the basics is code brick. Zhang Xiaolong original Foxmail is Delphi development, he does not understand C #, if you want to recruit a person who developed .NET Email client, you examine his grasp of the CLR well is not meaningful? Let Zhang Xiaolong to develop a C # version of Foxmail really Will you recruit a person who is proficient in C #, but no email client development experience to really fly more than Zhang Xiaolong it?

I say basic knowledge is not important, and the ancients said that "no bumpy step even to the distance" is not a contradiction? Not contradictory! "Wa Wa" and "Trinidad" is a cumulative relationship, but more "basic knowledge "Are not cumulative" comprehensive ability. " Learning software development should be like continuous integration. The beginning is a complete system. Although small in size and many in problems, its sparrows are small and complete, ranging from small systems to large systems and from simple systems to complex systems.

Therefore, the basic good itself is not enough to illustrate too many problems, we must further study comprehensive ability. Interviewers who do not perform well in basic interviews should further investigate if time permits. Some interviews are in fact capable, but not fully prepared. Of course, the best situation is the foundation and comprehensive ability is superb, if you can not take into account the comprehensive ability should be given priority.

experience

The experience here is not measured by how many years of work it has taken, but mainly by the interviewer's experience, for example, whether a software is completely implemented or completed as a major developer. The importance of experience is that it shows one's ability to synthesize. According to the nature, scale and difficulty of the project, the interviewer can roughly determine the interviewer's comprehensive ability. If an interviewer has been in charge of the development and maintenance of a small module in a large company, the basic judgment that he does not have the ability to undertake a project independently or as a major developer is only suitable for doing something similar in another large company. Relevant experience is even more important for jobs with higher thresholds that require long-term technology accumulation, such as Linux kernel development, JVM development, game engine development, database implementation, advanced UX, and more. For such positions, inexperienced interviewers, even with good overall qualifications, also need long hours of study and accumulation to be competent. So, basically, if you determine that your position falls into this category, then the relevant experience is undoubtedly the preferred factor, in other words, the probability of P (good job | good experience) is very high.

Through the project experience to determine the pros and cons of interviewers than basic and algorithmic testing more reliable, so the interview process interviewers should spend more time to listen to interviewers to introduce project experience and conduct in-depth exchanges to understand the interviewer's Knowledge, thinking ability, expression skills and so on. At the same time, you can combine the project to raise some basic knowledge and algorithm issues, for example, if the interviewer has done C + + related projects, then you can ask him how to carry out memory management? Are you familiar with the smart pointer? If the interviewer's answer is not satisfactory , Then basically you can judge his project did not do well.

It should be noted that experience is also a multidimensional thing. For example, C ++ stock trading middleware system, which involves (C + +, middleware, stock) three dimensions. If interviewer A has done a C ++ stock trading client, interviewer B has done C stock trading middleware. From the linguistic point of view, A is the best match, B is the best match from the nature of the project, and how do you choose? This is one of the more important dimensions in which dimensions. For this example, I personally prefer B, Because I think the middleware development experience is the main contradiction, and switching from C to C + + is not a problem. Therefore, the interviewer needs to decide which experience is the primary and which experience is the secondary. For example, we recruit Android application development, the position of the Android technology threshold is not high, its real difficulty is to make a good user experience (UX). So, if an interviewer does not have Android experience we are acceptable, but I hope he has UX experience, at least done on other platforms mobile application development.

character

Now, let me talk about the most important factor I think: character. This may be unimaginable for many first-time as an interviewer's friends, how can it be the most important personality? To be honest, when I realized this, I am also very surprised! To put it plainly, or P (Good Job | Personality Good) the highest probability ah. My practical experience is that if a person's personality is good, he can do the job with the highest possibility. His character is far better than the foundation and the algorithm is good.

If a person is technically flawed, inexperienced, but good personality, the team is very easy to make up for other people, he himself can easily gradually complement; the contrary, if a person's personality is not good, All the advantages of technology experience can not play out, or even play a negative role, and the character shortcoming is difficult to change. I have always said that what is needed for practical work is a comprehensive ability that plays a crucial role in playing character. Projects not only encounter technical problems, to involve communication, coordination, different people in different departments have both cooperation and friction, how to deal with these things need a good character. It can be said that in the development team to make you different is not from which school you graduate, nor is your past experience, but your character.

Of course, personality is a complex thing, it contains a lot of aspects, not all aspects of the programmer interview needs attention. My experience is to focus on these aspects:

1) Attitude is positive or negative. It is not hard to tell that some interviewers naturally give you a positive feeling in conversation or you can find positive elements in his experience. On the contrary, some interviewers can clearly feel his negative emotions. Enthusiasm is very important in the work, the positive person can bring vitality to the team, but also easier to cooperate. Basically, if the interviewer is determined to be positive, his chances of passing through me will be greatly increased. On the contrary, I will be very cautious if it is determined that the attitude is negative and the technical skills are good.

2) IQ. My experience is that, overall, smart people perform better at work. In an interview to examine whether a person is smart and not necessarily like Google and MS to find some IQ test IQ, in fact, you only need to see him discuss the problem is not very logical, thinking and speaking is not quick reaction You can make a rough judgment. In addition, the eyes are the windows of the soul, a person smart or not, the eyes can speak. However, smart is not entirely a merit. For example, when a company or project encounters difficulties, it often happens that smart people run away first and tend to be IQ-bound.

3) language skills. Language skills are also very important programmers a quality, it is related to the smooth communication in the project. The interviewer can see if the interviewer can explain clearly what has been done in a concise language, whether they can grasp the key points, and whether they can take into account the relevant background of the listener. In general, people with strong language skills are not poorly integrated.

4) Is user-conscious? Some people say that programmers are doing research and development, where to what users? Only sales, marketing staff and users will deal with. In fact, this is a complete misunderstanding. You write a module, or even an API, as long as someone else, he is your user. Some programmers to design a module or a software is always used to consider from the user's point of view, as far as possible to facilitate the user, this is a good sense of the user. People who have a good sense of the user can think more about the feelings of others and the needs of the whole, rather than simply thinking about the problem from themselves and from the parts. When the interviewer talks about past project experience, the interviewer can often question him or her from the perspective of the user and observe whether or not the interviewer has good user awareness.

5) how to deal with questions and pressure. The interviewer should reasonably question the interviewer's response and past projects to see how he coped. There was an interviewer who spoke about the experience of logging in to the server as a game. I asked: "If the login server is hung up, what should I do?" He said that although this issue was not considered, how can we improve it? Actually, everybody understands that there are various imperfections in the project. There are many reasons for this. There are many reasons for this. As long as we can confidently confront the challenges and pressures in a good direction, we should do our best to solve them. There is no need to cover up the flaws, let alone the emotions. I met some interviewers, once you questioned his project, he immediately rebelled, or unhappy, or do not recognize a problem, it is easy to see that he can not be questioned in the work and criticism, Such people want to cooperate is very difficult.

6) personality characteristics. Many interviewees like to write "proficient in C ++ / Linux" on resumes. These words are numb. If anyone writes "like C ++ / Linux," I will have a glimpse of what's going on. "Proficient" is not emotional description, and "like" includes the personality of the interviewer, I prefer to see the personality of the interviewer. I believe that the true passion for something is far more important than your current mastery of it. In fact, N years of experience tells us that students in the same class and colleagues in the same project group have the same knowledge of and work in contact with each other. However, the difference in achievement and performance of each person is very clear of. So, in the end what is the difference between the essence? In fact, that is, everyone's personality. Personality makes some people spare time to play, some people spare time to read books, some people like Linux, some people like Mac. A person's role in the team also has a great relationship with his personality. The interviewer should guide the interviewer to show their personality and judge whether it is beneficial to the team.

to sum up

To sum up, my experience is: 1) The interviewer's goal is to find "good people", we must conduct interviews around this goal, if the interview as the algorithm or the operating system final exam which went wrong ; 2) the interview process is through the qualifications, personality, foundation, experience, algorithms and other testable factors to comprehensively determine the probability of the interviewer "work well"; 3) Among various factors, the character> experience> basic> algorithm. Character is the most important, if the character is not good, all the technical ability will be greatly reduced, and the technical defects easy to make up, personality defects is difficult to change; experience reflects a person's comprehensive ability, you can judge from the interviewer's past experience What kind of work can be engaged in, what kind of work can not be engaged; Fundamentals and algorithms are mainly played a supporting reference role, based on the good general adaptability of programmers, learn new technology faster, but should not simply judge a person from the foundation Ability.