Read what the interviewer thinks when interviewing programmers

Every programmer will experience something in the future - interview. Maybe you were very relaxed during the interview, or maybe it was very uncomfortable. I think a good interviewer is very important, so let's talk about how those interviewers conducted interviews.

For the traditional interview recruitment process, it basically looks like this:

Read the applicant's resume and ask the applicant to introduce himself.

Ask some difficult and very detailed technical questions in a question-and-answer format.

Give the interviewer some and several programming problems. (Such as some weird algorithm questions)

I personally think this interview method is ridiculous and terrible, especially the last two points. Generally speaking, this kind of interview will only allow you to interview some "nerds" or some "technical obsessives". Let me analyze the disadvantages of these one by one.

It is difficult to understand a person from his resume or self-introduction. Because these are all written or elaborated by the parties themselves. Therefore, this is not very accurate. Through the resume, you can only know very simple things, which is far from enough to determine whether you can be recruited into the group. At the beginning of the interview, asking the candidate to introduce himself will only make the interviewer face the entire interview in a very formal manner. Once the interview process is very formal and serious, it will make people feel restrained. In fact, this is not what we want. What we want is the true and natural performance of the candidates, so that we can understand the most real things.

Ask a few questions about technical details. For example: What I have personally experienced - "What does the -a parameter of ps mean?", "What is the command to delete newlines in vi?", "What are the C++ keywords explict and mutable used for?" etc. ,etc. As a job applicant in the past, I hated questions like this very much, because you could just check the manual for such questions. Is he looking for a dictionary and manual? Not alone? For this, it is not the knowledge that matters, but the ability to find it.

Give the candidate one or several difficult algorithm questions for more than ten minutes, and then ask the interviewer to write down the pseudocode or code. This approach is quite ridiculous. There is no discussion or information checking. It makes people answer under a state of pressure. This is not the state of actual work at all, and our interview has become a kind of difficulty (my most perverted My experience is that after I handed in the code written on two pages, the interviewer handed it to the programmer next to me to output it on the computer for verification. As a result, the programmer said that there was a compilation error. So, the interviewer said, "Very good." Unfortunately, maybe you haven’t written many programs yet”, which is quite ridiculous). For this point, what is important is not the answer to the problem, but the idea and method of solving the problem.

I have experienced many interviews before. When technicians came to interview with me, I found that for some people, the "technician's thinking" cannot distinguish between interviews and exams. Subconsciously, Here, in many cases they are not interviewing the person, but making things difficult for the person and demonstrating their skills. I personally think I'm a good programmer, but I can tell you I couldn't pass an interview like that because that interview is for themselves, not for the candidate.

So, how did I get the interview?

1. Confirm your resume. First of all, you need to read other people's resumes. From the resume, you need to understand these three things: work experience, project experience, and technical skills. Generally speaking, you can first confirm his work experience, project experience and technical skills by phone. Then, if he matches the conditions of the person you need, you can call the company for a face-to-face interview. Never call others over and say there is a gap between your experience and our work. (I have had an interview experience. I won’t talk about the company. Anyway, it is the company that claims to need good communication. I was interviewed about 9 times, from ordinary programmers, PMs, managers, to general managers, and the last time I was directly interviewed Tell me, there is a big gap between my previous experience and their requirements. I can’t help but ask, what were they doing in the previous interviews? )

2. The opening of the interview. Secondly, when inviting people to the company for interviews, one thing is very important when the candidates come to the company for interviews, that is, you must make the entire interview process casual and relaxed, just like an ordinary chat or an ordinary communication between friends. . Only in this way can the candidates relax and show their real appearance to talk and chat with you, and you can learn more in a short period of time. It is the responsibility of the recruiter to let the candidates put down their psychological burden and behave naturally. Never say that others are too nervous to perform well. Sometimes, recruiters have to think about their own problems.

At the beginning of the interview, never let the applicant introduce himself, because the applicant has already sent you a resume, and you have also called him. In addition, candidates are usually very well prepared for this interview routine. On the other hand, this can make the entire interview process too formal and serious. So, why not ask the applicant how he got here? how are things? You can also talk to the candidates about a general topic, such as what sports, music, movies, social hot topics they like, etc. Don't keep a straight face, just talk and laugh, trying to make everyone relax. In addition, through these small conversations, you can get to know his/her ability to interact with people and some of his personality. Also, keep the table away from you and the candidate and keep the environment casual.

3. Let the applicant talk about his or her experience. Next, if you want to feel that this candidate is a person who can solve problems and get things done, you don’t need to ask him/her what he/she will do, but directly ask him/her what he/she has done? What have you done? For a good programmer, it is difficult to imagine that there is no relevant practice. Even if you are in college, you should have done something. If you have the ability to solve problems, then obviously you should have solved a lot of problems and accomplished a lot of things today. Listen to the applicant talk about those things. (Don’t use a question-and-answer approach. Let the applicant speak more, listen more, and think more)

When he talks about his project, generally speaking, you should pay attention to the following points:

Communication and expression skills. Can the applicant explain something clearly? If this person is smart, he can explain a complex matter clearly in the simplest language. Moreover, this is the most basic ability of a good programmer. Moreover, you can have some good back-and-forth conversations with the applicant while the applicant is describing his experience, so that you can know his communication skills and communication methods, and thus understand his personality.

Roles and locations. Maybe he was involved in a big project, but just made a very simple module. Therefore, it is very necessary to understand their role and position in the project. When applicants use words like "we" or "everyone", they must be detailed and clear.

What contributions have been made and what problems have been solved. This is very important. By understanding this, you can know whether the interviewer is smart, has the ability to solve problems, and has a good technical foundation.

Demo. If possible, you can ask the candidate to show some code he has written, designs he has made, or directly show you a demonstration of the program he wrote. (You can learn a lot about design, code style, reusability, and maintainability)

Basic knowledge. Understand some basic knowledge of the technologies used by candidates in the project. For example, through the entire process, you can ask about some basic knowledge of networks, languages, objects, and systems. Basic knowledge is very important, which is directly related to his ability.

Processes and Tools. Understand the project processes that the candidate is familiar with (silver bullet, waterfall, agile,...), as well as some artifacts in the process (such as requirements documents, design documents, test documentation, etc.), as well as the tools used in the development process Tools (memory testing, code inspection, BUG reporting, version maintenance, development and debugging...) (For the basic skills of programmers, you can refer to - "Basic Skills Programmers Need to Have")

Someone will It is said that the applicant's experience can be made up by himself, and he can say that he did some things that he did not do. Yes, it is indeed possible. However, don’t forget that behind a lie you need to use more lies to cover up the lie, so you don’t have to worry about this problem. As long as you gradually refine and refine the questions during the applicant’s description, you will know whether the applicant is I'm making up a story.

Be sure to remember the following points:

The conversation style should be casual and natural, not formal.

Don’t get too involved when learning about what the candidate has done before. Because the recruiters are also technical people, sometimes the recruiters themselves are attracted by the fascinating technology in the projects the candidates are working on.

Pay attention to guiding applicants. Believe me, eight out of ten programmers who apply for the job can't tell what they did before. Because they directly skip the project background and what kind of problems they want to solve, and go directly to the specific implementation.

Don’t just ask and answer questions, but let the applicant talk more, so that you can get to know a person more comprehensively.

Understanding a person’s past and what a person has done is more important than what they will do.

Understanding a person's personality, thoughts, thinking and behavior is more important than understanding his technical skills.

Communication skills, expression skills, language organization skills, understanding skills, etc. are related to whether you can work with others.

Basic knowledge is much more important than bits and pieces of knowledge. You may not know the keywords of C++, but you should know the inheritance and polymorphism of C++.

Technical skills are certainly important, but more important than that is the person's ability to acquire knowledge. Learning ability is necessary in a rapidly changing industry like computers.

Whether it can be cultivated is more important than the skills mastered.

4. Actual participation? ? This step may be difficult to implement. Because this requires some applicants to devote a certain amount of time. If they are graduates, there is no problem. Let them intern for a period of time first. But it’s not good if someone else has a job. Maybe you will say, this is the purpose of the probation period. However, I personally think that you have to respect the applicant. If they quit their job there and come to work for you, during the three-month probation period, if there are no problems in principle, you, as a recruiter, will regret it. , this is very bad. If such a thing is discovered, it can only be the recruiter's own fault.

During the interview process, some recruiters will ask the candidates to play a game together, or hold a debate competition, or form a team on site to do a simple thing, and some even ask the candidates to invite Take a day off to work with your team in your own company, and have to complete something (even set a deadline for it), and use this to measure the applicant's actual participation ability.

Yes, if you have never worked together and some actual things have happened, it is difficult to understand someone through a few hours of interviews. It is understandable for the recruiter to set up these interview links and learn everything about the candidates in the shortest possible time. And sometimes you can get good results. Here, I will only mention one point. Sometimes such a cycle is very long and requires the candidates to pay a lot, which in turn makes the candidates feel disgusted and bored. In a sense, this is really harmful to the candidates. of disrespect.

I have always had doubts about this, so I put two question marks after it. To be honest, my personal opinion on actually participating in this link is that enough is enough, because the time is too short, and no matter how you do it, you will not be able to understand it completely. Since you can't get it all, get what you need most, which are the three questions at the beginning of this article, and the "third point" mentioned above (understanding the candidate's past experience).

Through the interview process and summary described above, I hope that in addition to preparing for your own experience, you will also understand the interviewer's mind. But no matter what kind of programmer you are, you need to have good skills and be able to really develop, so that the interviewer can "talk about life" with you.

Related recommendations:

The 10 most error-prone PHP interview questions

Share some examples of front-end interview questions

Common PHP interview questions and answering techniques in 2017