IT interview experience: What is the most important for programmers to interview?

Programmer interview has always been a hot topic in the community. Since my internship in 2006, I have experienced four software companies, all of which are foreign companies, including communication companies in the world's top 500 companies, European medium-sized financial companies engaged in options futures trading, and emerging companies developing Android smart cars for large automobile manufacturers. Since I entered the IT industry, I have experienced many interviews in the process of finding a job, and I have also experienced many interviews with others in the last two years. I think it's time for me to express my views on this issue. This paper is a phased reflection and experience summary from the interviewer's point of view.

target

I believe that, like many friends, after several years of work experience, I began to interview others. At this initial stage, I just take "finding a programmer with a good foundation", "finding a programmer with excellent algorithm ability" and "finding a programmer with Android development experience" as my interview objectives. However, practical experience tells me that especially those who recruit according to the goal of "good foundation" and "good algorithm" will not have good results in the end. For example, some interviewers have a good grasp of basic knowledge and algorithms, with clear concepts such as process, thread and memory, and are familiar with basic data structures and algorithms such as hash, binary tree and quick sorting, but they have performed poorly in practical work after entering the company. Later, I found out that there was something wrong with my interview goal. My original interview method was more like the final exam of university algorithm or operating system. According to this method, many unsuitable people pass the interview, and at the same time, they may miss many suitable people.

Later, my reflection was that from the company's point of view, the fundamental purpose of interview is to find people who can do a good job, and "high education", "good algorithm", "good foundation" and "rich experience" are all appearances rather than fundamentals and cannot be directly equated with "good job".

way

The goal is clear, but the next question is to assume that the interviewer is a black box system and "good job" is not a directly observable variable. The variables you can directly observe are foundation, algorithm, experience, education, personality, speech, age and so on. Therefore, in fact, you can only infer the probability of "working well" from directly observable quantities such as "good foundation" and "good algorithm". This is a conditional probability problem of "working well" under the condition of "good X": P (working well | good X).

According to this model, which aspects should be investigated in the interview are obvious, that is, the most distinctive aspects should be selected for investigation. For example, it doesn't make much sense to examine the physical characteristics of the interviewer, because the probability of P (good job | high), P (good job | short), P (good job | fat) and P (good job | thin) is similar; Therefore, physical characteristics are inseparable, which is not something to pay attention to in the interview.

The interviewer should make clear which factors are better to distinguish according to 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 interview is average; Interviewer B, on the other hand, did a good job in basic knowledge and algorithm interview, but you have no experience in game development, so you can only choose one of them. Who do you choose? In fact, these are two conditional probability problems P (good job | good experience, average foundation and average algorithm) and P (good job | no experience, good foundation and good algorithm). This question is left to the interviewer to judge for himself. Personally, I think that experience is more telling for positions with high technical threshold and technical accumulation, so I prefer interviewer A.

Below, I will talk about several common aspects of interview based on my own experience.

algorithm

Algorithms are the focus of interviews in big companies such as Google and Microsoft .. I personally like algorithms. I have participated in ACM/ICPC, Beijing Division 13. But from my personal experience, for most of the development positions I have contacted, the algorithm is not suitable as the main factor to examine the pros and cons of interviewers. For ordinary non-algorithmic development positions, examining the interviewer's algorithm is equivalent to examining whether he plays table tennis well or not, and the correlation with the goal of "working well" is too low. As far as my personal experience is concerned, almost P (good job | good algorithm) =50%, which means there is not much discrimination in algorithm interview.

Even, there is a very bad situation, especially for interviewers with good algorithms. I call it "a woodcutter who sharpens his knife without mistake." What do you mean? Some people are only interested in pure technical issues such as A* algorithm, asynchronous programming, JVM class loading mechanism, and have no interest in realizing user needs. Such people seem to have certain technical ability, but their contribution to the company is very limited, even worse than those who are generally skilled but serious and responsible. So once the interviewer has a good algorithm, I will pay special attention to whether it is such a person who only sharpens the knife and does not cut wood.

In addition, although I don't know Google and MS personally, I am skeptical about their interview strategies that pay special attention to algorithmic ability. Even in such a world-class company, although the algorithm is important, it is conceivable that among all kinds of problems encountered in the project implementation process, the algorithm problem will not be the main bottleneck most of the time, and there is no need for everyone to be an algorithm expert. In fact, the real difficulty of most projects is not one or two algorithm bottlenecks, or even a single technical bottleneck, but a system organization, coordination, design and development. There are a lot of dirty jobs that don't look so technical, and many problems are due to lack of information and strong technical ability can't be overcome. It is best for a team to complement each other. Some people have strong algorithms and business analysis skills, some are good at back-end services, some are good at front-end interfaces, some are smart, and some are practical. This is the best. If materials are selected according to the single standard of "good algorithm", many excellent talents will be rejected.

basis

Basic interview refers to an interview that examines the basic knowledge such as the use of pointers and the concept of process threads, which is very similar to the final exam questions in universities. I used to think that the basic interview was very important, but now I don't think so. Foundation is really important in the work, but in the interview process, it is meaningful to distinguish, that is to say, the probability of P (good job | good foundation) is high, so it is meaningful to investigate basic topics such as pointer use and process thread distinction. My practical experience is that there is no good distinction between basic interviews. Like the algorithm, it is almost p (good job | good foundation) = 50%. At the same time, the basic interview is also the easiest to prepare. China people have long-term experience in exam-oriented education, so it is too easy to prepare a few tricky questions.

I once met such an interviewer, and he mastered the basics of C language and the principle of compiling and linking very well, which left a deep impression on me. The interview conclusion I gave is: I only know C language, but I have a solid foundation and recommend employment. Later events proved that the first half of that conclusion was correct, but "suggested employment" was wrong. He is a mess in his practical work, and he doesn't understand the requirements and the overall architecture. At the same time, work time is not spent on projects, but reading books such as "Self-cultivation of Programmers". Finally, this colleague left the company because he had no job for a long time.

The foundation is not unimportant, but "good foundation" is not enough to show that the interviewer can do well, because the foundation belongs to local knowledge and the actual work needs comprehensive ability, which is very different. Both C language and operating system can get high marks, but do we still see few people who can't write programs in universities? Software development is like building a house. The comprehensive ability is to design and build a skeleton, and the basic knowledge is to build bricks. Zhang Xiaolong originally developed Foxmail with Delphi, but he didn't understand C#. If you want to recruit someone to develop a. NET mail client, is it meaningful to see if he has a good command of the CLR? Is it really difficult for Zhang Xiaolong to develop a C# version of Foxmail? Is it really more reliable for you to recruit someone who is proficient in C# but has no experience in developing email clients than Zhang Xiaolong?

I said that basic knowledge is not important, and the ancients said, "You can't travel thousands of miles without accumulating a depression." Is this a contradiction? No contradiction! "Bubu" and "Li Qian" are cumulative, but no amount of "basic knowledge" can add "comprehensive ability". Learning software development, like continuous integration, is a complete system from the beginning. Although the scale is small and there are many problems, it has developed from a small system to a large system and from a simple system to a complex system.

Therefore, a good foundation itself is not enough to explain too many problems, and we need to further examine the comprehensive ability. For those who do not perform well in the basic interview, if time permits, further investigation is needed. Some interviewers are actually capable, but they are not fully prepared. The most ideal state is of course a good foundation and strong comprehensive ability. If you can't give consideration to both, comprehensive ability is preferred.

experience

The experience mentioned here is not measured by how many years of work, but mainly refers to the interviewer's experience, such as whether he has fully implemented a software or completed a project as the main developer. The importance of experience lies in that it can explain a person's comprehensive ability. From the nature, scale and difficulty of the project, the interviewer can roughly judge the interviewer's comprehensive ability. If an interviewer has been responsible for the development and maintenance of a small module in a big 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 big company. Relevant experience is particularly important for posts with high threshold and long-term technical accumulation, such as Linux kernel development, JVM development, game engine development, database implementation, advanced ux and so on. For this kind of position, inexperienced interviewers need long-term study and accumulation to be competent, even if their comprehensive quality is good. So basically, if you are sure that your position belongs to this category, then relevant experience should undoubtedly be the first choice. In other words, the probability of P (good job | good relevant experience) is very high.

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

It should be noted that experience is also a multidimensional thing. For example, the C++ stock trading middleware system involves three dimensions: (C++, middleware, stock). If interviewer A has been a C++ stock trading client and interviewer B has been a C stock trading middleware. From the language point of view, A is the best collocation, and from the nature of the project, B is the best collocation. How do you choose? This is the question of which dimension is more important. As far as this example is concerned, I personally prefer B, because I think the experience of middleware development is the main contradiction, and switching from C to C++ is not a problem. So the interviewer needs to judge which experience is primary and which experience is secondary. For example, we are recruiting Android application development. The Android technical threshold of this position is not high, and the real difficulty lies in doing a good job in user experience (UX). Therefore, if the interviewer has no Android experience, we can accept it, but I hope he has experience in UX, at least doing mobile application development on other platforms.

trend

Now, let me talk about what I think is the most important factor: personality. This may be unimaginable for many friends who have just contacted the interviewer. How can personality be the most important? To be honest, when I realized this, I was surprised myself! To put it bluntly, P (good job | good personality) has the highest probability. My practical experience is that if a person has a good personality, he is most likely to do a good job. A good personality is far more reliable than a good foundation and a good algorithm.

If a person is technically flawed and inexperienced, but has a good personality, it is easy for others to make up for it in the team, and he can easily make up for it gradually; On the contrary, if a person's personality is not good, all the technical advantages and experience advantages will not be brought into play, and even negative effects will occur, and it is difficult to change the shortcomings of personality. I have always said that practical work needs comprehensive ability, and in the exertion of this comprehensive ability, personality is very important. The project will not only encounter technical problems, but also involve communication and coordination. Different people and different departments have both cooperation and friction. How to deal with these things requires a good personality. It can be said that what makes you unique in the development team is not which school you graduated from, nor your past experience, but your personality.

Of course, personality is a complex thing, including many aspects, not all of which need to be paid attention to in the programmer's interview. My experience is that we can pay attention to 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. None of this is too ugly. On the contrary, you can obviously feel the negative emotions of some interviewers. Enthusiasm is very important in work. Positive people can bring vitality to the team and make it easier to cooperate. Basically, if the interviewer is sure to have a positive attitude, his chances of passing my pass will be greatly increased; On the contrary, if I am determined to be negative, I will be very cautious even if my technical ability is good.

2) IQ. My experience is that, on the whole, smart people perform better at work. When interviewing, you don't have to find some intelligent questions to test your IQ, such as Google and MS. In fact, you only need to see if he is logical in discussing the problem, and whether he is quick in thinking and speaking, so you can make a general judgment. In addition, eyes are the windows to people's hearts. Whether a person is smart or not, his eyes can talk. However, cleverness is not entirely an advantage. For example, when a company or a project encounters difficulties, it is often smart people who run first, and those who stick to it are often people with average IQ.

3) Language expression ability. Language expression ability is also a very important quality of programmers, which is related to the smooth communication in the project. The interviewer can see whether the interviewer can clearly introduce the projects he has done in concise language, grasp the main points and consider the relevant background of the listener. Generally speaking, people with strong language skills will not be too poor in comprehensive ability.

4) Whether there is user awareness. Some people say that programmers are engaged in research and development, but what about users? Only sales and marketing personnel will deal with users. In fact, this is a complete misunderstanding. If you write a module or even an API, as long as someone else uses it, he is your user. When designing a module or software, some programmers are always used to thinking from the user's point of view, which is a good user awareness. People with good user awareness can better consider other people's feelings and overall needs, rather than simply thinking from their own and local problems. When talking about past project experience, interviewers can often ask questions from the user's point of view, and observe whether they have good user awareness from this process.

5) How to deal with doubts and pressures. The interviewer should reasonably question the interviewer's answers and past projects to see how he responds. Once an interviewer talked about the experience of playing games and logging in to the server, so I asked, "What if the login server hangs up?" He said that although this problem was not considered at first, how can it be improved? In fact, we all know that there are various imperfections in the project, and there are many reasons for this situation. As long as you can calmly face doubts and pressures and try to think in a good direction, you don't need to hide your defects and you shouldn't have emotions. I have met some interviewers. Once you question their project, they immediately become rebellious, or unhappy, or refuse to admit that there is a problem. It is easy to see that he has no room for questioning and criticism in his work, and it is difficult for such people to cooperate.

6) Personality characteristics. Many interviewers like to write "proficient in C++/Linux" on their resumes, which makes people numb. If someone writes "Like C++/Linux", I will have a bright feeling. "Proficient" is an unemotional narrative, while "like" contains the interviewer's personality. I prefer to see the interviewer's personality. I believe that the real passion for something is far more important than your current mastery of it. In fact, the experience of N years tells us that students in the same class and colleagues in the same project team have the same knowledge and work every day, but in fact, the differences in grades and performance are very obvious. So, what is the essential difference? In fact, it is everyone's personality. It is 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 interviewer to show his personality and judge whether it is beneficial to the team.

abstract

Finally, to sum up, my experience is: 1) The interviewer's goal is to find someone who works well, and the interview must be conducted around this goal. If the interview is regarded as the final exam of algorithm or operating system, it will go into a misunderstanding; 2) The interview process is to comprehensively judge the interviewer's "good job" probability through measurable factors such as education, personality, foundation, experience and algorithm; 3) among various factors, personality >; Experience > fundamentals > algorithm. Personality is the most important thing. Bad personality, all technical ability will be greatly reduced, technical defects are easy to make up, and personality defects are difficult to change; Experience reflects a person's comprehensive ability. You can judge what the interviewer can and can't do from his past experience. Fundamentals and algorithms mainly play the role of auxiliary reference. Programmers with a good foundation are generally more adaptable and learn new technologies faster, but don't judge a person's ability simply from the foundation.