Introduction
The post is dedicated for the people that struggle with recruitment tasks and let you avoid basic mistakes in your recruitment processes. The knowledge is based on my personal experience from both sites. I used to check recruitment tasks as a recruiter but I have a huge amount of resolutions from my personal applications and feedback that I’m so thankful for. I would like to share it with you from a backend developer perspective.
There can be significant differences between particular roles but my proposal advices are quite universal. I hope that it will be helpful for you.
Read carefully
First of all the task is what you read in the task instruction. Before I remind you again as a teacher in primary school: “Read carefully!”, I would like to point out the aim of it. The reason that the recruiter takes care for completeness of the task is checking how your solution meets requirements in the project. As you probably know every project has requirements, the similar situation is in the case of recruitment projects. So my primary suggestion is read carefully, sometimes if you don’t understand something, in many cases you can contact a company to have everything clear. Asking questions is a massively important skill because as a software developer, you’ll everyday ask a question to create a product that client wants. From a different perspective it’s also a small test for a company, if it doesn’t open for questions, you’ll probably not be satisfied from working in that company.
Prove working solution
The basic step in checking a recruitment task is validating if it works. Otherwise, chances for accepting your solution are quite low. Of course, there is no rule, sometimes it’s worth being transparent that there is a bug in the task (or something not updated) or something is unclear. You’ll be recognized then not as a person that didn’t do the task correctly but as a person who had blockers in the meantime. These are 2 different concepts so if your final solution has bugs and the deadline comes it’s worth letting it know to the recruiter in response.
Provide end to end instruction
In order to illustrate usage of instruction and documentation in general, I’ll provide you a story. When I was a kid, I was passionate about LEGO bricks. I had many sets of them. I could build constructions without instruction provided but there is no guarantee that I’ll build the same as what is in the pictures and posters. Here instructions come, it is much easier to check the correctness of the solution going step by step. Recalling examples of LEGO, there are also many similar bricks but each of them can be used in different ways. Similar situation is in software development, so providing an end to end instruction to solution you’ll be sure that the recruiter will be on the same page.
Application is not all the environment
Sometimes you feel like the recruitment task is only about coding applications. You’re right! However, nowadays as a developer you are responsible for not only coding but also setting up CI/CD. You may tell me that it’s up to DevOps duties and that’s true in some cases. Building CI/CD is becoming more and more developer friendly and sometimes it doesn’t require Linux knowledge. I’m recalling it because it’s worth investing time to build the whole infrastructure for your recruitment task instead of just a code solution. Trust me, it’s very common that it’s nothing difficult to deploy what you did, it’s making things easier to check your task on the recruiter site and you can get extra points for it.
Go back to the job description
I know that your solution can be the best in the World but is it meeting the job description? It’s related to reading carefully the task but reading a job might suggest to you what to focus on. It’s very hard and sometimes almost impossible to focus on everything like 100% code coverage by tests. It’s desired to have tests to prove a working API or created app but the recruiter very often doesn’t care for fully tested code. It has to work, tests are good practice and show that you’re a competitive developer but you don’t have to care for 100% code coverage. There are many more important things to focus on, like nice to have bullet points from job descriptions. Very often candidates skip them because they are nice to have. They don’t see that it’s nice to have these things sooner or later required in the project so if you can’t do them, it’s a good time to learn it.