Programmer interview zhongdian

Document directory

• Algorithm
• Basic
• Experience
• Character

Programmer interviews have always been a hot topic in the community. Since my internship in 500, I have experienced four software companies, all of which are foreign companies, including the world's top communication companies, there are middle-sized European financial companies engaged in option futures trading, and emerging companies that develop Android smart cars for large automakers. Since entering the IT industry, I have experienced many interviews during my job search process, and have had many interviews with others in the last two years. When I feel that I have come to express my views on this issue, I am standing here.Interviewer's perspectiveA periodic reflection on the programmer's interview questions and a summary of experience.

Target

Like many of my friends, I started interviewing others after having several years of experience as Senior. At the initial stage, I just tried to "find a Basic programmer" and "Find a programmer with excellent algorithm capabilities", "Find a programmer with Android development experience" as the interview target. However, the actual experience tells me that, in particular, the goal of "good foundation" and "good algorithm" is not very effective. For example, some interviewers have good knowledge about basic knowledge and algorithms, and have clear concepts such as processes, threads, and memory. They are also familiar with basic data structures and algorithms such as Hash, binary tree, and fast sorting, however, after entering the company, the performance is terrible in actual work. Later, I found out that I had a problem with my interview goal. My original interview method was more like a college algorithm or an operating system final examination, in this way, many unsuitable people may have passed the interview and missed many suitable people.

Later, my reflection was that from the company's perspective, the fundamental purpose of the interview was to find"Able to do a good job"People who are "highly educated", "Good algorithms", "Good Foundation", and "experienced" are not fundamental representations. They cannot be directly equal to "working well.

Method

The goal is clear, but the following problem is that the interviewer is a black box system and "working well" is not a direct observability variable, the variables you can directly observe are basic, algorithm, experience, education, personality, conversation, age, and so on. Therefore, in fact, you can only speculate on the probability of "working well" from the amount of data that can be directly observed, such as "Basic" and "good algorithm, this is a conditional probability problem of "working well" under "X" conditions:P (Good Job | good job).

According to this model, what aspects should be investigated during the interview is obvious, that is, the most distinctive aspect should be selected for the interview. For example, it doesn't make much sense to test the interviewer's body type characteristics, because P (Good Job | high), P (Good Job | short), P (Good Job | fat ), P (Good Job | thin) has almost the same probability. Therefore, the shape features are not differentiated, which is not the content that the interview should pay attention.

The interviewer should be clear according to the requirements of the positionWhich factors have better differentiation?. For example, if you want to hire A high-tech 3D Game Engine Development Engineer, Interviewer A has experience in 3D game engine development, but has A general performance in basic knowledge and algorithm interview; on the contrary, Interviewer B has excellent basic knowledge and algorithm interviews, but has no experience in game development. You can only choose one of them. Who do you choose? In fact, this is the two conditional probability problems P (Good Job | good experience, basic, general algorithm) and P (Good Job | inexperienced, good foundation, good algorithm ). This question is left for the interviewer to judge. Personally, for positions with high technical thresholds that require technical accumulation, experience is more relevant. Therefore, I prefer Interviewer.

Next, I will share my thoughts on the common aspects of the interview based on my experience.

Algorithm

Algorithms are the focus of interviews with large companies such as Google and MS. I personally like algorithms. I used to take 13 of ACM/ICPC's Beijing division. However, in my personal experience, algorithms are not suitable for most development jobs I have been involved in as a major factor in understanding the advantages and disadvantages of interviewers. For general non-algorithmic development jobs, the algorithm used to test the subject is equivalent to checking whether the subject is playing table tennis or not, and the correlation with the target "working well" is too low. In my personal experienceP (Good Job | good algorithms) = 50%That is, algorithm interviews are not much differentiated.

Even there is a very bad situation that appears especially in the interviewer with good algorithms. I call it "only sharpen the knife, not cut firewood ". What does it mean? Some people are only interested in pure technical issues such as what A * algorithm, asynchronous programming, and JVM class loading mechanism, and are not interested in implementing user requirements. Such people seem to have certain technical capabilities, but they have very limited contributions to the company. They are even less technical but responsible. Therefore, once the interviewer has a good algorithm, I will pay special attention to whether it will be such a "only sharpen the knife, do not cut firewood" person.

In addition, although I personally do not know Google and MS, I am skeptical about the interview strategies that place special emphasis on algorithm capabilities. Even in such a world-class company, although algorithms are important, it can be imagined that in the various problems encountered in the project implementation process, algorithm problems are mostly not the main bottlenecks, there is no need for everyone to be an algorithm master. In fact, the vast majority of projects do not have one or two algorithm bottlenecks, or even a single point of technical bottlenecks, but are systemic problems of organization, coordination, design, and development, there are a large number of dirty jobs that do not seem so technical, and there are also many problems because of insufficient information. These difficulties can be overcome without strong technical capabilities. It is best for a team to have complementary advantages, strong algorithms, strong business analysis capabilities, good backend services, good front-end interfaces, smart, and steadfast. This is the best. If the materials are selected according to the single standard of "good algorithm", many excellent talents will be rejected.

Basic

A basic interview is an interview that examines basic knowledge such as pointer usage and process thread concepts. It is very similar to a college final exam. I used to think that basic interview is very important, but now I don't read it that way. The Foundation is indeed important at work, but in the interview process, it must be differentiated to make sense. That is to say, P (Good Job | good foundation) has a high probability, so it makes sense to evaluate the usage of pointers only when the process thread differs from such basic questions. My practical experience is that basic interviews are not very distinctive. They are similar to algorithms.P (Good Job | good foundation) = 50%. At the same time, basic interviews are the easiest way to prepare. Chinese people have long-term experience in exam-oriented education. It is too easy to prepare a few questions.

I have met an interviewer who has a good grasp of the basic and compilation and linking principles of C language. I was deeply impressed by the interview conclusion: the knowledge is not wide. Only the C language is used, but the foundation is solid and it is recommended to be hired. The last thing proves that the first half of the conclusion is correct, but the "recommended employment" is wrong. He is confused in his actual work, does not understand the needs, and does not understand the overall architecture. At the same time, he does not spend his work hours on projects, it is spent reading books such as "Programmer self-cultivation. Finally, this colleague left the company for a long time because he was "not living.

The foundation is not unimportant, but "good foundation" is not enough to show that the interviewer can do a good job, becauseThe Foundation is local knowledge, and practical work requires comprehensive capabilities.The two are quite different. Do we still have fewer students who can take high scores in C language and operating systems but do not write programs in college? Software development is like building a house. The comprehensive ability is to design and build a skeleton, and the basic knowledge is code brick. Zhang Xiaolong was originally developed by Foxmail in Delphi and does not understand C #. If you want to recruit a person who develops the. NET Email client, do you think he has a good grasp of CLR? Is it really difficult for Zhang Xiaolong to develop a C # Foxmail? Are you more reliable than Zhang Xiaolong if you recruit someone who is proficient in C # but has no experience in Email client development?

Therefore, a good foundation is not enough to explain too many problems, so we must further examine the comprehensive capabilities. For interviewees with poor basic interview performance, if the time permits, further study is required. Some interviewers are actually competent, but are not fully prepared. Of course, the most ideal state is that both basic and comprehensive capabilities are excellent. If they cannot be both considered, comprehensive capabilities should be given priority.

Experience

The importance of experience lies in its ability to demonstrate a person's comprehensive abilities.. For example, whether a software is fully implemented or a project has been completed as a major developer. From the nature, scale, and difficulty of the project, the interviewer can roughly determine the comprehensive ability of the interviewer. For example, if the interviewer has been responsible for the development and maintenance of a small module in a large company, then it can be judged that the interviewer does not have the ability to be independent or take on a project as a major developer, it is only suitable for doing similar things in another big company.

For jobs 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, and advanced UX. For such positions, it takes a long period of study and accumulation to be competent even if the overall quality is good. Therefore, if your position is determined to belong to this category, the relevant experience should undoubtedly become the first choice. In other words, the probability of P (Good Job | good experience) is very high.

It should be noted that experience is also a multi-dimensional thing. For example, the C ++ stock transaction middleware system involves three dimensions: (C ++, middleware, and stock. Assume that Interviewer A has been a c ++ stock trading client, and Interviewer B has been A C stock trading middleware. From the perspective of language, A is the most matched. From the perspective of project nature, B is the most matched. How do you choose? This is the question of which dimension is more important in multiple dimensions. In this example, I personally prefer B because I think the middleware development experience is the main contradiction, switching from C to C ++ is not a problem.

Therefore, the interviewer needs to determine which experience is important and which experience is secondary. For example, we are looking for Android Application Development. This position has a low technical threshold for Android. The real difficulty is to make a good user experience (UX ). Therefore, it is acceptable if an interviewer has no Android experience, but I hope he has experience in UX And at least has done mobile application development on other platforms.

Character

Now, let me talk about what I thinkThe most important factor is personality.. This may be hard to imagine by many new interviewers. How is it most important? To be honest, I was surprised when I realized this! To put it bluntly, P (Good Job | good personality) has the highest probability. My practical experience is that if a person has a good character, he is most likely to be able to do his job well. His character is far better than the basics and algorithms.

If a person has technical flaws and experience weaknesses, but has a good personality, it is easy for others to make up his position in the team. On the contrary, he can easily make up his position, if a person has a bad personality, all technical advantages and experience will not be able to play a negative role, and it is difficult to change his or her personality shortcomings. I have been talking about what practical work requires is comprehensive capabilities. It is vital to give full play to this comprehensive ability. There are not only technical problems in the project, but communication and coordination are required. Different people and departments have both cooperation and friction. A good character is needed to deal with these issues. It can be said that what makes you different from the development team is not the school you graduated from, nor your past experience, but your character.

Of course, personality is a complicated thing. It involves many aspects, not all of which are the concern of programmers for interviews. My experience focuses on these aspects:

1) positive attitude or negative attitude. Some interviewers will naturally give you a positive feeling, or you can discover positive factors in his experience. These are not too ugly. On the contrary, some interviewers can clearly feel their negative emotions. Enthusiasm is very important in the work. Positive people can bring vigor to the team and facilitate cooperation. Basically, if the interviewer is determined to be positive, his or her chances of passing through this level will be greatly increased. On the contrary, if the subject is determined to be negative, I will be very cautious even if my technical skills are good.

2) IQ. My experience is that, in general, smart people are doing better at work. In the interview, it is not necessary to find some intelligent questions dedicated to testing IQ like Google and MS. In fact, you only need to check whether the questions he discusses are logical, you can make a rough decision on whether or not you are agile in thinking and speaking. In addition, the eyes are the windows of the hearts of the people. If a person is smart or not, his eyes can talk. However, being smart is not entirely an advantage. For example, when a company or project encounters difficulties, it is often a wise person who runs away first and the rest is a common person.

3) language skills. Language expression ability is also a very important quality for programmers. It is related to the smooth communication in the project. The interviewer can check whether the interviewer can clearly introduce the projects he has done, grasp the key points, and take into account the background of the listener. Generally, the comprehensive ability of a person with strong language expression ability is not too bad.

4) Is it user-conscious. Some people say that programmers are engaged in R & D. Where are the users? Only sales and marketing personnel can deal with users. In fact, this is a complete misunderstanding. You write a module or even an API. If someone else uses it, it is your user. Some programmers design a module or a software. They are always used to considering it from the user's perspective and try to make it easier for users. This is a good user consciousness. People with good user awareness can better consider others' feelings and overall needs, rather than simply thinking about problems from their own and local aspects. When talking about the past project experience, the interviewer can often ask questions from the user's perspective and observe whether the interviewer has a good user awareness.

5) how to deal with challenges and pressures. The interviewer should give a reasonable question to the interviewer's answers and previous projects to see how he can respond. An interviewer once talked about the experience of logging on to the server through games. I asked, "What if the login server fails "? He said that although he did not consider this issue, how can he improve it. As a matter of fact, we all understand that there are various imperfections in the project. There are many reasons for this. As long as you are able to calmly cope with the challenges and pressures, you can think and solve the problems in a good direction without the need to conceal the defects, there should be no emotion. I have met an interviewer who, once you question his project, immediately becomes rebellious, or unhappy, or does not admit that there is a problem, it is easy to see that he cannot question or criticize at work. It is very difficult for such a person to cooperate.

6) personality characteristics. Many interviewers like to write "proficient in C ++/Linux" on their resumes. These words are very boring. If someone writes "like C ++/Linux", I will have a bright feeling. "Proficient" is a non-emotional narrative, 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 understanding of it. In fact, the N-year experience tells us that the same class of students and colleagues in the same project team share the same daily knowledge and work, but in fact, the difference between each person's score and performance is very obvious. So what are the essential differences? In fact, it is everyone's personality. Personality makes some people play in their spare time, some read books in their spare time, some like Linux, and some like Mac. A person's role in a team also has a lot to do with his personality. The interviewer should guide the interviewer to show his or her personality and determine whether the interviewer is good for the team.

Summary

In conclusion, my experience is as follows: 1) the interviewer's goal is to find a "good job" person who must conduct an interview based on this goal, if the interview is regarded as an algorithm or an operating system final examination, this is a misunderstanding; 2) the interview process is based on factors that can be tested, such as education, personality, foundation, experience, and algorithm, to determine the probability that the interviewer "works well". 3) among various factors, personality> experience> basics> algorithms. Personality is the most important thing. If the personality is poor, all technical skills will be greatly compromised, and technical defects will be easily compensated, making it difficult to change. experience reflects a person's comprehensive ability, you can determine from the interviewer's past experiences what kind of work he can engage in, and what kind of work he can not engage in. the basics and algorithms are mainly used for reference. programmers with good foundations are generally more adaptable, it is faster to learn new technologies, but it is not necessary to judge a person's ability simply from the foundation.