How to perform test tasks for java juniors / trainees to get an interview
Recently, due to my work, I happened to select interns in our company. Everyone who remembers how it is to be an intern / junior should remember how difficult it is to get stuck in a more or less normal place without experience, where they will spend resources on your training. Due to the fact that the flow of beginner developers is very large, the employer has the opportunity to choose from this stream if not the best, then at least sensible, promising guys who are worth spending time on training in order to later employ them.
Each company has its own methodology for finding such candidates. Today, we adhere to the following: we give a small test task (about an hour of work, for an experienced developer), for which java-core knowledge is enough and ask to put it on a github. We do not limit the execution time. Then, qualitatively fulfilling the task, applicants are invited for an interview.
A task usually contains an implementation of CRUD methods to a file through a console menu with one or two entities plus validation of some fields. As an example, I’ll give a classic situation with a user who needs to implement email and phone validation according to a given template and to this be able to enter from 1 to 3 phones. There are a lot of responses, and there are very few places - accordingly, the selection is quite tough.
Starting to check all the tasks in a row, it turned out that it takes about 30 minutes to test the performance with launching and feedback of each task, I had to revise the verification methodology and derive criteria for quickly filtering out insufficiently high-quality code. For example, opening a solution on a github, I see that all the code is concentrated in several classes and even piled in one package - a quick failure (what about the principles of OOP?).
Many may find this approach unfair, to say that the problem is solved, the code works, but the life of the intern and junior is harsh and merciless.
The solution to the problem without errors is sent by a large half of the applicants, and a solid code - units that pass through natural selection and fall into the next round.
PS: I hope my advice will help you, dear applicants better perform your test tasks, and less likely to cry testers with bloody tears. Good luck in your search and a good starting place!
Each company has its own methodology for finding such candidates. Today, we adhere to the following: we give a small test task (about an hour of work, for an experienced developer), for which java-core knowledge is enough and ask to put it on a github. We do not limit the execution time. Then, qualitatively fulfilling the task, applicants are invited for an interview.
A task usually contains an implementation of CRUD methods to a file through a console menu with one or two entities plus validation of some fields. As an example, I’ll give a classic situation with a user who needs to implement email and phone validation according to a given template and to this be able to enter from 1 to 3 phones. There are a lot of responses, and there are very few places - accordingly, the selection is quite tough.
Starting to check all the tasks in a row, it turned out that it takes about 30 minutes to test the performance with launching and feedback of each task, I had to revise the verification methodology and derive criteria for quickly filtering out insufficiently high-quality code. For example, opening a solution on a github, I see that all the code is concentrated in several classes and even piled in one package - a quick failure (what about the principles of OOP?).
Many may find this approach unfair, to say that the problem is solved, the code works, but the life of the intern and junior is harsh and merciless.
In this regard, I offer my list of recommendations for the implementation of the test task
- Your decision should work in accordance with the ToR
Carefully fulfill the requirements set out in the conditions for solving the problem. Do not think over your fields in entities, do not change the validation conditions, etc. etc. This shows how attentive you are to the details, which is very important for the developer. - Carefully check the completed task
Done the task - check the performance. First, the main functionality described in the ToR, then additional. Try to break your application, enter not valid data, the data is as similar as possible. Remember to fix everything you find. - Encoding
All files must be in the same encoding, in my opinion in UTF-8. Configure your IDE for this. Remember, if you have Windows, then the reviewer may have Linux, and additional squats with encoding is a waste of time for the reviewer. - Do not commit in one commit
You need to commit as you solve your problem, add clear descriptions in English to the commits. This indirectly indicates that you did not just merge someone else's solution from the git, but wrote the code yourself. - Try not to merge other people's decisions
Given that you claim the maximum for June, most often you still have not enough experience to use someone else's code. The conditions of the problem can vary slightly, and when you simply copy someone else's solution, it may already be a little inconsistent with the current task. And the task must be completed exactly with the task (see P1). - Add readme file
Add the readme.md file to the project root. Briefly describe your application, lay out additional explanations for launch, if necessary. If you have other tasks already completed, add readme there too. For example, if I’m interested in a candidate, I can see his other code. And if you don’t go here, you can also attach this code to your resume. - Make a convenient menu
The application must be user friendly. Remember that the time for checking is often limited, so preload the application with data, add a method to show all entities (which is there in the conditions). Menu navigation should be convenient, for example using numbers. And sometimes they implement it in such a way that to delete an entity you need to enter “Delete” in the console. - Do as best as your skills allow.
Since you have decided to carry out the test task, approach its solution with maximum return. Even if the task seems trivial and simple, you do not need to approach its solution formally and write code on your knee. And if you don’t go to this company, then your decision will remain on the github, and this is practice. - Do not forget the principles of OOP
Let it seem to you that a small task, do not forget - the task is a test, and java is primarily an object-oriented language. And they will look not only at the operability of the application, but also at the code. Code quality is a very important part of the solution . Do not write spaghetti code. Put everything into classes, packages. Create interfaces where you need, put constants in ENUM. - Try to use design patterns
A successful application of at least one design pattern will show that you have an understanding of design patterns (or you don't). Just before applying this or that pattern - figure out what the idea is, how it should work and why it was invented. If I see patterns in the code, then at the interview I can ask a question about the applied pattern. - Use resources
All messages displayed to the user are best taken into resources and taken from there. This will show the reviewer that you know how to work with resources and understand what they are used for. Messages are best displayed in English. - Remember to redefine where equals & hashcode is
- Use java8 + features like lambda expressions, streams
Use the correct collections instead of an array, it is at least more convenient - we do not need to save memory. - Tests
If you can, write tests, but this is a task with an asterisk
Summary
The solution to the problem without errors is sent by a large half of the applicants, and a solid code - units that pass through natural selection and fall into the next round.
PS: I hope my advice will help you, dear applicants better perform your test tasks, and less likely to cry testers with bloody tears. Good luck in your search and a good starting place!
All Articles