INTERVIEWS ARE STRESSFUL. EVEN FOR PROFESSIONAL DEVELOPERS WHO HAVE WRITTEN THOUSANDS OF LINES OF COMMERCIAL CODE.
It is even more difficult for beginners – they do not have enough experience to adequately assess the quality of their code. The maximum that an employer can count on is a link to a GitHub profile, where a couple of training tasks await him. To save time, IT managers start with the main thing: they ask the applicant to write code.
Some managers send a test task to remotely assess the level of knowledge of the candidate and the quality of his code. Others do so to understand how much he/she is interested in working in their company. In both cases, the test task completed by a newcomer is an opportunity to receive an invitation to an interview.
There are employers who invite you for an interview without a test. But they will also ask you to write code if you flunk about a specific use of tools. Adequate code will save the situation and remove doubts.
Usually, as test tasks, candidates are given abstract cases, and not real business ones. According to them, the employer evaluates:
- knowledge of language/technologies;
- logical abilities of the candidate;
- candidate’s level of accuracy and pedantry, code readability.
HOW MUCH TIME DO YOU HAVE TO COMPLETE THE TEST TASK?
Usually, employers select tasks that will require no more than 7-8 hours from a middle developer, but juniors are given more time. Try to send the result within 3-5 days. Remember that only few employers will pay you for the completed test. However, each solved task adds you experience.
What is more important is the amount of time you will spend on the code and how you will write it. General advice: send code that solves the problem, and format it in accordance with the standards accepted in the developer community. The faster one can figure out your code, the more chances it has.
You will nail the interview if your code:
WORKS WITH NO ERRORS, SOLVES THE TASK, AND IS PROVEN WITH TESTS
A graceless program that produces the correct answer is better than a stunner that is dead on arrival. Testing is also extremely important: send the program along with the test results.
LIVES UP TO THE GENERALLY ACCEPTED PRINCIPLES:
SOLID is an acronym for the five main OOP design principles: Single responsibility, Open-closed, Liskov substitution, Interface segregation, and Dependency inversion.
KISS (acronym for «Keep it simple, stupid», that is, a call not to complicate the code),
DRY (acronym for «Don’t repeat yourself», a call not to iterate), etc.
These moments allow you to understand how deeply a person is immersed in the topic of development, how much he is interested in it. If a candidate who has never really worked anywhere follows the basic principles of code writing, this is a good sign. This means that the person studied this issue, and, most likely, on his/her own, because this part is rarely emphasized within the framework of university programs.
SIMPLE TO THE GREATEST POSSIBLE EXTENT
Beginners complicate the code. Even in solving simple problems, they strive to repeat the style of a professional using techniques “from the textbook” and not fully understanding why they are needed. The result of executing such code is difficult to predict: it can produce unexpected errors; it is difficult to read and test it.
Novice developers try to predict and calculate all possible cases of system development. This multiplies abstractions and unnecessary architectural layers in their code. In fact, a professional writes code for a specific task, and for this it is not necessary to use all known patterns and architectural solutions.
CHARACTERIZED BY INTEGRAL STYLE
The test task must comply with the coding standards adopted in the programming language. This is not a boring requirement of a computer science teacher: the standards are approved and used by the world community of programmers. The width of the indents, the case of variables, the style of writing comments – if all this meets the standards, the program is easy to read, you do not have to strain your memory and eyesight.
When working in a team, remember that your code will be read by other developers. Will they be able to quickly understand what is happening on the screen? Or make changes without diving deep into the context of the task?
CLEAR, EXPLAINED BY COMMENTS IF NECESSARY
You shouldn’t comment code just to describe what it does. Professional developers explain in the comments the purpose of creating the code and the meaning inherent in it.
If a test task is difficult for you, the employer will most likely notice this. Code written by a beginner often resembles a patchwork quilt. One piece of advice for the beginners: when you have solved the task, treat it as a draft and rewrite it again with the correct name and comments. It is important that the thought is visible behind the code, and not forced wording.
If you have difficulties with the test: tips
DIDN’T MAKE IT ON TIME? SHOW WHAT YOU ALREADY HAVE
Your potential is visible even in functionality that is not completely implemented.
It doesn’t matter why you didn’t make it. Show what is already written: even on the basis of this code, one can understand a lot. Do not be too lazy to describe in a cover letter or tell at a meeting how you planned to implement the task. The ability to think through solutions and present them intelligibly is valued no less than the ability to write code.
ASK MORE QUESTIONS. LEARN FROM THE BEST.
Do not be afraid to clarify the details of the test task. Reach out to more experienced colleagues for advice and ideas. Derive inspiration and knowledge from quality sources. By doing so, you develop thinking and increase the level of preparation.
The advice for beginners is to read books and articles only by trusted authors. Don’t be afraid to ask questions and consult with more experienced colleagues. Read their code and always (even like this: ALWAYS) specify why it was done this way and not otherwise, why this particular approach was chosen and not another.
ENTHUSIASM IS AS IMPORTANT AS A CLEAN CODE!
It is possible to teach person syntax, patterns and best practices but not the ability to express thoughts, work in a team, responsibility and especially hot eyes.
Conclusion and main advice: do not be afraid to complete and send test tasks. Employers turn a blind eye to errors if they see logic in the code. Your test task is a great opportunity for a personal conversation. Be prepared to explain why you used a particular technique. Or offer an alternative solution if the conditions of the problem change. The main goal of the employer is not to flop you down but to understand how you think.
Almost all experts agree on the main thing: the topmost in a candidate is the ability to think. Everything else, if desired, will be taught at a new place. Good luck!
