Interviewing - Interviewer's View
Long ago, back in ancient times, I wrote an article for Habr - Interview. The look of the applicant .
Over the 10 years that have passed since then, much has changed: the number of projects in my portfolio, both successful and successfully failed, has increased; dozens of books were read, dozens of trainings and vidosikov on YouTube were viewed, both useful and just “time eaters”, as well as dozens of interviews, but which I had already conducted. After a while, there was a revision of views, but this is not exactly what I want to talk about in this discussion article.
It's time to create a sequel. Meet my # 10YearChallenge, only now from the interviewer.
The statement that I am so awesome and now with a flick of the pen or by pressing buttons on the keyboard will give the most useful advice and everything will be fine - fundamentally deceitful. The purpose of this article is the exchange of experience and, perhaps, to give beginners some general recommendations, since The person interviewing the candidate is the face of the company. You want to go to the office, where the interviewer or HR \ Recruiter assholes with experience and show it from the threshold at the entrance? Me not.
In this section I am not going to reveal the secrets of Pusinel, only a small digression telling about me. Interviews have become my responsibility for the last 5-6 years. Now I am able to interview candidates from the Junior-developer level, to the Junior-manager level, developers only in a certain technology stack in which my growth and development took place, i.e. I will not agree in life to interview the C ++ developer, since I have come across this programming language for a very long time.
In total, I had about two hundred interviews, there were years / months when I conducted 2-3 interviews per week, there was a time when I spent only 7 interviews in a year. Now I consider 1 interview per week / two comfortable.
I will make a reservation right away, I only do technical interviews, I do not issue a job offer to the company, although some time ago I had such powers.
Before the interview, I always get a candidate's resume. It is worth noting that the content sometimes depends on the region, so there is a summary in which it is listed that the candidate worked with various technologies and just annealed in each of them. It always looks a little suspicious, because I know only a few people who fumble in Java and .Net (for example), and this is an exception rather than the rule. With the same full-stack, a developer who can in both .Net and JS is a completely normal phenomenon, although there is something more and something less here as well.
Excuse me for a minute: unfortunately at the interview I come with a laptop and sit with my nose buried in it, only occasionally exaggerating, and if I used to treat such actions with a bit of skepticism, now I’ve got to know what to do with the candidate, then write a detailed conclusion , you will not make a mark, and the candidates 2,3,4 per week and everything, the interviewer cannot write / recall details for the review and the interviewee’s personality is smeared in general, for aggravation you can add what came out of the interview and you need to return to the project and still connected with him, and there their heads and bustle.
and closed the kerchief . He introduced himself and explained what we are going to do now.
On average, my interviews last an hour or more, usually up to 2x, of course I try not to delay them with blank blah blah blah. If the question is: “what for? it is possible for 10, 15, 30 minutes to find out whether it suits you or not! ”, then the answer can be found in the arguments further. ;)
The next step I ask is to tell the candidate about yourself, your experience over the past few years. An inquisitive reader will immediately have a legitimate question: “Why? You did not read the summary before the interview? Bottom!".
I read, but as practice shows, sometimes people send summaries of obsolete, not reflecting the latest achievements. No, this is not human laziness, sometimes a person does not have time, sometimes other tasks, sometimes updated in a hurry. Moreover, in the IT field, work is often looking for a candidate, and not vice versa - this must be understood and accepted.
Further, as a rule, there are 2 possible developments:
In the first case, you need to listen to the candidate very carefully, make notes and ask deeply questions based on the results of the notes. As practice shows, there are cases when people are well versed in various issues, in addition, they have quite a steep skill of self-presentation - handsome, I applaud so standing! Sometimes it happens the other way around, they have scored all sorts of names, terms and, not only have they shoved it all in the summary, but also decided to show these words at the interviewthere are even remote regions where it is very common . There is exactly the same approach, we listen very carefully to make notes and then dig deeply.
Immediately, I note that it is worth separating 2 approaches to questions - the availability of practical experience and the availability of theoretical knowledge.
Therefore, when a person talks about his previous experience, he shows that he really “felt” in practice, and then it was already possible to throw theoretical questions to have an idea that the person did not use the microscope to put crutches into the sleepers.
If a person wants to draw, explain what is on a piece of paper or on a drawing board - please, for example, I will only be glad of such clarity.
Also, I will obviously push the candidate to the arguments "out loud", because this is quite a useful process, both from the point of view of the applicant - he demonstrates his skills to reason and draw conclusions, and from the point of view of the interviewer - perhaps the candidate does not have enough small things so that a person can reveal from a positive point and demonstrate his knowledge, which is like a small pebble, able to cause a huge rockfall.
Thus, we come to the conclusion that one of the main tasks of the interviewer is to help the candidate to demonstrate his knowledge and practical skills . Therefore, the interview can take more than an hour.
To ask theoretical questions is quite useful and interesting, it shows the breadth of views and knowledge of a person, and the ability to find information in various sources. I especially respect people who, when answering a theoretical question, can weave in some kind of reference from their practical experience.
I will not particularly linger on the point of verification of the theory, I would just note that you need to go through the theory from those sections that the person stated, but also do not forget to ask around what lies next. As an example, a person can tell that he sawed the architecture for a project, and by asking a few more clarifying questions: “how many people were on the project?” Or “and what other responsibilities did you have?” You can find out that the person is also quite a team of 10 people successfully ruled, but it flew out of my head for an interview, or the interviewer did not ask the right questions. So you can miss valuable skills.
“Well, okay, the theory is quite easy to interview, but how are we going to test the practice? Will we put the computer behind and make the code write? Or are you starting to drown for a test? ”
I have been opponents of test items, and remain adherent to this theory. A person should not spend his personal time on solving problems that are not paid, but if the interviewer cannot understand a person is able to write code without resorting to a test one, then such an interviewer is bottom. Moreover, the law establishes the norm of the probationary period, which works in both directions: the employee understands the company suits him, whether the expectations were met, the company in turn can evaluate in more detail the professional qualities of the person.
"How are you going to check?"
I will ask you to jot down a small piece of code, without carping at the syntax, the accuracy of method calls, and other nonsense. Sheet of paper or whiteboard - no difference. We do not check how much a person remembers all the signatures of the overloaded methods of some class. At the same time, I consider writing a large piece of code unnecessary, it is quite normal for an interview to give a small piece of code, for example, my favorite “DI” concept test, and ask for a simple method to be added, indicating what you can write, or you can say with words. I often have guys who glance at the code, they can say: "Well, here you need to use DI, you can, and you can, then we do it and this." If a person can explain everything in less than a minute, why bother him with writing? The same applies to other technical skills.
A little more complicated is the case with the skills of designing, for example, a database, here I can ask and sketch on the board, but I shouldn’t be driven to any kind of notation.
“Write code again? Only through the code to check the availability of practical skills possible?
Not at all, if a person begins to talk about any cases from practice or the use of certain tools and skills, then it is only logical to complicate the situation and ask him how he would act. Or give a situation from personal experience and see how her candidate would decide. I admit, honestly, I still go on interviews as a candidate, both technical and managerial, though if the technical interview is in several stages, I “burn” and report that the code I am writing is not enough, but mostly it is architecture and control projects. At one of these technical interviews, I was asked an interesting question how to make the first deployment with the initial configuration of the infrastructure in a fully closed system, i.e. it does not “stick” to the Internet, and access from outside to it is not from the word at all, but you cannot send a specially trained person. In my opinion - quite an interesting question.
Perhaps one of the most controversial topics, because From the point of view of the interviewer, you need to have a clear understanding of how, where and why we will interview the candidate. Consider in order:
I note that when the interviewer began his activities, he relied on notes from his previous article and tried not to make mistakes that he observed in others. Although my path was thorny and not painless.
In this article, calling for a discussion, I deliberately omitted ways to ask questions, because This is the choice of each, and the volume of what has been written has turned out to be large.
I hope this article will be useful for all who begin their way in interviews and do not forget that you should like it, otherwise you will only have negative and demotivation, which will not positively affect anyone.
Over the 10 years that have passed since then, much has changed: the number of projects in my portfolio, both successful and successfully failed, has increased; dozens of books were read, dozens of trainings and vidosikov on YouTube were viewed, both useful and just “time eaters”, as well as dozens of interviews, but which I had already conducted. After a while, there was a revision of views
It's time to create a sequel. Meet my # 10YearChallenge, only now from the interviewer.
What for? Why? For whom?
The statement that I am so awesome and now with a flick of the pen or by pressing buttons on the keyboard will give the most useful advice and everything will be fine - fundamentally deceitful. The purpose of this article is the exchange of experience and, perhaps, to give beginners some general recommendations, since The person interviewing the candidate is the face of the company. You want to go to the office, where the interviewer or HR \ Recruiter assholes with experience and show it from the threshold at the entrance? Me not.
Boring and tedious background about yourself, which you can and miss
In this section I am not going to reveal the secrets of Pusinel, only a small digression telling about me. Interviews have become my responsibility for the last 5-6 years. Now I am able to interview candidates from the Junior-developer level, to the Junior-manager level, developers only in a certain technology stack in which my growth and development took place, i.e. I will not agree in life to interview the C ++ developer, since I have come across this programming language for a very long time.
In total, I had about two hundred interviews, there were years / months when I conducted 2-3 interviews per week, there was a time when I spent only 7 interviews in a year. Now I consider 1 interview per week / two comfortable.
I will make a reservation right away, I only do technical interviews, I do not issue a job offer to the company, although some time ago I had such powers.
About the resume and the beginning of the conversation
Before the interview, I always get a candidate's resume. It is worth noting that the content sometimes depends on the region, so there is a summary in which it is listed that the candidate worked with various technologies and just annealed in each of them. It always looks a little suspicious, because I know only a few people who fumble in Java and .Net (for example), and this is an exception rather than the rule. With the same full-stack, a developer who can in both .Net and JS is a completely normal phenomenon, although there is something more and something less here as well.
Not recorded - forgot. The best memory is paper.Therefore, I came, explained why I needed a laptop and, if the candidate did not mind, opened the notebook
On average, my interviews last an hour or more, usually up to 2x, of course I try not to delay them with blank blah blah blah. If the question is: “what for? it is possible for 10, 15, 30 minutes to find out whether it suits you or not! ”, then the answer can be found in the arguments further. ;)
The next step I ask is to tell the candidate about yourself, your experience over the past few years. An inquisitive reader will immediately have a legitimate question: “Why? You did not read the summary before the interview? Bottom!".
I read, but as practice shows, sometimes people send summaries of obsolete, not reflecting the latest achievements. No, this is not human laziness, sometimes a person does not have time, sometimes other tasks, sometimes updated in a hurry. Moreover, in the IT field, work is often looking for a candidate, and not vice versa - this must be understood and accepted.
Further, as a rule, there are 2 possible developments:
- The candidate talks about himself. What he (and) good and generally well done and how lucky the company, when she hires him. In general, the words of a modern classic:
The whole world will change immediately
It will be more beauty
And shine like rhinestones,
Smiles and bring bridges. - The candidate does not really know how \ wants to advertise himself, and why, when there is work? More \ less favorite, moreover, well-paid.
In the first case, you need to listen to the candidate very carefully, make notes and ask deeply questions based on the results of the notes. As practice shows, there are cases when people are well versed in various issues, in addition, they have quite a steep skill of self-presentation - handsome, I applaud so standing! Sometimes it happens the other way around, they have scored all sorts of names, terms and, not only have they shoved it all in the summary, but also decided to show these words at the interview
Questions and knowledge / skill tests
Immediately, I note that it is worth separating 2 approaches to questions - the availability of practical experience and the availability of theoretical knowledge.
The theory without practice is dead and fruitless, and practice without theory is useless and destructive. © by Chebyshev.In my understanding, a good engineer is a person who combines both practical experience and theoretical knowledge, because tasks need not only to be able to do from fence to dinner, to do it well (read professionally), but sometimes to explain what has been done to colleagues, and simply not to look profane in the eyes of others.
Therefore, when a person talks about his previous experience, he shows that he really “felt” in practice, and then it was already possible to throw theoretical questions to have an idea that the person did not use the microscope to put crutches into the sleepers.
If a person wants to draw, explain what is on a piece of paper or on a drawing board - please, for example, I will only be glad of such clarity.
Also, I will obviously push the candidate to the arguments "out loud", because this is quite a useful process, both from the point of view of the applicant - he demonstrates his skills to reason and draw conclusions, and from the point of view of the interviewer - perhaps the candidate does not have enough small things so that a person can reveal from a positive point and demonstrate his knowledge, which is like a small pebble, able to cause a huge rockfall.
Thus, we come to the conclusion that one of the main tasks of the interviewer is to help the candidate to demonstrate his knowledge and practical skills . Therefore, the interview can take more than an hour.
Test of practical and theoretical skills - in questions and answers
To ask theoretical questions is quite useful and interesting, it shows the breadth of views and knowledge of a person, and the ability to find information in various sources. I especially respect people who, when answering a theoretical question, can weave in some kind of reference from their practical experience.
I will not particularly linger on the point of verification of the theory, I would just note that you need to go through the theory from those sections that the person stated, but also do not forget to ask around what lies next. As an example, a person can tell that he sawed the architecture for a project, and by asking a few more clarifying questions: “how many people were on the project?” Or “and what other responsibilities did you have?” You can find out that the person is also quite a team of 10 people successfully ruled, but it flew out of my head for an interview, or the interviewer did not ask the right questions. So you can miss valuable skills.
“Well, okay, the theory is quite easy to interview, but how are we going to test the practice? Will we put the computer behind and make the code write? Or are you starting to drown for a test? ”
I have been opponents of test items, and remain adherent to this theory. A person should not spend his personal time on solving problems that are not paid, but if the interviewer cannot understand a person is able to write code without resorting to a test one, then such an interviewer is bottom. Moreover, the law establishes the norm of the probationary period, which works in both directions: the employee understands the company suits him, whether the expectations were met, the company in turn can evaluate in more detail the professional qualities of the person.
"How are you going to check?"
I will ask you to jot down a small piece of code, without carping at the syntax, the accuracy of method calls, and other nonsense. Sheet of paper or whiteboard - no difference. We do not check how much a person remembers all the signatures of the overloaded methods of some class. At the same time, I consider writing a large piece of code unnecessary, it is quite normal for an interview to give a small piece of code, for example, my favorite “DI” concept test, and ask for a simple method to be added, indicating what you can write, or you can say with words. I often have guys who glance at the code, they can say: "Well, here you need to use DI, you can, and you can, then we do it and this." If a person can explain everything in less than a minute, why bother him with writing? The same applies to other technical skills.
A little more complicated is the case with the skills of designing, for example, a database, here I can ask and sketch on the board, but I shouldn’t be driven to any kind of notation.
“Write code again? Only through the code to check the availability of practical skills possible?
Not at all, if a person begins to talk about any cases from practice or the use of certain tools and skills, then it is only logical to complicate the situation and ask him how he would act. Or give a situation from personal experience and see how her candidate would decide. I admit, honestly, I still go on interviews as a candidate, both technical and managerial, though if the technical interview is in several stages, I “burn” and report that the code I am writing is not enough, but mostly it is architecture and control projects. At one of these technical interviews, I was asked an interesting question how to make the first deployment with the initial configuration of the infrastructure in a fully closed system, i.e. it does not “stick” to the Internet, and access from outside to it is not from the word at all, but you cannot send a specially trained person. In my opinion - quite an interesting question.
About the difference of interviews
Perhaps one of the most controversial topics, because From the point of view of the interviewer, you need to have a clear understanding of how, where and why we will interview the candidate. Consider in order:
- Since I was engaged in hiring and in a small company and in a large enough, then there are differences. When hiring a large company, it is important to understand that a person knows and knows how The interviewer is obliged to determine the list of skills and the depth of possession of these skills. This is due to the fact that you can find a project suitable for the skills and abilities of the candidate.
- Project interview or interview in a small company. I do not specifically share these two concepts because, by their mechanism, the approaches in these interviews are very similar. In these interviews, you have one or more candidates, then how lucky you are, and you try to understand how much the candidate is suitable for you, according to the skills that he owns. At the same time, the technical interviewer should be involved in the project, and not be invited by, since such a person has an idea of the need for certain skills and the ability to sacrifice them or increase the missing ones within a reasonable time.
Epilogue
I note that when the interviewer began his activities, he relied on notes from his previous article and tried not to make mistakes that he observed in others. Although my path was thorny and not painless.
In this article, calling for a discussion, I deliberately omitted ways to ask questions, because This is the choice of each, and the volume of what has been written has turned out to be large.
I hope this article will be useful for all who begin their way in interviews and do not forget that you should like it, otherwise you will only have negative and demotivation, which will not positively affect anyone.
Source: https://habr.com/ru/post/437386/