How to find a good programmer in the interview

ArticleDirectory

• Part 1: Test the authenticity of resumes
• Part 2: discover practical experiences
• Hidden time found
• Empirical Density
• Part 3: verification experience
• Encoding Problems
• Further steps

Original article link.

In an interview, I asked a very experienced embedded software developer to write a reverse string and output it to the screen.Program. He struggled for a long time on the subject. This guy is amazing. You give him useless parts. He can build a robot and use a program to control it walking around the house. He used to develop a satellite.On-Orbit Operation. He can only use his left-brain skills. However, he has never had a chance to do anything on the screen.

 

Some people have this skill and can ask the right questions during the interview to find excellent programmers. However, some people are afraid to ask questions, and they are afraid to answer questions. If they ask questions copied from the Internet, they will only follow the opinions of other interviewers. However, interviews are a basic skill for most developers. A failed job fair has serious long-term consequences for an organization, because employees with high levels of water bring others into the company. On the other hand, turning out outstanding candidates is also a kind of harm to the company.

A technical interview consists of at least three parts. In the first part, we need to check whether the applicant's resume is correct. In the second part, we need to evaluate the number of candidates.Practical experience. Finally, we need to test this experience with some Q & A options or programming questions.

Part 1: Test the authenticity of resumes

I once interviewed a candidate with a colleague. After the interview, I think this candidate is good, but not very good. But my colleagues seem very dissatisfied. "He lied. He said he would use XXX technology, but apparently he didn't do it. This is definitely not the case ." Although this XXX technology is not very important to our company, "it's because of this panic," my colleagues continued, "I won't trust anything he wrote on his resume."

Candidates should use a positive color in their resumes to describe themselves. However, this positive description should have a degree. After this degree, the expression is incorrect. In the above example, I don't think this is very serious like my colleagues, because I assumed that,Everything on your resume is false unless it is proved.If my resume says "good at XXX technology", I think this candidate may only be known as XXX technology. If my resume says, "working in a team that develops a multi-thread stock trading system," I think that the applicant may just select the background color for the system. My requirements have never been strict, unless I have met a person who has ten years of work experience and is no longer writingCodeGuys. If someone says that he has developed a Text Formatting tool for OpenOffice software or has a doctorate in philosophy, it's easy to assume that they have any skills.Suppose there is nothing. Everything must be confirmed.

I will first estimate the actual situation of the applicant for each Related Description on my resume. Then, I confirmed through the following conversation.

• I have developed a real-time operating system as a practice project.
  How big is your team? 15 members? Oh, so what part do you actually take charge? Message Queue? Good! What happens when a high-priority task sends messages to a low-priority task?
• We have independently developed a set of audio transmission protocols for wireless security systems.
  How many people are there in your team? Only you? Oh, how did you test it? Why don't you use RTP?
• Fix bugs for the xxx engine.
  Please describe a particularly challenging bug you have found and how you fix it.

Part 2: discover practical experiences

Having more experience is a good indicator for excellent talents. Experienced developers are all mature from making mistakes. They know when and when they should not use design patterns. They have a sixth sense: they can feel which part of the demand needs to be modified and which part should be kept as is. They know when to be lazy and when to study it well. YesReal ExperienceThis makes it impossible to bridge the gap between excellent developers and mediocre developers.

 

 

 

Not all experiences are equivalent.It is very likely that, after years of work, he writes or re-creates countless codes in many tasks and makes many mistakes, so that he can gain solid skills. In another case, a person will modify only one line of code in one project in ten years without learning anything new.

 

 

 

Hidden time found

Many great programmers started programming in the second year of their college. When they left school, they had several years of work experience. Also, some amazing programmers started learning the art of programming when they were very young. I also met several people who wrote some small programs in their teens or hours later. You cannot find this information on your resume. You need to seduce it during the interview.

• How did you enter the software development line?
• The first one you have learnedProgramming LanguageWhat is it?

Empirical Density

Many amazing programmers only code during their work hours. This is a good balance between work and life. You have no reason not to hire such a person. However, doing some personal programming projects after work and study is a good indicator for excellent talents. Candidates with amateur programming experience obviously have more experience and are more suitable for the company. No personal project? Here are some other indicators that can be used for this purpose:

• Work in a small team or group.
• I have participated in many kinds of projects.
• I have a detailed understanding of all abstract aspects of a large project.
• As the main developer in a project team.

Part 3: verification experience

After having a basic experience for the applicant, I began to verify their practical programming experience. A few minutes is definitely not adequate for a real test, but that's the only thing we can do. We can ask questions in various programming and development fields to understand the depth and breadth of these knowledge. Of course, your opinion on the skill level of the candidate will be biased by your own experience level. You cannot make a correct judgment on the answer to a domain you are not familiar. So we usually have several interviewers at the same time.

Different job positions have different interview subjects. However, the following fields are common:

• Data Structure andAlgorithm
• Multithreading
• Byte operation
• Memory Allocation
• Object, inheritance, design mode
• Recursion
• Assembly knowledge and program running principle

Each field I select has a very well-selected basic question ("What is a signal ?"). The question is very basic. As long as the applicant has done some work in this field, he can answer these questions. There are some other in-depth problems in each field. The candidate's answers to these questions prove whether they are professional or not. For example, if you ask an experienced embedded software developer how to convert 0 × 4C to binary, he writes a 4 × 16 + 12 file, which is not true.

Encoding Problems

After completing the above steps, I usually can determine whether the candidate can pass the examination. If there are still difficulties, the coding problem will help me eliminate the final obstacle. This is important and cannot be missed even during phone interviews. In order to be effective, before the interview, you should think carefully and plan the coding questions to be raised. If the question is wrong, the answer is meaningless.

First, the problem must be based on the applicant's work experience. If you think about a 3D airplane and want to surround it with all the problems, it will be a wonderful problem. But you can save it. It's okay to talk to your colleagues during lunch. If the recruitment work has nothing to do with 3D graphics, the candidate will surely be ruled out unfairly.

The problem must be accurately expressed. "Write a function to move a pile of cards", which is very ambiguous. The functional title should be given to avoid misunderstanding. Such a thing often happens. If you are not careful, the interviewer may answer a question that is more difficult or easier than the question you asked, rather than the question you want to ask. If you answer a more difficult question, It's okay unless the problem makes him stunned. It is of no use to answer a simpler question. In order to avoid wasting a lot of time, they asked their answer outline several minutes later to see if their understanding is in the correct direction.

Further steps

The above instructionsAll problems cannot be solved.These are mainly for work experience. You may miss out on some outstanding programmers who have little experience but great potential. Especially when the interviewer wants to examine the candidate's ability to solve the problem through some non-coding problems.

The interview skills mentioned here are based on assumptions, possibilities, and internal intuition. Assume that the candidate is an outstanding developer. What qualities should a good developer have? You cannot directly measure these qualities, so you need to think: what is the possibility for a good developer with these qualities to quickly answer such a specific question? You cannot make 100% correct comments on a candidate through the interview, but you will be very close to the result by asking as many questions as possible.