How DO I Hire Programmers?

I once wrote an article about how I hire Programmers (and got a lot of responses at CSDN). Today, I want to talk a little bit more about hiring and interviewing for the following reasons:

• In the past half year, I have been engaged in a large number of recruitment work, and I have some new experience on the interview.
• Cool shell recently published several interesting interview questions (interview question 1, interview question 2, interview question 3), from the response to give me some thinking.
• A colleague of mine who was recently interviewed by a company shared his interview with a PhD expert and got me thinking.
• I found on Douban that “a person wrote his/her interview experience as a product manager of Douban on Zhihu, and I was very happy” (the highlight is that the interviewer appeared on Zhihu and answered the question himself)

So, I want to write down these new ideas again. As always, this article is for the interviewer. In my opinion, the quality of an interview depends entirely on the interviewer rather than the person interviewing. Here are some of my reinforcing points from “How I Hire Programmers”. (See the next post for some comments.)

For the sake of continuity, let me reiterate a few important points I made earlier.

• Only when the candidate behaves authentically and naturally will he or she know the truest things
• What matters is not the knowledge, but the ability to find it
• What is important is not the answer to the problem, but the idea and method of solving the problem

Operation, knowledge, experience, ability

Many of our interviewers seem to be confused about what is operational ability, what is knowledge, what is experience, what is ability, which leads to our interviewers often make the wrong conclusion about the interviewees, I think people who can not distinguish these things are not qualified to be an interviewer. Therefore, I need to be clear about this issue here.

• Operation. Our interviewers can’t distinguish between operational skills and knowledge, they even think that operational skills are knowledge or even experience. For example, they ask questions like, what does final mean in Java? How do I check the CPU usage of a process? How to write a pipeline program? How to view the program path of a process? What is the copy and paste command in VI? Including what the object-oriented XX schema is. And so on. In my opinion, these things that can be found by looking up manuals or googling can only show the skill of the person, not the knowledge or experience of the person.

• Knowledge. Knowledge is the embodiment of a person’s cognition and learning, which may be some basic concepts and knowledge. For example: TCP versus UDP, linked lists versus hashes. What is a heap and what is a stack? How do processes communicate with each other? What are the pros and cons of processes and threads? Advantages and disadvantages of synchronous and asynchronous? What are the main principles of the object-oriented XX design pattern, etc. In my opinion, “knowing what it is” is just operating technology, “knowing what it is” is the real knowledge. Lack of knowledge does not mean that he cannot work, he can cope with the work if he has operational skills, but the lack of knowledge will certainly limit your experience and ability, and also affect the quality of your development.

• Experience. Experience is usually related to one’s experience. A person’s range of knowledge, what a person has experienced, often becomes a reflection of a person’s experience. In interviews, we ask these questions: What is the most difficult problem you’ve ever solved? How did you design the system? How do you debug and test your program? How do you do performance tuning? What is good code? And so on. For people who have not been working for a long time, experience and what they have done can indeed be a major factor in their experience, especially in business with industry background. However, I think experience is more about your application and control of knowledge, your reflection and summary of what you have done, and your learning, observation and communication with others.

• Ability. A person’s ability does not fail because he knows little, nor does he fail because he has no experience. A person’s ability is an attitude, character, idea, train of thought, behavior, method and style of doing things. With enthusiasm, ideas, good manners, and a good style, knowledge and experience are only a matter of time. For example: learning ability, specialized research spirit, analytical ability, communication ability, organizational ability, problem investigation ability, cooperation ability and so on. Therefore, for a novice, his knowledge and experience may be limited, but it does not mean that he has a problem in his ability, but for an old hand, if there is a lack of knowledge and experience, then it is usually the problem of his ability. You may be temporarily underappreciated, but I don’t believe you will be underappreciated for long. If so, then you must have some problems that keep you from performing at your best. In this case, “no experience” is just an excuse for “incompetence.”

I don’t deny that all four things are important to a good programmer. However, from the above analysis, we can know that ability and experience and knowledge need to be treated separately. Of course, these things complement each other, your ability can give you knowledge, your knowledge can give you more experience, your experience will change your thoughts and thinking, so as to improve your ability. In the interview, we need to clearly realize that the operational skills, knowledge and experience of the candidate is only a necessary condition of his ability, but we should pay more attention to the candidate’s ability.

• If the interview is just a test of the person’s skills, the interview is a complete failure. This is an unqualified interviewer.
• If the interview is only testing the person’s knowledge and experience, half the battle is won. Just because you know the basics and what you’ve done doesn’t mean you fully understand what he’s really capable of.
• If you can focus on the person’s abilities (attitude, personality, ideas, train of thought, behavior, method and style) as you learn about the person’s knowledge and experience, and assess the person’s abilities correctly, you will have a successful interview.

These four words may not be the right words to describe a set of things, but I think you get the point. In addition, I would like to say that we are not trying to test candidates with questions. We are trying to find their strengths and strengths.

Don’t take algorithmic and intellectual questions superficially

A lot of companies give algorithmic questions or intelligence questions or design questions during the interview, and I believe that algorithmic questions or intelligence questions are one of the most annoying things programmers do in the interview process. A lot of people hate the algorithmic questions that interviewers ask because they don’t think the algorithmic or intelligence questions will be used in the real job. But I want to say here that there is nothing wrong with algorithmic intelligence questions, and that many of the wrong questions are superficial or even misunderstand the purpose of the interview puzzle. The idea that anyone who can do algorithmic and intelligence problems is smart or capable is really superficial.

In fact, the ability to solve problems does not mean that a person has the ability to solve problems at work. You can think about it, the math Olympiad in primary school may be more difficult than these problems, but it does not mean that those who are good at math Olympiad have the ability to actually work. You can think of your class to get high marks in the examination of the students are not necessarily smart people, is not necessarily capable people, on the contrary, such people are often in the test-oriented education to cultivate the bookworm.

Therefore, I think the problem solving process is more important. You should mainly check the applicant’s ideas, methods, knowledge, experience, interaction with you and smooth communication, etc. These are the key to observe. Eventually, of course, the answer has to be found.

I think the real way to get a candidate to solve a difficult problem is this:

• Look at his application and understanding of knowledge. For example, does he use basic data structures and algorithms to solve algorithmic problems?
• Look at his whole set of ideas. The answers are secondary, his thoughts and actions are important.
• See how he discusses and communicates with you. Think of the interviewer as your future colleague, as your work partner, solve problems together, discuss them together, and see if people can work together.

These are the qualities (ideas, methods, attitudes, character, etc.) of the candidate, along with the experience and knowledge of the candidate. Here are some interview points:

• Will the candidate break down or simplify the problem when solving an algorithm? It’s analytical.
• Will the candidate use some basic knowledge, such as data structures and basic algorithms, when solving algorithmic problems? This is knowledge.
• Do you feel the applicant’s professional research spirit and good communication in the process of solving the problem and discussing with you?
• The mentality and attitude of the applicant towards this algorithm. For example, whether there is a fear of difficulty in the interview.
• Is the applicant’s thinking and method when solving the problem appropriate? Is it a scientific method?
• And so on.

The goal is to test the candidate’s ability to solve difficult problems, not to embarrass the candidate, otherwise you will be an arrogant and ignorant interviewer.

Simulate real-world challenges and capabilities

As an interviewer, you should think about your job and how you grew up. This will help you in your interview. How do you actually solve problems at work? What is the reality of your code? What was your upbringing like? How did you acquire your knowledge and ability? What kind of people do you like to work with? You can easily find that the actual situation in your job and the interview situation are completely different, so how can you use such a very different interview to assess a person’s ability?

Therefore, the ideal interview is to work together for a period of time. Of course, this is almost impossible to do in the hiring process, so it requires our interviewers to simulate the interview process as much as possible. Have some discussions to solve a problem, review with the candidate what he has already done, and discuss and learn from each other as you go back. Here’s an example.

As we all know, software development is not difficult to develop software. Here are the challenges:

1. The cost of software maintenance is far greater than the cost of software development.
2. As the quality of software becomes more and more important, so does the testing effort.
3. Software requirements are always changing, and software requirements are always incremental.
4. A lot of the code in the program is dealing with some kind of wrong or abnormal flow.

So why can’t we simulate this process when we’re testing a candidate’s coding abilities? For example, ask the candidate to implement a function atoi(), which should be easy to implement, and then keep adding new requirements or new cases, such as: Non-numeric symbols, letters, deal with the space, handle hexadecimal, binary, processing “comma”, and so on, we want to see how the applicant to modify his code, how to write test cases, how to reconstruct, with more and more things to deal with, whether his code is so easy to read and clear. If you’re just testing your coding skills, just ask that one question for an hour. Real programmers deal with this kind of thing every day.

If you want to test the design ability of the applicant, the same can be done. We’re constantly adding new energy, new demands. Look at the interviewer’s thinking, thinking, analysis methods, and you discuss whether smooth, said no said on the point, thought is not clear, what kind of knowledge, applies his experience in the design of this system is what would, in the face of constant change and demand more and more complex, his design is still so good?

Of course, because the time is short, so, you can’t ask too complicated questions, this requires you to carefully design some refined representative questions.

Author: increasingly, blog: https://coolshell.cn/articles/18190.html