Test tasks at a developer interview - does it make sense?
Over the course of my long IT career, I managed to visit both sides of the interviews and see all the splendor, poverty, insanity and sound thoughts of the test assignments issued at technical interviews of software developers.
If Petya is at the beginning of a developer’s career, then he will most likely be interested in doing test tasks and is ready to spend his personal time on this. For developers of Senior level and above, such tasks already cause boredom, especially not paid. And since a developer usually bypasses more than one company, the amount of time wasted on test tasks can be days or even weeks!
Are there really cool tasks? They happen but very rarely, maybe one in 100. Basically, everything is standard and not interesting - to read data from somewhere, do something with it, write data somewhere (file / base / socket ..). Or implement some well-known algorithm in place. Why is this so? Yes, because, in most cases, the tenant just needs to thin out the stack of CVs on his desktop, I’ll tell you more about this later.
Vasya has two dozen completely suitable resumes, among which you need to choose a worthy candidate for your team. To interview all two dozen Vasya is too lazy, and there is no reason to, and he decides to filter the line a bit and choose the most worthy ones. Of course, Vasya knows that you can go the way, as in a famous joke:
But Vasya decides to follow another widespread path - to give out a test task and sends it to all candidates. And then the circus with horses begins, which shows the absurdity of the test tasks.
One of the worst options for both parties, if the team leader for some reason (busy, lacking competencies, stupidly lazy, went to lunch) instead of himself sends one member of his team for an interview and makes a decision on his recall. If this happens, then the team leader, most likely, does not take its place in the company.
I met tasks for half an hour and a week, on average, most employers understand that it is not worthwhile to require the candidate more than a few hours.
Here, employers are trying to implement in the statement of tasks what they are deprived of in real work - code with comments, covered with unit tests, always with code style, and there have been cases when they required a brief tutorial on the program. In most cases, in real work, completely different requirements are much more prosaic.
You can meet both standard tasks at home, and such perversions as:
Some of the candidates fall off simply because they are too lazy to work for free, some do not like the task itself, some do not fully cater for all the conditions carefully written by Vasya, and they do a little wrong. As a result, the line of applicants is really thinning out, but not at all according to the principles that Vasya was expecting. Over time, Vasya sees that the quality of the completed test task and the effectiveness of the new developer in the team are weakly correlated and for the next candidates do not insist on the test task, moving on to the next level of developer assessment.
In his pink dreams, Vasya sees that the candidate will joyfully and enthusiastically begin work on the test task and will give out his best ever code, covered by tests by no means possible, with a competent (but not overly complicated) structure and generously spiced up with sensible comments.
The gap between the test task and the real work is so wide that it would be very naive to project the result of a small task for 3 hours on the long work of the developer. A lot remains behind the scenes (debugging, troubleshooting, refactoring, the architecture of the project is more complicated than Hello World , interaction with colleagues), which eliminates almost any benefit from such tasks. With about the same effect, you can just toss a coin and quickly decide whether a candidate is suitable or not.
A well-known case is when the author of the package manager Homebrew was not taken to Google, only for the reason that at the 7th interview he could not write an algorithm on the board how to invert the binary tree. How many tough guys companies lose from such slurred tasks - one can only guess.
Being in the place of Vasya, I sometimes gave test tasks in order to have something to discuss after its implementation. But only if the developer himself is not against it. This works well for Junior and Middle developers if they don't have code that they can demonstrate. Senior'ov and above cannot be appreciated by a small test task, here another approach is needed.
Given the disadvantages of traditional test cases, some companies have begun to take an approach that is closer to the working conditions. The candidate receives a real task from the current list of tasks (backlog) of the company, which can be carried out from one day to a couple of weeks and is paid at a contractual rate. Thus, the candidate gets the opportunity to work in trial mode with a new team and at the same time earn money for the time spent. This allows you to evaluate the candidate more accurately in conditions close to combat, but, unfortunately, few companies can afford it.
A meticulous reader will ask, “OK, author, if not a test task, then how else can you select the right senior?” And this is a topic for a separate article, stay tuned!
From the side of the applicant (aka developer Petya)
If Petya is at the beginning of a developer’s career, then he will most likely be interested in doing test tasks and is ready to spend his personal time on this. For developers of Senior level and above, such tasks already cause boredom, especially not paid. And since a developer usually bypasses more than one company, the amount of time wasted on test tasks can be days or even weeks!
Are there really cool tasks? They happen but very rarely, maybe one in 100. Basically, everything is standard and not interesting - to read data from somewhere, do something with it, write data somewhere (file / base / socket ..). Or implement some well-known algorithm in place. Why is this so? Yes, because, in most cases, the tenant just needs to thin out the stack of CVs on his desktop, I’ll tell you more about this later.
From the side of the employer (aka Timlid Vasya)
Vasya has two dozen completely suitable resumes, among which you need to choose a worthy candidate for your team. To interview all two dozen Vasya is too lazy, and there is no reason to, and he decides to filter the line a bit and choose the most worthy ones. Of course, Vasya knows that you can go the way, as in a famous joke:
Why do we need losers
The end of the working day. Two recruiting staff are sitting, old and young.
Old:
“Well, I'm done.” Let's go home?
Young looking at a bundle of unprocessed resumes:
- Yes, I still have a lot of work.
The old one comes, divides the pack into two, throws one into the urn. Young:
- How?!
Old:
“They were out of luck.” Why do we need losers?
Old:
“Well, I'm done.” Let's go home?
Young looking at a bundle of unprocessed resumes:
- Yes, I still have a lot of work.
The old one comes, divides the pack into two, throws one into the urn. Young:
- How?!
Old:
“They were out of luck.” Why do we need losers?
But Vasya decides to follow another widespread path - to give out a test task and sends it to all candidates. And then the circus with horses begins, which shows the absurdity of the test tasks.
Interviewer
One of the worst options for both parties, if the team leader for some reason (busy, lacking competencies, stupidly lazy, went to lunch) instead of himself sends one member of his team for an interview and makes a decision on his recall. If this happens, then the team leader, most likely, does not take its place in the company.
Task lead time and scope
I met tasks for half an hour and a week, on average, most employers understand that it is not worthwhile to require the candidate more than a few hours.
Quality of code and design
Here, employers are trying to implement in the statement of tasks what they are deprived of in real work - code with comments, covered with unit tests, always with code style, and there have been cases when they required a brief tutorial on the program. In most cases, in real work, completely different requirements are much more prosaic.
Job Format
You can meet both standard tasks at home, and such perversions as:
- write a decision on the board (this is usually done by Western companies)
- write a solution in notepad on company laptop
- write a solution remotely in pair programming mode
What does Vasya see at the exit?
Some of the candidates fall off simply because they are too lazy to work for free, some do not like the task itself, some do not fully cater for all the conditions carefully written by Vasya, and they do a little wrong. As a result, the line of applicants is really thinning out, but not at all according to the principles that Vasya was expecting. Over time, Vasya sees that the quality of the completed test task and the effectiveness of the new developer in the team are weakly correlated and for the next candidates do not insist on the test task, moving on to the next level of developer assessment.
What would you like to see Vasya?
In his pink dreams, Vasya sees that the candidate will joyfully and enthusiastically begin work on the test task and will give out his best ever code, covered by tests by no means possible, with a competent (but not overly complicated) structure and generously spiced up with sensible comments.
What give test tasks in reality?
The gap between the test task and the real work is so wide that it would be very naive to project the result of a small task for 3 hours on the long work of the developer. A lot remains behind the scenes (debugging, troubleshooting, refactoring, the architecture of the project is more complicated than Hello World , interaction with colleagues), which eliminates almost any benefit from such tasks. With about the same effect, you can just toss a coin and quickly decide whether a candidate is suitable or not.
It’s good to catch up, the author, probably in cool offices there is less nonsense with tasks
A well-known case is when the author of the package manager Homebrew was not taken to Google, only for the reason that at the 7th interview he could not write an algorithm on the board how to invert the binary tree. How many tough guys companies lose from such slurred tasks - one can only guess.
What test tasks are not needed at all?
Being in the place of Vasya, I sometimes gave test tasks in order to have something to discuss after its implementation. But only if the developer himself is not against it. This works well for Junior and Middle developers if they don't have code that they can demonstrate. Senior'ov and above cannot be appreciated by a small test task, here another approach is needed.
Can test cases really benefit both parties?
Given the disadvantages of traditional test cases, some companies have begun to take an approach that is closer to the working conditions. The candidate receives a real task from the current list of tasks (backlog) of the company, which can be carried out from one day to a couple of weeks and is paid at a contractual rate. Thus, the candidate gets the opportunity to work in trial mode with a new team and at the same time earn money for the time spent. This allows you to evaluate the candidate more accurately in conditions close to combat, but, unfortunately, few companies can afford it.
A meticulous reader will ask, “OK, author, if not a test task, then how else can you select the right senior?” And this is a topic for a separate article, stay tuned!
All Articles