What is the most important thing in a programmer interview?

Abstract: Programmer interviews have always been a hot topic in the community. Since my internship in 2006, I have worked in 4 software companies, all of which are foreign companies, including a Fortune 500 communications company, a medium-sized European financial company engaged in options and futures trading, and an Android developer for a large car manufacturer. Smart car startup.

Programmer interviews have always been a hot topic of discussion in the community. Since my internship in 2006, I have worked in 4 software companies, all of which are foreign companies, including a Fortune 500 communications company, a medium-sized European financial company engaged in options and futures trading, and an Android developer for a large car manufacturer. Smart car startup. Since entering the IT industry, I have experienced many interviews in the process of applying for a job, and I have also experienced many interviews with others in the past two years. I feel that it is time to express my views on this issue. This article is a staged reflection and experience summary of programmer interview questions from the perspective of the interviewer.

Goal I

believe that like many of my friends, I started the experience of interviewing others after becoming a senior with several years of work experience. At the initial stage, I just took "finding programmers with good basics", "finding programmers with excellent algorithm ability", and "finding programmers with Android development experience" as the interview goals according to my imagination. However, the actual experience tells me that people recruited by the goals of "good foundation" and "good algorithm" are not very effective in the end. For example, some interviewees have a good grasp of basic knowledge and algorithms, clear concepts such as process, thread, memory, etc., and are familiar with basic Hash, binary tree, quick sort and other data structures and algorithms, but after joining the company, they perform well in actual work. very bad. Later, I found out that it was my interview goal that went wrong. My original interview method was more like a university final exam on algorithms or operating systems. According to this method, many unsuitable people passed the interview, and at the same time, it was possible Missing a lot of the right people.

Later, my reflection was that, from the perspective of the company, the fundamental purpose of the interview is to find people who "can do a good job", while "highly educated", "good algorithm", "good foundation", and "experience" are all They are appearances rather than fundamentals, and they are not directly equated with "working well".

method

The goal is clear, but the next question is to assume that the interviewee is a black-box system. "Good job" is not a directly observable variable. The variables you can directly observe are basics, algorithms, experience, education, personality, conversation, age. etc. So, in fact, you can only infer the probability of "working well" from directly observable quantities such as "good foundation" and "good algorithm", which is a conditional probability of "working well" under the condition of "good X" Problem: P (works fine | X fine).

According to this model, it is obvious which aspects should be examined by the interviewer, that is to choose the most distinguishing aspect to examine. For example, it is not meaningful to examine the physical characteristics of the interviewee, because the probability of P (good job | tall), P (good job | short), P (good job | fat), and P (good job | thin) are similar; Therefore, body type characteristics are not discriminative, and this is not what the interview should focus on.

The interviewer should clarify which factors have better differentiation in combination with the requirements of the position. For example, if you want to recruit a 3D game engine development engineer with a relatively high technical threshold, Interviewer A has experience in 3D game engine development, but his performance in basic knowledge and algorithm interviews is average; Interviewer B, on the contrary, has basic knowledge and algorithm interviews. Performs well, but has no game development experience, and you can only choose one. Who do you choose? In fact, these are two conditional probability problems P (good work | good experience, general foundation, general algorithm) and P (good work | no experience, good foundation, good algorithm). This question is left to the interviewer to judge. As far as I am concerned, for positions with high technical thresholds that require technical accumulation, experience is more indicative of the problem. Therefore, I prefer Interviewer A.

Below, I will combine my own experience to talk about the common aspects of the interview.

algorithm

Algorithms are the focus of interviews at large companies such as Google and MS. I personally like algorithms very much. I once participated in the ACM/ICPC and won the 13th place in the Beijing division. However, in my personal experience, for the vast majority of development roles I've worked with, algorithms are not suitable as a primary factor in evaluating candidates. For ordinary non-algorithmic development positions, examining the candidate's algorithm is equivalent to examining whether he is good at table tennis, and the correlation with the goal of "good work" is too low. From my personal experience, it is almost P (good job | good algorithm) = 50%, that is, the algorithm interview does not have much distinction.

Even, there is a very bad situation that occurs in many interviewers with good algorithms. I call it "only sharpening knives, not chopping wood". What does that mean? Some people are only interested in pure technical issues such as A* algorithm, asynchronous programming, and JVM class loading mechanism, and have no interest in implementing user requirements. Such people seem to have certain technical abilities, but their contribution to the company is very limited, and they are not even as skilled but serious and responsible. Therefore, once I encounter an interviewee with a good algorithm, I will pay special attention to whether it will be such a person who "only sharpens knives and does not chop wood".

Also, although I don't know Google and MS personally, I'm skeptical of their interview strategy that places a special emphasis on examining algorithmic abilities. Even in such a world-class company, although the algorithm is important, it is conceivable that in the various problems encountered in the project implementation process, the algorithm problem will not be the main bottleneck most of the time. It's all about algorithm experts. In fact, the real difficulty of most projects is not one or two algorithm bottlenecks, or even single-point technical bottlenecks, but systemic organization, coordination, design, and development issues. There are many problems due to the lack of information, and it is not the technical ability that can overcome these difficulties. It is best for a team to complement each other's strengths. Some people have strong algorithms, some people have strong business analysis capabilities, some people are good at back-end services, some people are good at front-end interfaces, some people are smart, and some people are down-to-earth. This is the best. If you select materials according to the single standard of "good algorithm", many excellent talents will be rejected.

Base

Fundamental interviews are interviews that examine basics such as pointer usage, process threading concepts, etc., much like final college exam questions. I used to think basic interviews were important, but I don't see it that way anymore. The foundation is indeed important in the work, but in the interview process, it must be differentiated to make sense, that is to say, the probability of P (good work | good foundation) is high, then the use of pointers and the difference between process threads are examined. The basic topic has its meaning. My practical experience is that basic interviews are not very discriminative, like algorithms, almost P(good job|good foundation) = 50%. At the same time, the basic interview is the easiest to prepare. The Chinese have long-term experience in exam-oriented education, and it is too easy to prepare a few pointer questions.

I have met such an interviewer. He has mastered the basics of C language and the principles of compiling and linking very well, which left a deep impression on me. The interview conclusion I gave was: the knowledge is not broad, and only C Language, but the foundation is very solid, it is recommended to accept. Subsequent events proved that the first half of that conclusion was right, but the "recommended hire" was wrong. He is a mess in actual work, does not understand the requirements, and does not understand the overall architecture; at the same time, his work time is not spent on projects, but on reading books such as "Programmer's Self-Cultivation". In the end, the colleague left the company due to "no work" for a long time.

The foundation is not unimportant, but "good foundation" is not enough to indicate that the interviewee can do a good job, because the foundation is local knowledge, while the actual work requires comprehensive ability, the two are worlds apart. C language and operating system can get high scores, but do we still see few people in college who can't write programs? Software development is like building a house. The comprehensive ability is to design and build the skeleton, and the basic knowledge is to code bricks. Zhang Xiaolong originally developed Foxmail in Delphi. He doesn't understand C#. If you want to recruit a person who develops .NET Email client, does it make sense for you to check whether he has a good grasp of CLR? Is it really difficult to let Zhang Xiaolong develop a C# version of Foxmail? Is it really more reliable than Zhang Xiaolong to hire someone who is proficient in C# but has no experience in Email client development?

When I say basic knowledge is not important, is it a contradiction to Lao Tzu's saying, "If you don't accumulate a hole, you can't go a thousand miles"? Not contradictory! "Wabu" and "Thousand Miles" are an accumulative relationship, but no amount of "basic knowledge" can add up to "comprehensive ability". Learning software development is like continuous integration. It is a complete system from the beginning. Although it is small in scale and has many problems, it is small and complete, and it gradually evolves from a small system to a large system, from a simple system to a complex system.

Therefore, a good foundation itself is not enough to explain too many problems, and the comprehensive ability must be further investigated. For interviewers who did not perform well in the basic interview, further investigation should be conducted if time permits. Some interviewers are actually competent, but they have not been fully prepared. The most ideal state is of course good foundation and comprehensive ability. If it cannot be taken into account, comprehensive ability should be given priority.

Experience The experience mentioned

here is not measured by how many years of work, but mainly refers to the experience of the interviewer, for example, whether a software has been fully implemented, or a project has been completed as the main developer. The importance of experience is that it speaks to a person's combined abilities. From the nature, scale and difficulty of the project, the interviewer can roughly judge the overall ability of the interviewee. If an interviewee has been responsible for the development and maintenance of a small module in a large company, it can basically be judged that he does not have the ability to undertake a project independently or as a main developer, and is only suitable for doing similar things in another large company. For positions with high thresholds that require long-term technical accumulation, relevant experience is particularly important, such as Linux kernel development, JVM development, game engine development, database implementation, advanced UX, etc. For this type of position, even if the overall quality of the inexperienced interviewee is good, it will take a long time to study and accumulate to be competent. So, basically if it is determined that your position falls into this category, then the relevant experience should undoubtedly be the preferred factor, in other words, the probability of P (good job | good relevant experience) is very high.

It is more reliable to judge the quality of an interviewee through project experience than through basic and algorithm tests. Therefore, during the interview process, the interviewer should spend more time listening to the interviewer's introduction of project experience, and conduct in-depth discussions and exchanges to understand the interviewer's experience. Knowledge, thinking ability, expression ability, etc. At the same time, you can ask some basic knowledge and algorithm questions in combination with the project. For example, if the interviewee has done C++ related projects, you can ask him how to manage memory? Are you familiar with smart pointers? If the interviewee's answer is unsatisfactory, then basically he can judge that his project is not very good.

It is important to note that experience is also a multidimensional thing. For example, the C++ stock trading middleware system involves three dimensions (C++, middleware, stock). Suppose interviewer A has worked as a C++ stock trading client, and interviewer B has worked as C's stock trading middleware. From the perspective of language, A is the best match, and from the nature of the project, B is the best match, how do you choose? This is the question of which dimension is more important among the multiple dimensions. For this example, I personally prefer B, because I think middleware development experience is the main contradiction, and switching from C to C++ is not a problem. So, the interviewer needs to decide which experience is primary and which is secondary. For example, we recruit Android application development. The Android technical threshold for this position is not high. The real difficulty lies in making a good user experience (UX). So, if an interviewee has no experience with Android we can accept it, but I would expect him to have experience in UX, at least mobile app development for other platforms.

Character

Now , I come to what I think is the most important factor: character. This may be unimaginable for many friends who are interviewers for the first time. How can character be the most important thing? To be honest, I was surprised myself when I realized this! To put it bluntly, the probability of P (good work | good character) is the highest. My actual experience is that if a person has a good character, he has the highest possibility of doing a good job. A good character is far more reliable than a good foundation and a good algorithm.

If a person is technically flawed and lacks in experience, but has a good character, he can easily be filled by others in the team, and he can easily make up for it gradually; on the contrary, if a person has a bad character, All technical advantages and experience advantages cannot be brought into play, and even have a negative effect, and character shortcomings are difficult to change. I have always talked about the need for comprehensive ability in practical work, and the ability to play this comprehensive ability is crucial. There are not only technical problems in the project, but also communication and coordination. Different people and different departments have both cooperation and friction. How to deal with these things requires a good character. Arguably, what sets you apart on a development team is not which school you graduated from or your past experience, but your personality.

Of course, personality is a complex thing, and it contains many facets, not all of which are what programmer interviews need to focus on. My experience is to focus on these aspects:

1) Positive or negative attitude. Some interviewers will naturally give you a positive feeling in the conversation, or you can find his positive factors in his experience, these are not too difficult to see. On the contrary, some interviewers can clearly feel his negativity. Positivity is very important at work. Positive people can bring vitality to the team and make it easier to cooperate. Basically, if the interviewer is determined to have a positive attitude, the probability of him passing my level will be greatly increased; on the contrary, if it is determined to be a negative attitude, I will be very cautious even if the technical ability is good.

2) IQ. My experience is that, overall, smarter people perform better at work. To test whether a person is smart in an interview, it is not necessary to find some IQ-specific puzzles like Google and MS. In fact, you only need to see whether he is very logical in discussing questions, and whether he is quick in thinking and speaking. A rough judgment can be made. In addition, the eyes are the windows to the human soul. Whether a person is smart or not, the eyes can speak. However, being smart is not entirely an advantage. For example, when a company or project encounters difficulties, it is often the smart people who run away first, and those with average IQ who stick to it.

3) language skills. Language expression ability is also a very important quality for programmers, which is related to whether the communication in the project is smooth. The interviewer can see if the interviewee can explain the projects he has done clearly in concise language, whether he can grasp the main points, and whether he can take into account the relevant background of the listener. Generally speaking, the comprehensive ability of people with strong language expression ability is not too bad.

4) Whether it has user awareness. Some people say that programmers do research and development, where do users come from? Only sales and marketing personnel will deal with users. In fact, this is a complete misunderstanding. You write a module, or even an API, as long as someone else uses it, he is your user. Some programmers design a module or a piece of software and are always accustomed to considering it from the user's point of view, and try to make it as convenient for the user as possible, which is a good user awareness. People with good user awareness are more able to consider the feelings of others and the needs of the whole, rather than simply thinking about problems from their own and local perspectives. When interviewers talk about past project experience, interviewers can often ask questions from the user's point of view, and observe whether they have a good user awareness in the process.

5) How to deal with doubt and pressure. The interviewer should ask reasonable questions about the interviewee's responses and past projects to see how he responds. Once an interviewee talked about the experience of being a game login server, I asked: "What should I do if the login server hangs up"? He said that although this problem was not considered at the beginning, how can it be improved. In fact, everyone understands that there are various imperfections in the project. There are many reasons for this. As long as you can calmly deal with doubts and pressures and work hard to think and solve them in a positive direction, you don’t need to cover up your defects, and you shouldn’t have emotions. I have encountered some interviewers, once you question their project, he immediately becomes rebellious, or is unhappy, or does not admit that there is a problem. It is very difficult for such people to cooperate.

6) Personality characteristics. Many interviewers like to write "Proficient in C++/Linux" on their resume. These words are numbing. If someone writes "Like C++/Linux", I will have a bright feeling. "Mastery" is an emotionless narrative, while "like" contains the personality of the interviewer, which I prefer to see. I believe true passion for something is far more important than your current level of mastery of it. In fact, N years of experience tells us that students in the same class and colleagues in the same project team, although the knowledge they learn and the jobs they are exposed to are the same every day, but in fact the differences in performance and performance of each person are very obvious. of. So, what is the essential difference? In fact, it is everyone's personality. It's personality that makes some people play ball in their spare time, some people read books in their spare time, some people like Linux, and some people like Mac. The role a person plays in a team also has a lot to do with his personality. The interviewer should guide the interviewee to show his personality and judge whether it will benefit the team.

Summary In

the end , my experience is: 1) The interviewer's goal is to find a "good job" person, and the interview must be conducted around this goal. If the interview is regarded as the final exam of an algorithm or an operating system, this is the way to go. Misunderstanding; 2) The interview process is to comprehensively judge the probability of an interviewee's "good job" through factors that can be tested such as education, personality, foundation, experience, and algorithm; 3) Among various factors, personality > experience > foundation > algorithm. Personality is the most important thing. If you have a bad personality, all technical abilities will be greatly reduced, and technical defects are easy to make up for, and character defects are difficult to change; experience reflects a person's comprehensive ability, and you can judge him from the interviewer's past experience What kind of work can be done and what kind of work can’t be done; the basics and algorithms mainly play the role of auxiliary reference, programmers with good basics are generally more adaptable and learn new technologies faster, but don’t judge a person simply from the basics Ability.