About the technical interview
You have a product, a well-established team and funding. You (the team) worked well, and the management is ready to pay more money to hire a person in order to speed up development, improve quality and be able to spend resources on technological development of the product. You have already placed an ad on hh with a good salary and a vivid description that would be of interest to you, 20 candidates have been selected, and tomorrow you will begin to conduct interviews. It remains only to figure out what to ask. Common situation? Then welcome under cat.
Perhaps the situation is a bit utopian, but many cases also fall within the scope of this article. Exceptions are companies that “need a person yesterday” or companies that do not need a new person at all, they simply “watch the market” and (or) hope to find a “rare professional”.
In other words, this is an article for those who want to invest money and energy in making the team stronger.
To begin with, we note that it is extremely harmful to hire a person for immediate need. Say, now you have a little "slow" development of the server. Does this mean you need to hire a server-side programmer? Actually, no. If you have a fairly active development, then the priority of different pieces will inevitably change. In this sense, it is foolish to hire a person for the task for the next month. After all, a month will pass, but the person will remain. And if this month you patch a hole in the server-side development, then the next one will find out that the server-side is written faster than the interface is riveted. And what next month should I hire a UI programmer? Or dismiss the “weak link” in the server-side? No, it's worth a different approach. See what you did before in product development. Ask for sales, investors or whoever defines goals for development, and try to build a picture of what is waiting for you, say, a year in advance. Now imagine what kind of person would help you work more effectively in the past and in the future. I hope you have more than one person. Most likely it turns out that you can strengthen the team here, and here. And if it turns out to be too strong somewhere (and, correspondingly, somewhere too thin), then someone from the existing team may agree to “switch” the type of activity.
So, you sketched out a few portraits of "ideal" candidates. It is time to conduct a technical interview. By the way, I hope in your company it is the technical interview that influences the decision to hire employees? Often they speak of the company as a “family” or “a team where it's nice to spend time”. So, the company is still not a family. And not friends with whom you go bowling. Of course, if a person is sick with kleptomania or leprosy, then it is dangerous to take him to work, even if he was the best to have a technical interview. But do not get too hung up on personal qualities. In principle, before or after a technical interview, it is necessary to find out if a person does not throw out some kind of trick, and in this sense such a “non-technical” interview will have the role of a “threshold” - the one who does not pass in the company will not work exactly, but if it passes, it doesn’t matter whether it is the “soul of the company” or just a conscientious worker. But this and all, in fact, all other decisions should be determined by the technical interview. If your HR company pesters candidates with questions about their career aspirations and “who do they see themselves in 10 years” or “why should the company hire you”, then it’s too early for you to look for technical specialists. First you need to find a new HR.
')
But what to ask at the technical interview? Make a test? Find out what the person did in the past job? Ask a tricky question? Give a puzzle with braingames.ru?
Let's look at these options in order.
A test may seem like a good thing to save time. However, it is difficult enough to make a good test - it is necessary to spend a lot of time on this task. A bad test can exclude only candidates who have few interviewers and who do not know the answers to “typical” questions. A very bad test can weed out really cool candidates who just did a bit of other things. In general, the test is just some primary filter. You can not hire a person who could not answer the five trivial in your opinion questions. But you definitely shouldn't hire a person after the test without asking him a word.
What did you do at your last job? Well, you know, what the applicant did in his past job, he will not be involved in you. In principle, you can ask such a question to find a topic for conversation. But honestly, it looks like a waste of time. I will give an example from my practice.
Total - what have we learned? Never mind. Some complicated project. It is not really clear what the project is, what exactly this employee did, what he eventually learned to do well. We squandered 5 minutes to find out nothing about a person. Of course, you can spend half an hour and sort everything out on the shelves. But there are two "but."
First, appreciate the time. If you spend 4 hours for each candidate, then you can simply “not reach” the really worthwhile one. In general, in my opinion, the interview should be strictly limited to the time frame, say one hour. And try to shake out for this hour from a person everything you need to make a decision.
Secondly, do not dwell on who the person was. Try to evaluate what he could be in your company. Does your candidate say that in the last work you did the module that you did in the past month? So maybe in the last work there are cool business processes and a mountain of ready-made code, and you would have made this module exactly the same as you did? Or did it seem to you that in the previous work the candidate did not do anything remarkable? It may very well be. But maybe this is a talented person who lived in third-rate "horns and hooves", and you will reveal his full potential! Believe me, in many situations it is worth fighting for such a person even more than for an established specialist.
Should I ask something tricky? Let's say yesterday you read in a habr that it turns out that the hash code in Java is not an address (as you always thought), but a random number, and you wonder if the candidate knows this. Or you picked the nixes last week and found out that "[" is not part of the bash script as a language, but a regular program named "[". Would it be helpful to find out if this is known to the candidate?
There is again try to lose the question and answer options.
Role play.
And the second option:
You have spent 3 minutes on this question. How do you compare the first and second candidate? Can you say that one of them is better than the other? Maybe the second one is scrolling at leisure grepcode. Or read Habr instead of work. And maybe not instead. But does this mean something to you?
Not that it doesn’t matter whether a person knows whether or not a subtlety of realization On the contrary - I think it is very important to know the little things. A person who knows assembler is more valuable to me than someone who does not know him, even when I am looking for a Java developer. But, unfortunately, there are so many trifles that the direct question “Did you know that?” Almost never carries meaning. We cannot ask about hundreds of things, because we have limited time.
So what to ask?
It seems to me that it is best to conduct a conversation, in the vein of what you usually do and watch how the candidate solves the problems you often solve.
Let's say your application has UI logic and server code. Ask the candidate what he thinks is more interesting.
Server code? Fine. Let's imagine some typical piece of code in your program. We are interested in what questions a candidate has, and how he links theoretical knowledge with practical needs.
Let's say this problem:
There is a code snippet
Question to the candidate - suppose in this code we need to sort the list in alphabetical order before “Some processing”. What will you do? By the way, yes, you can immediately tell the candidate about Collections.sort - we do not check the "vocabulary".
Put our candidate wrote something like
(I hope our candidate solved this problem in this way and did not start sorting a).
However, the solution of the problem is not the point here. The main discussion.
Why did he create a new list and not use the old one? Is it always right?
Why used ArrayList and not something else? Does he know what else to eat?
The most interesting is that the discussion here can be almost endless. The candidate will say that ArrayList is better because it is random access, and you say that sort still copies the data to the array before sorting, and then returns it back. Has the ArrayList become better now, according to the candidate? How, no longer? Or anyway better?
Conversation with the candidate should reveal the way of his thoughts. See how many details he knows. How does it react to something new? And most importantly, can he properly dispose of the information you give him? After all, the abstract "knowledge of everything" is usually not particularly important, in the end there are colleagues nearby and the problem issue can often be discussed. Colleagues can tell, but they will not write code instead of a new employee, so try to understand, can he, after hearing the advice, write a program better?
Or let's say another example.
Do not ask "what is the garbage collector." Do not ask "how many generations are there." What is the difference how much. What difference can a person tell or not how gc works - for your work it may be important only if a person can correct the performance problem if it arises, but can he tell a sentimental story about assembly for generations or is there a concurrent mark sweep gc.
I'm not saying that someone can solve any interesting problems with GC without knowing how it works. One time, of course, may be lucky. But in practice, knowledge is extremely important. The problem is different - not everyone who can tell how something works can fix the problem with this something. And, generally speaking, intuition, general technical knowledge is often more important for solving a problem than reading a description of an algorithm somewhere.
For example, for gc it will be good to bring again some practical puzzle.
Say, "you started the program with a 2 gigabyte hip and it works slowly, what will you do?".
Will it be faster? And the most interesting, and isn't it worth asking before the answer to this question, but what is “faster” for me? See if the candidate understands the difference between throughput and latency. Do not ask what it is and what is the difference. If a candidate in the above described formulation of the problem does not occur to ask such trivial questions, it means that in practice he will not have these questions. However, do not forget that we are in conversation. If the candidate jumped off the bat, stop him, tell us about the different performance characteristics. The candidate has never heard of them, but he immediately realized that hip growth may improve one, but will definitely worsen the other? Well, that's great!
Such examples are infinite. The most pleasant thing is that such puzzles are invented elementary, and they don’t have a number - you can ask each new candidate about different things and adapt the puzzles for a particular candidate.
Perhaps the situation is a bit utopian, but many cases also fall within the scope of this article. Exceptions are companies that “need a person yesterday” or companies that do not need a new person at all, they simply “watch the market” and (or) hope to find a “rare professional”.
In other words, this is an article for those who want to invest money and energy in making the team stronger.
To begin with, we note that it is extremely harmful to hire a person for immediate need. Say, now you have a little "slow" development of the server. Does this mean you need to hire a server-side programmer? Actually, no. If you have a fairly active development, then the priority of different pieces will inevitably change. In this sense, it is foolish to hire a person for the task for the next month. After all, a month will pass, but the person will remain. And if this month you patch a hole in the server-side development, then the next one will find out that the server-side is written faster than the interface is riveted. And what next month should I hire a UI programmer? Or dismiss the “weak link” in the server-side? No, it's worth a different approach. See what you did before in product development. Ask for sales, investors or whoever defines goals for development, and try to build a picture of what is waiting for you, say, a year in advance. Now imagine what kind of person would help you work more effectively in the past and in the future. I hope you have more than one person. Most likely it turns out that you can strengthen the team here, and here. And if it turns out to be too strong somewhere (and, correspondingly, somewhere too thin), then someone from the existing team may agree to “switch” the type of activity.
So, you sketched out a few portraits of "ideal" candidates. It is time to conduct a technical interview. By the way, I hope in your company it is the technical interview that influences the decision to hire employees? Often they speak of the company as a “family” or “a team where it's nice to spend time”. So, the company is still not a family. And not friends with whom you go bowling. Of course, if a person is sick with kleptomania or leprosy, then it is dangerous to take him to work, even if he was the best to have a technical interview. But do not get too hung up on personal qualities. In principle, before or after a technical interview, it is necessary to find out if a person does not throw out some kind of trick, and in this sense such a “non-technical” interview will have the role of a “threshold” - the one who does not pass in the company will not work exactly, but if it passes, it doesn’t matter whether it is the “soul of the company” or just a conscientious worker. But this and all, in fact, all other decisions should be determined by the technical interview. If your HR company pesters candidates with questions about their career aspirations and “who do they see themselves in 10 years” or “why should the company hire you”, then it’s too early for you to look for technical specialists. First you need to find a new HR.
')
But what to ask at the technical interview? Make a test? Find out what the person did in the past job? Ask a tricky question? Give a puzzle with braingames.ru?
Let's look at these options in order.
A test may seem like a good thing to save time. However, it is difficult enough to make a good test - it is necessary to spend a lot of time on this task. A bad test can exclude only candidates who have few interviewers and who do not know the answers to “typical” questions. A very bad test can weed out really cool candidates who just did a bit of other things. In general, the test is just some primary filter. You can not hire a person who could not answer the five trivial in your opinion questions. But you definitely shouldn't hire a person after the test without asking him a word.
What did you do at your last job? Well, you know, what the applicant did in his past job, he will not be involved in you. In principle, you can ask such a question to find a topic for conversation. But honestly, it looks like a waste of time. I will give an example from my practice.
- What did you do at your last job?
- Well, there was a complex system simulating a city communications system with the search for optimal routes and (...)
- What is Dijkstra's algorithm?
“Um, yes, and I heard something like that.”
Total - what have we learned? Never mind. Some complicated project. It is not really clear what the project is, what exactly this employee did, what he eventually learned to do well. We squandered 5 minutes to find out nothing about a person. Of course, you can spend half an hour and sort everything out on the shelves. But there are two "but."
First, appreciate the time. If you spend 4 hours for each candidate, then you can simply “not reach” the really worthwhile one. In general, in my opinion, the interview should be strictly limited to the time frame, say one hour. And try to shake out for this hour from a person everything you need to make a decision.
Secondly, do not dwell on who the person was. Try to evaluate what he could be in your company. Does your candidate say that in the last work you did the module that you did in the past month? So maybe in the last work there are cool business processes and a mountain of ready-made code, and you would have made this module exactly the same as you did? Or did it seem to you that in the previous work the candidate did not do anything remarkable? It may very well be. But maybe this is a talented person who lived in third-rate "horns and hooves", and you will reveal his full potential! Believe me, in many situations it is worth fighting for such a person even more than for an established specialist.
Should I ask something tricky? Let's say yesterday you read in a habr that it turns out that the hash code in Java is not an address (as you always thought), but a random number, and you wonder if the candidate knows this. Or you picked the nixes last week and found out that "[" is not part of the bash script as a language, but a regular program named "[". Would it be helpful to find out if this is known to the candidate?
There is again try to lose the question and answer options.
Role play.
- What is Object.hashCode ()?
- Well, this is the address of the object
And the second option:
- What is Object.hashCode ()?
- Yes, there is a random number generator, so he returns.
You have spent 3 minutes on this question. How do you compare the first and second candidate? Can you say that one of them is better than the other? Maybe the second one is scrolling at leisure grepcode. Or read Habr instead of work. And maybe not instead. But does this mean something to you?
Not that it doesn’t matter whether a person knows whether or not a subtlety of realization On the contrary - I think it is very important to know the little things. A person who knows assembler is more valuable to me than someone who does not know him, even when I am looking for a Java developer. But, unfortunately, there are so many trifles that the direct question “Did you know that?” Almost never carries meaning. We cannot ask about hundreds of things, because we have limited time.
So what to ask?
It seems to me that it is best to conduct a conversation, in the vein of what you usually do and watch how the candidate solves the problems you often solve.
Let's say your application has UI logic and server code. Ask the candidate what he thinks is more interesting.
Server code? Fine. Let's imagine some typical piece of code in your program. We are interested in what questions a candidate has, and how he links theoretical knowledge with practical needs.
Let's say this problem:
There is a code snippet
void x(List<String> a) { …Some processing } Question to the candidate - suppose in this code we need to sort the list in alphabetical order before “Some processing”. What will you do? By the way, yes, you can immediately tell the candidate about Collections.sort - we do not check the "vocabulary".
Put our candidate wrote something like
void x(List<String> a) { List<String> b = new ArrayList(a); Collections.sort(b); …Some processing with b } (I hope our candidate solved this problem in this way and did not start sorting a).
However, the solution of the problem is not the point here. The main discussion.
Why did he create a new list and not use the old one? Is it always right?
Why used ArrayList and not something else? Does he know what else to eat?
The most interesting is that the discussion here can be almost endless. The candidate will say that ArrayList is better because it is random access, and you say that sort still copies the data to the array before sorting, and then returns it back. Has the ArrayList become better now, according to the candidate? How, no longer? Or anyway better?
Conversation with the candidate should reveal the way of his thoughts. See how many details he knows. How does it react to something new? And most importantly, can he properly dispose of the information you give him? After all, the abstract "knowledge of everything" is usually not particularly important, in the end there are colleagues nearby and the problem issue can often be discussed. Colleagues can tell, but they will not write code instead of a new employee, so try to understand, can he, after hearing the advice, write a program better?
Or let's say another example.
Do not ask "what is the garbage collector." Do not ask "how many generations are there." What is the difference how much. What difference can a person tell or not how gc works - for your work it may be important only if a person can correct the performance problem if it arises, but can he tell a sentimental story about assembly for generations or is there a concurrent mark sweep gc.
I'm not saying that someone can solve any interesting problems with GC without knowing how it works. One time, of course, may be lucky. But in practice, knowledge is extremely important. The problem is different - not everyone who can tell how something works can fix the problem with this something. And, generally speaking, intuition, general technical knowledge is often more important for solving a problem than reading a description of an algorithm somewhere.
For example, for gc it will be good to bring again some practical puzzle.
Say, "you started the program with a 2 gigabyte hip and it works slowly, what will you do?".
- Increase hip
Will it be faster? And the most interesting, and isn't it worth asking before the answer to this question, but what is “faster” for me? See if the candidate understands the difference between throughput and latency. Do not ask what it is and what is the difference. If a candidate in the above described formulation of the problem does not occur to ask such trivial questions, it means that in practice he will not have these questions. However, do not forget that we are in conversation. If the candidate jumped off the bat, stop him, tell us about the different performance characteristics. The candidate has never heard of them, but he immediately realized that hip growth may improve one, but will definitely worsen the other? Well, that's great!
Such examples are infinite. The most pleasant thing is that such puzzles are invented elementary, and they don’t have a number - you can ask each new candidate about different things and adapt the puzzles for a particular candidate.
Source: https://habr.com/ru/post/285538/
All Articles