Pragmatic approach to test tasks for programmers

In an ideal world, we would not need interviews and test items. We would take people to work, and if they did not cope, they would be fired. We are not in a perfect world. That is why our interviews and tests should be like real work.

Test tasks by themselves are neither good nor bad. But they have to solve a practical problem, somehow influence the hiring process, preferably for the better: help to distinguish good candidates from bad ones, save time and money. The use of test tasks has its consequences. And the tests themselves may or may not correspond to the goal. I do not pretend to be complete. And I will be glad if you share your thoughts.

The employer and his super ideas

The employer, as it seems to him, gives test tasks because:

1. the candidate can be fully appreciated only by his code
   • This can really be a problem if the candidate is not involved in any open source project. But you can consider the test tasks that the candidate did for other companies.
     ')
     
2. interview doesn't give us enough information
   • The question is whether the test task will give you this information. Those. if you do not know from the very beginning how and what information you want to get from the test task and cannot convey these requirements to the candidate, then you are doomed to inefficiency. The reason for the failure of tests with test items often lies precisely in the fact that the candidate does not understand what and why they want from him in the end.
     
     
3. no time to communicate with each candidate
   • This is the strangest and dishonest motive. Candidate time is about the same as yours. But only your time is paid by the company, and the candidate’s time in this case is paid for by his family. Moreover, candidates are snapped up like cakes, and if your company does not have the image of a dream company, then you will simply lose the most interesting candidates.
   • In fact, a good test task is not easy to come up with. In addition, it should be run in, which requires significant costs. For free - will not work.
     
     
4. the task pumps over specialists of initial level
   • Curious motive. I am convinced that every student must have a mentor. Let them meet once a week, and the bulk of the work happens even outside the company. The format, when the intern is directed, is much more effective than independent research. Just do not say that you do not have time to teach, in this case, just do not take entry-level specialists.
     
     
5. A test task demonstrates a candidate’s ability to deliver a result, not just a process. It seems to me wrong. The result in real work is rarely achieved in the time spent even on a very large test task.
   
   
6. performance of the test task shows interest in work at you. If you have a strong HR-brand, then, probably, yes. But for most companies, this is not true. With the same success, we can assume that the test task performed shows that the candidate has a lot of time, he has no other suggestions, that he desperately needs work. Both this and that is nonsense. You can not know the personal motives of man.

The motives of the neurotic employer

1. We do not know how to interview
   • This is especially wonderful when a test task is sent to you immediately in response to a resume. Surprisingly, such fabulous companies still exist.
     
     
2. Test task as a delay in decision making
   • Your doubts are only your doubts. Do not shift the responsibility of the candidates.
     
     
3. No one to recruit, but to prove that I am the smartest here
   • People reviewing test items in one large and well-known company rejected test items if lambdas or anonymous delegates (C #) were used there. Well, but nothing about this discrimination of their closures was nothing in the conditions of the test task.
     
     

Conclusion: to make a good test task and not to spend your resources will not work. The job does not show the attitude of the candidate to your company. And to teach someone through the task is also unlikely to succeed. And read about the interview book.

About engineers. Methodology.

Problems with the methodology:

1. Test case must test
   • something substantial. What is essential for your project? algorithms? languages? frameworks? team game? business model?
   • something related to the future work of the candidate: the same task can be indicative and non-indicative - it all depends on the work that will have to be done. What is the main difficulty in developing your project? Do you need expertise in the development or in the subject area? What will the candidate do?
     
     
2. Test tasks are not interactive
   • It seems that everything is clear about the interview questions: this is an interactive event, you can always clarify, ask again and direct the conversation in the right direction (this also applies to the candidate and the interviewer). Much worse with test items: a candidate may clarify something incomprehensible in a letter or a call, but on the other hand there is always the fear of appearing unqualified. The candidate may be put in the wrong direction, especially if you did not clearly define the requirements: in the section on real test tasks, I will consider several such examples.
     
     
3. It is necessary to explain how you check the compliance of the result with the task. Everyone has their own criteria for evaluation, yes, yes, yes. There is a good explanation here . It is remarkable that the guys understand their weaknesses, so they are not looking for interesting solutions.
   
   
4. You yourself have not done your test task. Many companies estimate the complexity of the test task and give it to the candidates, considering that their assessment is correct, while almost no one can guess at real work with the estimates. In addition, the execution of the test task reveals implicit difficulties, or the fact that your seemingly fine task is a boring routine about writing lines into configs (which, however, can also be a task) and only 5% of them are about real complexity. I also have such an example.
   
   
5. There must be statistics on the assignments of both candidates and employees of your company. The task may be too difficult even for your best specialists. Or there may not be any candidates on the market who can do your task qualitatively, which is a sad fact, but you must accept this fact and decide what to do with it, and without statistics there is no way.
   
   
6. The MachineZone company openly publishes its tasks on the site. And they are great fellows. The candidate knows what to expect, he can evaluate himself, save his time. In addition, public tests are good for the HR brand.
   
   

Conclusion: If you decide to give test tasks, clearly state what you are testing, find out what you want as a result, calibrate the task on your employees - and all this in several iterations. Then you will have an illustrative, interesting task that is heating you up.

ABOUT! And there are also candidates!

And what do the candidates think when they are given test tasks?

1. Test tasks are artificial
   • It is often not clear what is expected of you and to what extent. It is easy to get a minus for an overly complex engineering solution or, on the contrary, too simple without a backlog on development. What, sorry, development?
     
     
   • Olympiad algorithmic problems, problems on spherical data with clear constraints - on the contrary, they are not artificial. But they, naturally, have their own scope: the ability to solve such problems does not mean that the candidate will do well for large systems or write clear code.
     
     
2. Test tasks are boring, monotonous crafts.
   • Of course, if your job is death boring, you can check how the candidate handles the manual placement of buttons into 100 forms, but it’s better that the test task also solves business goals, for example, telling the outside world what you are interesting and challenging tasks.
     
     
3. Test items require a lot of time, which the applicant does not have
   • 8 hours for a test task is a real two weeks: candidates have a family, work, gym, life, bars, a short summer. Evenings are two hours of free time. Weekend - more, but let people live.
   • If for some reason it is necessary to give a large test task, then do not limit the candidate, give him as much time as is required.
     
     
4. It is not clear what the criteria for assessing the job. What to look for and when to stop?
   
   
5. It is not clear what and in what volume you need to implement
   
   
6. You give me a test task, then to take it and not pay me for the work. Can I not comment on this?
   
   
7. Of course, there are still highbrow and arrogant candidates who will aggressively send you, but is it good that they fell off so early? However, maybe they just have a sentence without a test task?
   
   

Conclusion: think about how your task looks to the outside world. The task should be interesting, understandable: the candidate does not have many opportunities to clarify the details. Do not give long tasks - they will not perform.

And there are also HRs and the hiring process!

Problems with tasks as HR see them:

1. Test tasks reduce the flow of candidates, many candidates will simply refuse to fulfill them, or will disappear after receiving the task
   • In addition to engineering requirements, there are also business requirements. And between them there is some opposition. This does not mean that quality should be sacrificed for anything, but one should always bear in mind that test tasks have consequences: many good candidates simply refuse to fulfill them
     
     
2. Test tasks lengthen the time of hiring. Lengthen it significantly.
   • During this time, the candidate may receive an offer from competitors.
   • If you have tortured a candidate for an interview and test tasks, then during the final meeting he will inflate his cost: still! he broke through so many barriers, you showed him how difficult it is to get to you, and now he knows for sure that he is worth more.
     
     
3. Test items affect karma and HR brand
   • A good test task will attract your interest and create an image of a strong company.
   • A bad test task is a step to the abyss. Did you pay attention to the ratio of bad and good reviews on products and services on the Internet? Writing stuff is easier than writing something good.
     
     
4. No matter how we formalize the hiring process, whatever technology we use, hiring is a creative process. He is creative because you are looking for a person with whom you will understand and find it interesting to work, i.e. it must resonate with your thoughts and the way to do the work. Test tasks, due to their temporary limitations, do not solve this problem, they only help to cut off the excess.
   
   

Conclusions: Tests make the hiring process more difficult and time consuming. Many good candidates drop out, but weak ones remain.

A good example : You can pay for tasks, which somewhat alleviates the problem. For example, in VisualSVN they paid techies: they were given a fairly voluminous task, which, naturally, was already implemented (that is, another important condition was fulfilled: there was something to compare with, problems were known when performing the task). If the techis performed the task on time (they gave 2 weeks), then his work was paid at market prices. The best candidate was invited to work. This is an example of an honest approach to someone else's time and the most valuable human resource.

And I collected real test items.

What to do with the test tasks - you decide.

If you are still giving test tasks, then look at what other companies offer (some tasks are quite old, but nevertheless they are very curious) , maybe this will push you to something interesting.