If you are a junior developer and you decide to apply to our company, first of all, you will have an interview with our HR Manager and then if you succesfully pass the soft skills interview, we will offer you to complete a test task.
We offer the test task to check the practical skills of a candidate if he doesn’t have commercial experience.
What the test task looks like:
- The task is formulated clearly, we indicate the main evaluation criterion, i.e. which aspects we will pay more attention to and which ones – less;
- The requirements for graphics are minimal, but not absent because visuals form a complete picture;
- We treat the test task as a regular task from the task tracker issued by PM.
- The task should be completed in less than a working day (up to 8 hours);
- Please attach a cover letter to the completed test task, in which you indicate and explain the solutions you have chosen.
What exactly we pay attention to when we check a test task:
- Cover letter (usually a wiki in the repository).
- The project in the repository:
The project from the test task should be on any version control service, for example, GitHub.
We pay attention to how the commits are made and signed.
- Basic review of the Unity project in the editor:
We download and check the project for compilation errors and warnings in the console.
The project should have a basic workflow: start, core feature, win/lose screen, and restart (automatic or manual). We also pay attention to the project structure (folders and files). We review content and its management: scenes, prefabs, and other assets.
- Code review:
Code style and convention, assembly definitions, namespaces.
Class names, method names, access modifiers, selected abstractions.
Project initialization, dependencies between entities, dependency resolution.
Evaluation of the implementation of scripts which are directly related to the main feature of the technical task.
The concept of a clean code includes the following points:
– The same code style and conventions in the project. There are clear rules that are applied to name of classes, interfaces, methods, fields, properties, the same indents, etc. It’s not so important which these rules are, but what is important is to follow them. Moreover, nowadays any modern IDE has a basic configuration and highlights any inconsistencies.
– Self-documented code, which means that comments are not required everywhere. In general, the company doesn’t mind comments in the code if they are specifically implemented (e.g., mathematical models, laws) or important parts of code. But that does not mean that comments should be everywhere because this will only worsen the readability of the code.
Make sure that your code comments are detailed, technical, and clear enough. And when you name classes, interfaces, and methods, use English to avoid making the code looks like comic text.
– Use principles and popular patterns that are suitable for the project. “Reinvent the wheel” for each task will make it difficult to read the code and maintain it by other developers.
– Clear and understandable entity dependencies. The code is “clean” in terms of its coherence in the project: what patterns were used to resolve dependencies and how.
- The algorithmic component of the solution.
For example, how efficiently the candidate forms a sample of objects and processes them.
- Understanding how the Unity Engine works.
For example, whether the candidate knows about the existence of naming conventions, and understands the basic hierarchies and purposes of the framework classes that should or can be used during the task or not.
- The presence of an improvement that makes some “sporting” sense (e.g., the implementation has improved performance compared to the basic solution, but does not degrade the way it is used) or has a real-life purpose (e.g., the candidate took care of the possibility of expanding the functionality in advance and made additional decomposition and more flexible distribution of responsibilities in the system) will be an advantage for the candidate.
- The candidate’s ability to explain his thoughts and to understand the task is a fundamental evaluation criterion.
After all, a junior developer is a specialist with whom other developers in the company will spend a lot of time: communicating with him, helping him develop, learn, making code reviews.
If you are still at a crossroads and don’t know how to start as a developer, we have some tips for you:
- If you’re starting to learn a new technology or stack, be sure to solve a real-world problem, because it will give you more interesting questions and answers than a ready-made tutorial or course. Better yet, post the solution to this problem in Git.
- Try to analyze how easily you get along with people and how you react in difficult situations. Try to improve your soft skills so you will be on the same page with the interviewer and it will be easier to build a dialog.
- Objectively assess your skills to understand your strengths and weaknesses. It is better to know fewer technologies in your stack but be more professional with them than to have a huge stack on your resume and know only the basics.
- Participate in game and app development jams and competitions. This experience will give you many advantages, interesting knowledge, new useful contacts, and the opportunity to be noticed by successful companies.
