A couple of tips for technical interviews
I have been doing technical interviews with candidates for the position of Software engineer for quite a long time and there are several dozen of them on my account. Today I will try to formulate the main points that I personally, as an interviewer, seem to be quite important.
The advice is quite obvious (although, as practice shows, there are those who do not know these obvious things) and subjective.
')
1. When answering general questions, remember that the interviewer may be unaware of what you are talking about .
It happens that at the very beginning of the interview the interviewer asks general questions - for example, “Tell us about Project X, on which you worked at Y” (the list of projects is taken from the summary) or “Tell us about the most favorite technology” or something else. Answering this question it is very important to remember that you are not talking about the project to yourself, but to the interviewer - and your task is for the interviewer to understand you.
We should not assume that the interviewer is very smart and knows everything - he is probably really smart, but he knows for sure not all. And what may be obvious to you because you have been doing this for a couple of years in a row can be a completely new area for the interviewer. And so do not hesitate to start from the very basics and from time to time ask if the interviewer understands you.
2. Do not google during an interview.
It happens that the interviewer asks a question, the answer to which you dimly remember, and if only a small glance to look at Wikipedia ... So - do not do that. Knocking the keys is usually quite well heard through the phone and the answer, which is read out from Wikipedia without much understanding - is also quite easy to distinguish. Needless to say, what impression does the candidate leave the interviewer?
3. Do not lie to the resume.
There are things that are relatively easy to verify - knowledge of some technology, for example. And things that are difficult to verify - for example, if the candidate wrote that he was in the top 100 on topcoder (this is the site where programming competitions are held). Personally, I never check it at the level “And under what nickname are you there?”, But from a candidate who in the top 100 on the topcoder I expect that he will write simple things without regaining consciousness (I have already interviewed olympiadians - and in my opinion experience is what happens). And if it suddenly turns out that the candidate is writing the code slowly, with a bunch of errors, then this most likely means that he feels very bad, or he has entered incorrect information in the resume.
Of course, it is not within the competence of the interviewer to assess the status of the candidate, but I will definitely mention this discrepancy in my review.
4. Do not try to "talk" the interviewer.
If the interviewer asked a question - for example, “What is the difficulty with bubble sorting?” - but you don’t remember, whether it is O (N ^ 2), or O (N), or O (NlogN), then by no means No need to disguise your ignorance under a bunch of phrases that you hope that the interviewer will take for the correct answer. The interviewer listens to you very carefully and notices all attempts to accidentally divert him from a question to which the candidate does not know the answer. It is better to just admit that you do not exactly remember and think out loud - most likely you will come to the correct answer and so.
5. Speak and explain. But not too much.
There are two extremes - a candidate who is silent and says almost nothing, and even a question like “Tell me what you think about X, what advantages and disadvantages X has”, he manages to answer with a maximum of one sentence. And the candidate who speaks and explains everything down to the last comma - "Here I put a comma, because this is the syntax of the language." Both the first and the second type of candidates are very difficult to interview - one of them has to pull answers with ticks, while others are constantly cut short in mid-sentence.
Explanations should be just right - for the interviewer to understand the essence, but at the same time he did not feel that the candidate always wants to break into an explanation of the trivial basics.
6. Test the code yourself.
During the interview, you wrote some code that you think is correct. At this point, it is important to test this code without waiting for the interviewer to tell you, "Now, let's test the code with a simple example 123." During testing, it is very important to check the so-called corner cases - for example, null, empty lines and arrays, negative numbers, zero - and even more important to make sure that the code really works on simple examples. Because the candidate who tests the code, but during the test does not notice a very gross error, usually does not make the best impression.
7. Do not try to please the interviewer.
In the film “Bad teacher” there is one thing - one of the main characters asks another about sharks:
1: What do you think about sharks?
2: Oh, sharks are such terrible fish, I heard that they eat people ...
1: But some of them do not eat anyone, and very cute ones ...
2: Oh yes, it's terrible that people are destroying sharks, because sharks are an endangered species and God created them that way. They are beautiful creatures ...
1: But they eat people ...
2: Yes, yes, it is terrible, entire families are destroyed by sharks ...
I do not remember exactly, but the essence is approximately the same. So, do not conduct a "conversation about sharks" with the interviewer. The interviewer asks a question to find out what the candidate thinks about this or that aspect, and not to hear that the candidate agrees with him in any case.
8. Try to remove everything that will prevent you from speaking clearly.
This may seem obvious, but I still mention - do not chew gum during an interview. And do not eat too. If you have a piercing in a language that is wont to make a clicking sound when you speak, then at the time of the interview it is also best to get it.
And most importantly, the question that the interviewer himself consciously or subconsciously asks is “Would I like to work in the same team with this person?”. And the answer to this question is made up not only of the knowledge and skills of the candidate, but also of the ability to clearly and clearly express his thoughts, abilities to listen, and many other little things.
The advice is quite obvious (although, as practice shows, there are those who do not know these obvious things) and subjective.
')
1. When answering general questions, remember that the interviewer may be unaware of what you are talking about .
It happens that at the very beginning of the interview the interviewer asks general questions - for example, “Tell us about Project X, on which you worked at Y” (the list of projects is taken from the summary) or “Tell us about the most favorite technology” or something else. Answering this question it is very important to remember that you are not talking about the project to yourself, but to the interviewer - and your task is for the interviewer to understand you.
We should not assume that the interviewer is very smart and knows everything - he is probably really smart, but he knows for sure not all. And what may be obvious to you because you have been doing this for a couple of years in a row can be a completely new area for the interviewer. And so do not hesitate to start from the very basics and from time to time ask if the interviewer understands you.
2. Do not google during an interview.
It happens that the interviewer asks a question, the answer to which you dimly remember, and if only a small glance to look at Wikipedia ... So - do not do that. Knocking the keys is usually quite well heard through the phone and the answer, which is read out from Wikipedia without much understanding - is also quite easy to distinguish. Needless to say, what impression does the candidate leave the interviewer?
3. Do not lie to the resume.
There are things that are relatively easy to verify - knowledge of some technology, for example. And things that are difficult to verify - for example, if the candidate wrote that he was in the top 100 on topcoder (this is the site where programming competitions are held). Personally, I never check it at the level “And under what nickname are you there?”, But from a candidate who in the top 100 on the topcoder I expect that he will write simple things without regaining consciousness (I have already interviewed olympiadians - and in my opinion experience is what happens). And if it suddenly turns out that the candidate is writing the code slowly, with a bunch of errors, then this most likely means that he feels very bad, or he has entered incorrect information in the resume.
Of course, it is not within the competence of the interviewer to assess the status of the candidate, but I will definitely mention this discrepancy in my review.
4. Do not try to "talk" the interviewer.
If the interviewer asked a question - for example, “What is the difficulty with bubble sorting?” - but you don’t remember, whether it is O (N ^ 2), or O (N), or O (NlogN), then by no means No need to disguise your ignorance under a bunch of phrases that you hope that the interviewer will take for the correct answer. The interviewer listens to you very carefully and notices all attempts to accidentally divert him from a question to which the candidate does not know the answer. It is better to just admit that you do not exactly remember and think out loud - most likely you will come to the correct answer and so.
5. Speak and explain. But not too much.
There are two extremes - a candidate who is silent and says almost nothing, and even a question like “Tell me what you think about X, what advantages and disadvantages X has”, he manages to answer with a maximum of one sentence. And the candidate who speaks and explains everything down to the last comma - "Here I put a comma, because this is the syntax of the language." Both the first and the second type of candidates are very difficult to interview - one of them has to pull answers with ticks, while others are constantly cut short in mid-sentence.
Explanations should be just right - for the interviewer to understand the essence, but at the same time he did not feel that the candidate always wants to break into an explanation of the trivial basics.
6. Test the code yourself.
During the interview, you wrote some code that you think is correct. At this point, it is important to test this code without waiting for the interviewer to tell you, "Now, let's test the code with a simple example 123." During testing, it is very important to check the so-called corner cases - for example, null, empty lines and arrays, negative numbers, zero - and even more important to make sure that the code really works on simple examples. Because the candidate who tests the code, but during the test does not notice a very gross error, usually does not make the best impression.
7. Do not try to please the interviewer.
In the film “Bad teacher” there is one thing - one of the main characters asks another about sharks:
1: What do you think about sharks?
2: Oh, sharks are such terrible fish, I heard that they eat people ...
1: But some of them do not eat anyone, and very cute ones ...
2: Oh yes, it's terrible that people are destroying sharks, because sharks are an endangered species and God created them that way. They are beautiful creatures ...
1: But they eat people ...
2: Yes, yes, it is terrible, entire families are destroyed by sharks ...
I do not remember exactly, but the essence is approximately the same. So, do not conduct a "conversation about sharks" with the interviewer. The interviewer asks a question to find out what the candidate thinks about this or that aspect, and not to hear that the candidate agrees with him in any case.
8. Try to remove everything that will prevent you from speaking clearly.
This may seem obvious, but I still mention - do not chew gum during an interview. And do not eat too. If you have a piercing in a language that is wont to make a clicking sound when you speak, then at the time of the interview it is also best to get it.
And most importantly, the question that the interviewer himself consciously or subconsciously asks is “Would I like to work in the same team with this person?”. And the answer to this question is made up not only of the knowledge and skills of the candidate, but also of the ability to clearly and clearly express his thoughts, abilities to listen, and many other little things.
Source: https://habr.com/ru/post/123831/
All Articles