About a technical interview
You have a product, an established team and financing. You (the team) worked well, and the management is ready to pay more money to hire a person, respectively, to expedite the development, improve quality and be able to spend resources on the 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 yourself, selected 20 candidates, and tomorrow you will begin to conduct interviews. It remains only to come up with what exactly to ask. Common situation? Then welcome to cat.
The situation may be a little utopian, but many cases are also part of this article. The exceptions are companies that “need a person yesterday” or companies that do not need a new person at all, they simply “observe the market” and (or) hope to find a “rare professional”.
In other words, this article is 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 a momentary need. Let's say that now you have a little “slowdown” in the development of the server side. Does this mean that you need to hire a server-side programmer? No, actually. 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, and the person will remain with you. And if this month you fill a hole in server-side development, then in the next it turns out that server-side is written faster than the interface is riveted. And what, next month you need to hire a UI programmer? Or fire the weak link in the server-side? No, it’s worth a different approach. See what you did before in product development. Ask sales, investors, or who determines the goals for development, and try to build a picture of what awaits you, say, a year in advance. Now imagine what kind of person would help you work more efficiently in the past and in the future. I hope you have introduced yourself to more than one person. Most likely it turns out that you can strengthen the team here, and here. And if somewhere it turns out to be too strong (and accordingly somewhere too thin), then someone from the existing team may agree to “switch” the type of activity.
So, you have sketched out several portraits of “ideal” candidates. It is time to conduct a technical interview. By the way, I hope in your company that a technical interview affects the decision to hire employees? People often talk about the company as a "family" or as a "team where it's nice to spend time." So, a company is still not a family. And not the friends with whom you go bowling. Of course, if a person is sick with kleptomania or leprosy, then it’s dangerous to take him to work, even if he underwent a technical interview best of all. 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 will throw out some kind of focus, and in this sense, such a “non-technical” interview will have the role of a “threshold” - someone who doesn’t pass it in the company will definitely not work, and if it passes, then it does not matter whether he will be the "soul of the company" or just a conscientious employee. But this and all, in fact, all other decisions should be determined precisely by a technical interview. If in your company HR pester candidates with questions about their career aspirations and "who they see themselves in 10 years" or "why the company should 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 a technical interview? Make a test? Find out what a person was doing at his last job? Ask a tricky question? Writing 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, making a good test is difficult enough - a lot of time must be spent on this task by itself. A bad test can only weed out candidates who do not attend interviews very well and who do not know the answers to “typical” questions. A very bad test can weed out really cool candidates who were just doing a little different things. In general, a test is just some primary filter. You can not hire a person who could not answer the five banal questions in your opinion. But it’s certainly not worth hiring 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 previous job, he will not do it with you. In principle, you can ask such a question in order to find a topic for conversation. But honestly, this seems like a waste of time. I will give an example from my practice.
Total - what did we learn? Never mind. Some kind of complicated project. It’s not clear what the project is, what exactly this employee did, what he eventually learned to do well. We squandered 5 minutes in order not to find out anything about the person. Of course, you can spend half an hour and take it all apart. But there are two “buts.”
First, appreciate the time. If you spend 4 hours on each candidate, then you can simply “not reach” the really worthwhile one. In general, in my opinion, the interview should be strictly limited to a time frame, say one hour. And try to shake out everything that is necessary for you to make a decision from the person during this hour.
Secondly, do not dwell on who the person was. Try to evaluate who he could become in your company. Does your candidate say that in the past job you did a module in a week that you did a month? So maybe at the last job cool business processes and a mountain of ready-made code, and you would have done this module exactly as much as you? Or did it seem to you that at the last job the candidate did not do anything remarkable? It may very well be. But maybe this is a talented person who has vegetated in third-rate "horns and hooves", and you will discover all his potential! Believe me, in many situations it is worth fighting for such a person even more than for an accomplished specialist.
Should I ask something tricky? Let's say yesterday you read on the hub that, it turns out, the hash code in Java is not an address (as you always thought), but a random number, and you are wondering if the candidate knows this. Or, last week, you poked around in nixes and found out that "[" is not part of a bash script as a language, but an ordinary program called "[". Will it be useful to find out if the candidate knows this?
Here it is again worth trying to lose the question and answer options.
Play the roles.
And the second option:
You spent 3 minutes on this question. How do you compare the first and second candidates? Can one say that one of them is better than the other? Maybe a second flipping at leisure grepcode. Or read a habr instead of work. Or maybe not instead. But does this say something to you?
Not that it doesn’t matter if a person knows the subtleties of realization. On the contrary - I think it’s 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'm looking for a Java developer. But, unfortunately, there are so many trifles that the direct question “Do you know what” almost never makes sense. And 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 that 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? Excellent. Let's introduce 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 fragment
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 are not checking the “vocabulary”.
Suppose our candidate wrote something like
(I hope our candidate solved this problem in this way and did not start sorting a).
However, the solution to the problem is not the main thing 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 is?
The most interesting thing 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 ArrayList gotten better now, according to the candidate? How, no longer? Or is it better anyway?
A conversation with a candidate should reveal his way of thinking.See how many details he knows. How does it react to something new? And most importantly - can he correctly dispose of the information that you give him? After all, abstract “knowledge of everything” is usually not particularly important, in the end there are colleagues nearby and a problematic issue can often be discussed. Colleagues can tell, but they won’t write code instead of a new employee, so try to understand if he can, after listening to advice, write a program better?
Or say another example.
Do not ask “what is a garbage collector”. Do not ask "how many generations are there." What difference does it make? What difference can or not a person tell you about how gc works - for your work it can only be important whether the person can fix the performance problem if it arises, and if he can not tell a heart-breaking story about the assembly for generations or about the concurrent mark sweep gc.
I'm not saying that someone can solve any interesting problems with the GC without knowing how it works. Once, of course, maybe she’s 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 than the description of an algorithm read somewhere, to solve a problem.
For example, for gc it will be good to bring some practical problem again.
Let's say, “you started a program with a 2 gigabyte heap and it runs slowly, what will you do?”
Will it be faster? And the most interesting, but isn’t it worth asking 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, in the above statement of the problem, it does not occur to the candidate to ask such trivial questions, then in practice he will not have these questions. However, do not forget that we are having a conversation. If the candidate jumped into the quarry, stop him, tell us about the different performance characteristics. The candidate had never heard of them, but he immediately realized that the growth of hip might improve one, but definitely worsen the other? Well, that's wonderful!
There are an infinite number of such examples. The best part is that such puzzles are thought up elementarily, and they don’t have a number - you can ask each new candidate about different things and adapt the puzzles to a particular candidate.
The situation may be a little utopian, but many cases are also part of this article. The exceptions are companies that “need a person yesterday” or companies that do not need a new person at all, they simply “observe the market” and (or) hope to find a “rare professional”.
In other words, this article is 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 a momentary need. Let's say that now you have a little “slowdown” in the development of the server side. Does this mean that you need to hire a server-side programmer? No, actually. 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, and the person will remain with you. And if this month you fill a hole in server-side development, then in the next it turns out that server-side is written faster than the interface is riveted. And what, next month you need to hire a UI programmer? Or fire the weak link in the server-side? No, it’s worth a different approach. See what you did before in product development. Ask sales, investors, or who determines the goals for development, and try to build a picture of what awaits you, say, a year in advance. Now imagine what kind of person would help you work more efficiently in the past and in the future. I hope you have introduced yourself to more than one person. Most likely it turns out that you can strengthen the team here, and here. And if somewhere it turns out to be too strong (and accordingly somewhere too thin), then someone from the existing team may agree to “switch” the type of activity.
So, you have sketched out several portraits of “ideal” candidates. It is time to conduct a technical interview. By the way, I hope in your company that a technical interview affects the decision to hire employees? People often talk about the company as a "family" or as a "team where it's nice to spend time." So, a company is still not a family. And not the friends with whom you go bowling. Of course, if a person is sick with kleptomania or leprosy, then it’s dangerous to take him to work, even if he underwent a technical interview best of all. 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 will throw out some kind of focus, and in this sense, such a “non-technical” interview will have the role of a “threshold” - someone who doesn’t pass it in the company will definitely not work, and if it passes, then it does not matter whether he will be the "soul of the company" or just a conscientious employee. But this and all, in fact, all other decisions should be determined precisely by a technical interview. If in your company HR pester candidates with questions about their career aspirations and "who they see themselves in 10 years" or "why the company should 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 a technical interview? Make a test? Find out what a person was doing at his last job? Ask a tricky question? Writing 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, making a good test is difficult enough - a lot of time must be spent on this task by itself. A bad test can only weed out candidates who do not attend interviews very well and who do not know the answers to “typical” questions. A very bad test can weed out really cool candidates who were just doing a little different things. In general, a test is just some primary filter. You can not hire a person who could not answer the five banal questions in your opinion. But it’s certainly not worth hiring 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 previous job, he will not do it with you. In principle, you can ask such a question in order to find a topic for conversation. But honestly, this seems 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 did we learn? Never mind. Some kind of complicated project. It’s not clear what the project is, what exactly this employee did, what he eventually learned to do well. We squandered 5 minutes in order not to find out anything about the person. Of course, you can spend half an hour and take it all apart. But there are two “buts.”
First, appreciate the time. If you spend 4 hours on each candidate, then you can simply “not reach” the really worthwhile one. In general, in my opinion, the interview should be strictly limited to a time frame, say one hour. And try to shake out everything that is necessary for you to make a decision from the person during this hour.
Secondly, do not dwell on who the person was. Try to evaluate who he could become in your company. Does your candidate say that in the past job you did a module in a week that you did a month? So maybe at the last job cool business processes and a mountain of ready-made code, and you would have done this module exactly as much as you? Or did it seem to you that at the last job the candidate did not do anything remarkable? It may very well be. But maybe this is a talented person who has vegetated in third-rate "horns and hooves", and you will discover all his potential! Believe me, in many situations it is worth fighting for such a person even more than for an accomplished specialist.
Should I ask something tricky? Let's say yesterday you read on the hub that, it turns out, the hash code in Java is not an address (as you always thought), but a random number, and you are wondering if the candidate knows this. Or, last week, you poked around in nixes and found out that "[" is not part of a bash script as a language, but an ordinary program called "[". Will it be useful to find out if the candidate knows this?
Here it is again worth trying to lose the question and answer options.
Play the roles.
- 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 it returns.
You spent 3 minutes on this question. How do you compare the first and second candidates? Can one say that one of them is better than the other? Maybe a second flipping at leisure grepcode. Or read a habr instead of work. Or maybe not instead. But does this say something to you?
Not that it doesn’t matter if a person knows the subtleties of realization. On the contrary - I think it’s 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'm looking for a Java developer. But, unfortunately, there are so many trifles that the direct question “Do you know what” almost never makes sense. And 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 that 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? Excellent. Let's introduce 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 fragment
void x(List 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 are not checking the “vocabulary”.
Suppose our candidate wrote something like
void x(List a)
{
List 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 to the problem is not the main thing 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 is?
The most interesting thing 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 ArrayList gotten better now, according to the candidate? How, no longer? Or is it better anyway?
A conversation with a candidate should reveal his way of thinking.See how many details he knows. How does it react to something new? And most importantly - can he correctly dispose of the information that you give him? After all, abstract “knowledge of everything” is usually not particularly important, in the end there are colleagues nearby and a problematic issue can often be discussed. Colleagues can tell, but they won’t write code instead of a new employee, so try to understand if he can, after listening to advice, write a program better?
Or say another example.
Do not ask “what is a garbage collector”. Do not ask "how many generations are there." What difference does it make? What difference can or not a person tell you about how gc works - for your work it can only be important whether the person can fix the performance problem if it arises, and if he can not tell a heart-breaking story about the assembly for generations or about the concurrent mark sweep gc.
I'm not saying that someone can solve any interesting problems with the GC without knowing how it works. Once, of course, maybe she’s 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 than the description of an algorithm read somewhere, to solve a problem.
For example, for gc it will be good to bring some practical problem again.
Let's say, “you started a program with a 2 gigabyte heap and it runs slowly, what will you do?”
- increase hip
Will it be faster? And the most interesting, but isn’t it worth asking 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, in the above statement of the problem, it does not occur to the candidate to ask such trivial questions, then in practice he will not have these questions. However, do not forget that we are having a conversation. If the candidate jumped into the quarry, stop him, tell us about the different performance characteristics. The candidate had never heard of them, but he immediately realized that the growth of hip might improve one, but definitely worsen the other? Well, that's wonderful!
There are an infinite number of such examples. The best part is that such puzzles are thought up elementarily, and they don’t have a number - you can ask each new candidate about different things and adapt the puzzles to a particular candidate.