Interview on a position of the developer as it is
Good day. At the moment I am in the position of Senior / Team Lead IOS Developer. It so happened that over the past year I had the opportunity to attend a huge number of interviews, so to speak, on both sides of the barricades. Therefore, I would like to share my experience and talk about how, in my opinion, it is necessary to conduct an interview, because in general confusion you can miss a number of important points that, subsequently, can negatively affect the quality of the interview.
This article will be useful to people who, by the will of fate, are forced to conduct interviews, but at the same time do not have the necessary experience and plan, as I once did. Everything described below is a conclusion from a large number of interviews conducted. But as they say, any coincidence of names or events with real ones is an accident.
Your task is to determine what the person knows, and not to show that you know more.
Anyone who interviews for the first time faces this. He perceives it as some sort of competition where he must, like the interviewee, show a class. This is not true. There is no doubt that you, as a person who asks questions, will be able to find a question in the depths of the Internet and on the secret pages of the manual that the interviewee cannot answer. But your task is not this.
')
Your task is to find out what this person can do for your company now and in three months, and not what he could have done a year ago.
I had to interview people who had more experience than me more than once. The first time it put me in a stupor, it was somehow embarrassing to ask questions to a person who is older than you, and in the field of programming it works longer. But all the awkwardness vanished as soon as he could not give a clear answer to the elementary principles of working with multithreading. Although the portfolio was impressive, the real knowledge was shallow. You hire a person who will work with you in the future, and not who he was 2 years ago.
Your task is to determine whether a person can join the team.
Regardless of the level of the interviewee, try to determine for yourself whether you can work with this person in a team, even if you know that you will not have to do this. Once, a friend came to the interview, who during the first 5 minutes managed to prank the HR manager and was far from the business tone throughout the entire interview, although he had some knowledge. After the interview, his candidacy was no longer considered, since no one wanted to work with him on the same team. In turn, you, no matter how you like a person, should be restrained and friendly, as you represent the whole company, and he only himself.
I work at a small firm, and I don’t have at my disposal a crowd of HR managers who organize everything at the highest level, so I will describe some points that need to be monitored.
I had to conduct an interview for various positions, and below I will try to outline the main points that need to be taken into account.
The goal is to find out the learner's ability to learn.
First, find out where a person is studying or studying (I support the idea that you need to have an engineering education to work as a programmer, as this will allow you to speak the same language). God knows, people from the Conservatory of Music came to me for an interview. They took 2-month programming courses.
Learning can be partially compensated for by zeal. And here comes the education system. Find out what is the average score of the applicant, he learns for a fee or for free. Square ass programming in handy.
For me, the greatest difficulty was in forming a list of questions, since many, with the exception of creating a class or an array, know nothing at all.
This is what I came up with as a result of experiments. You can go through the standard questions: OOP with examples, the scope of variables, overriding and overloading of methods, virtual functions. This will allow the applicant to understand that they are planning to take him as a programmer , and not as an elementary school teacher, to solve problems about the crossing of a wolf and a bunny across a bridge.
I am not a supporter of logical problems, since their solution does not give any information about the candidate, except for the fact that a person is able to solve problems of this type. If you do not agree - you can give an IQ test instead of an interview.
Here things are better. Before you is a person with experience and you have something to talk about. If you have enough experience, you can use what is stated below, if not, then a prepared list of interesting questions is a great option. After two dozen interviews, I realized that pulling information out of a person through dry interrogation is difficult and boring. Let him tell better himself.
Start the interview from afar. Find out what the person was doing in the past work, what role in the team he occupied, whether he had ever participated in the design of the software. Everyone loves to talk about themselves, and even more when they listen to them, so you turn the interrogation into a conversation and relieve some tension from the interviewee.
Listen to him calmly until he mentions the technology that interests you. And here you start asking questions, even better to say, ask how he, as a very serious engineer, would solve some problem.
Of course, you need to have in your head a list of questions that you would like to touch in order to direct the conversation in the right direction. This type of interview will allow you to check a very important quality of a person - his honesty. There was the following case. The person who came to the interview said that he had worked on the project on the leading roles, and that there were more than 50 tables in the database in his project, more than a dozen migrations and references to the database run in different streams and many more. However, when asked how work with the base was organized from many streams, there was no clear answer (see commandment 2). I think everyone understands that this person did not receive a place in our company.
After the conversation, go on the offensive. Most of all I love tasks like “and if”. Such tasks begin very simply, for example, “redefine the setter for a property”. After that, the task acquires various kinds of additional conditions, classes and restrictions.
For a setter, the next step may be the ability to access a property from many threads. At the same time there will be an occasion to talk about multi-threading in general, if this was not done by the “will” of the interviewee at the very beginning.
By all means avoid questions like “I know / do not know,” the answer to which can be given only if you read about it. An example of such a bad question is the question of the internal structure of a highly specialized class.
You must find the limit of knowledge of the interviewee, if a gap is found it is not necessary to spend 10 minutes on finishing moves, it is better to move on. This option will be more pleasant for the interviewee and more productive for you. (see commandment 1).
If, as a result of the interview, all the questions were answered - the price for such an interview is worthless. You did not give the interviewee the full potential.
Finally, I will touch on a controversial for many question. "Is it worth explaining the correct answer to a question?" In my opinion, if a person was close to solving a problem, the answer may be announced. However, if a person did not come close to an iota to solve the problem, I don’t see any reason to explain something to him.
How many times I was at the interviews, each time I remembered something that I wanted to ask after the farewell. These are the questions that I would like to find out for myself:
Remember: even the most well-organized interview may fail due to the complete lack of talent of the interviewer exactly, as well as the candidacy of the best candidate may be noted because of the insufficient experience of the interviewee.
All successful searches and high-class specialists.
This article will be useful to people who, by the will of fate, are forced to conduct interviews, but at the same time do not have the necessary experience and plan, as I once did. Everything described below is a conclusion from a large number of interviews conducted. But as they say, any coincidence of names or events with real ones is an accident.
Commandments
Commandment number one
Your task is to determine what the person knows, and not to show that you know more.
Anyone who interviews for the first time faces this. He perceives it as some sort of competition where he must, like the interviewee, show a class. This is not true. There is no doubt that you, as a person who asks questions, will be able to find a question in the depths of the Internet and on the secret pages of the manual that the interviewee cannot answer. But your task is not this.
')
Commandment number two
Your task is to find out what this person can do for your company now and in three months, and not what he could have done a year ago.
I had to interview people who had more experience than me more than once. The first time it put me in a stupor, it was somehow embarrassing to ask questions to a person who is older than you, and in the field of programming it works longer. But all the awkwardness vanished as soon as he could not give a clear answer to the elementary principles of working with multithreading. Although the portfolio was impressive, the real knowledge was shallow. You hire a person who will work with you in the future, and not who he was 2 years ago.
Commandment number three
Your task is to determine whether a person can join the team.
Regardless of the level of the interviewee, try to determine for yourself whether you can work with this person in a team, even if you know that you will not have to do this. Once, a friend came to the interview, who during the first 5 minutes managed to prank the HR manager and was far from the business tone throughout the entire interview, although he had some knowledge. After the interview, his candidacy was no longer considered, since no one wanted to work with him on the same team. In turn, you, no matter how you like a person, should be restrained and friendly, as you represent the whole company, and he only himself.
Things to pay attention to
I work at a small firm, and I don’t have at my disposal a crowd of HR managers who organize everything at the highest level, so I will describe some points that need to be monitored.
- The interview should be held in the negotiation room (the negotiation room). If the conversation is busy - postpone the interview. By and large, this room with you is the face of the company for the interviewee. And if you really need an employee, make sure that the “face” looks appropriate. In no case do not conduct an interview in the lobby of the office center or near your workplace with colleagues scurrying around. All this will not create a calm atmosphere and will not help form a person's pleasant opinion about the company. I, unfortunately, had to go in a similar situation.
- On the table must be a glass of water for the "guest". Tea and coffee are options, but water must be required. First, it’s pretty hard to talk for a long time. Secondly, you save the person from having to ask you for something during the interview. Finally, in the case of a temporary hitch, he will not sit and twist his fingers nervously in a Gordian knot, but simply take a glass of water.
- Conduct an interview without a leaf or laptop, otherwise you may get the impression that you yourself are not sure what to ask. Clearly formulate a question, having previously worked it out on colleagues. The interviewer must understand what you want from him.
- At the interview should ask questions one person. In this case, there may be several in the room, what would be with whom to discuss the results. Three in my opinion is optimal. Often, due to uncertainty, we strive to bring along a colleague who will insure us in difficult times. Because of this, the interview turns into a cross-examination with the participation of two bad policemen. This should not be (see commandment 1).
If the interview has a need to talk about several areas at once, for example, programming and project management. Then break the interview into 2 parts, so that the interviewer would first communicate with the first specialist, and then with the second. Avoid cross-examinations.
(this item is corrected after User comment: xoposhiy) - After the interview, do not be lazy directly on the summary to mark information about the applicant. All that you see fit: right or wrong answers, emotional impression from communicating with a person, etc.
After a couple of weeks and 6-7 interviews, you will thank yourself for this visionary decision when you have to invite a person to work. Plus, you have accumulated a good database. - Time limit At one time I had to face the demand from the HR manager to reduce the time of the interview to half an hour, they say people get very tired after long interviews and they have a bad impression about the company.
Feel free to send such proposals to all the devils. First of all, once the interview is conducted by you, then only on your shoulders is the entire burden of responsibility for hiring the person. And, therefore, in the case of the wrong choice to answer you too.
Secondly, people get tired of uninteresting and boring interviews rather than long ones.
I remember that I came out annoyed with 40-minute interviews on the list of standard questions, and it is quite another thing after 2 hours of a hard interview with author questions that I had never heard before. After the second, I learned something new, and at the first I just spent time. - In order to reduce the time, highlight a number of key questions, in the absence of an answer to which the interview can be shortened as much as possible without offending the person. Maybe in a year or two he will become a high-class specialist.
I had to conduct an interview for various positions, and below I will try to outline the main points that need to be taken into account.
Interview for junior programmer
The goal is to find out the learner's ability to learn.
First, find out where a person is studying or studying (I support the idea that you need to have an engineering education to work as a programmer, as this will allow you to speak the same language). God knows, people from the Conservatory of Music came to me for an interview. They took 2-month programming courses.
Learning can be partially compensated for by zeal. And here comes the education system. Find out what is the average score of the applicant, he learns for a fee or for free. Square ass programming in handy.
For me, the greatest difficulty was in forming a list of questions, since many, with the exception of creating a class or an array, know nothing at all.
This is what I came up with as a result of experiments. You can go through the standard questions: OOP with examples, the scope of variables, overriding and overloading of methods, virtual functions. This will allow the applicant to understand that they are planning to take him as a programmer , and not as an elementary school teacher, to solve problems about the crossing of a wolf and a bunny across a bridge.
- Try to come up with several tasks for the ingenuity and ingenuity of the interviewee. For example, what is Single Responsibility. Having listened to a person, you will understand how he acts when confronted with an unfamiliar task : in which direction does he move or simply falls into a stupor. It is important.
- Give a simple task, say, to add an element to an array and a leaf with a handle. This will make it possible to understand whether a person is able to write anything at all without prompting the environment.
- Invite the applicant to describe the classes that he would create to implement, say, the VK message pages. Based on this, it is possible to judge whether a person is able to think in the format of the PLO .
I am not a supporter of logical problems, since their solution does not give any information about the candidate, except for the fact that a person is able to solve problems of this type. If you do not agree - you can give an IQ test instead of an interview.
Interview at middle / senior programmer
Here things are better. Before you is a person with experience and you have something to talk about. If you have enough experience, you can use what is stated below, if not, then a prepared list of interesting questions is a great option. After two dozen interviews, I realized that pulling information out of a person through dry interrogation is difficult and boring. Let him tell better himself.
Start the interview from afar. Find out what the person was doing in the past work, what role in the team he occupied, whether he had ever participated in the design of the software. Everyone loves to talk about themselves, and even more when they listen to them, so you turn the interrogation into a conversation and relieve some tension from the interviewee.
Listen to him calmly until he mentions the technology that interests you. And here you start asking questions, even better to say, ask how he, as a very serious engineer, would solve some problem.
Of course, you need to have in your head a list of questions that you would like to touch in order to direct the conversation in the right direction. This type of interview will allow you to check a very important quality of a person - his honesty. There was the following case. The person who came to the interview said that he had worked on the project on the leading roles, and that there were more than 50 tables in the database in his project, more than a dozen migrations and references to the database run in different streams and many more. However, when asked how work with the base was organized from many streams, there was no clear answer (see commandment 2). I think everyone understands that this person did not receive a place in our company.
After the conversation, go on the offensive. Most of all I love tasks like “and if”. Such tasks begin very simply, for example, “redefine the setter for a property”. After that, the task acquires various kinds of additional conditions, classes and restrictions.
For a setter, the next step may be the ability to access a property from many threads. At the same time there will be an occasion to talk about multi-threading in general, if this was not done by the “will” of the interviewee at the very beginning.
By all means avoid questions like “I know / do not know,” the answer to which can be given only if you read about it. An example of such a bad question is the question of the internal structure of a highly specialized class.
You must find the limit of knowledge of the interviewee, if a gap is found it is not necessary to spend 10 minutes on finishing moves, it is better to move on. This option will be more pleasant for the interviewee and more productive for you. (see commandment 1).
If, as a result of the interview, all the questions were answered - the price for such an interview is worthless. You did not give the interviewee the full potential.
Finally, I will touch on a controversial for many question. "Is it worth explaining the correct answer to a question?" In my opinion, if a person was close to solving a problem, the answer may be announced. However, if a person did not come close to an iota to solve the problem, I don’t see any reason to explain something to him.
How to behave at the interview
- I deliberately do not touch the topic of wages, as in the field of IT it is very individual. The only thing I can say is ask so much that you want to work and you do not feel deceived.
- Do not be lazy to take half an hour before the interview to repeat the main points. Believe me, this time will pay off with interest. I remember I was interviewed by a person who answered the question “What is OOP?”, Replied, “Well, Eh ... This is necessary for inheritance.”
- Do not get a tie or a suit, if you do not wear it in everyday life. I’m more embarrassed by the person in the stranglehold that he is not used to than in the bike If the company has a dress code - they will tell you about it. The main thing is to look neat.
- Do not lie about your merits. The lie is easily revealed.
- Prepare in advance for questions like: “which project did you like the most?” - this question is needed to start a conversation.
“Why did you leave your previous job?” - I won’t say how to answer it, but the worst answer I heard was: “I was more offered elsewhere”. After such an answer to the person there are many questions.
How many times I was at the interviews, each time I remembered something that I wanted to ask after the farewell. These are the questions that I would like to find out for myself:
- the actual amount you will receive on your hands (after taxes and God knows what else);
- the format of the room in which you will work: open space / separate rooms. It is even desirable to see;
- equipment provided: monitors, laptops;
- ask in detail about the projects, team sizes and your role on them;
- find out who will be your immediate superior. This may be the person who conducted the interview. And if it is not, then you can ask to meet him.
Conclusion
Remember: even the most well-organized interview may fail due to the complete lack of talent of the interviewer exactly, as well as the candidacy of the best candidate may be noted because of the insufficient experience of the interviewee.
All successful searches and high-class specialists.
Source: https://habr.com/ru/post/283880/
All Articles