Almost the entire Skyeng development team, consisting of more than 100 people, works remotely and the requirements for specialists have always been high: we were looking for seniors, fullstack developers, and mid-level professionals. However, in early 2019, we hired three juniors for the first time. This was done for several reasons: hiring only super-specialists does not solve all problems, and to create a healthy atmosphere in development, we need people with varying levels of expertise.
When you work remotely, it is crucial for a person to join the project and immediately start delivering value, without long training and ramp-up processes. This is not the case with juniors, plus, in addition to training, a proper integration of a newcomer into the team is required, as everything is new to them. This is already a separate task for the team lead. Therefore, we focused on searching for and hiring more experienced and established developers. But over time, it became clear that teams consisting only of seniors and fullstack developers have their own problems. For example, who will handle the routine but necessary tasks that do not require super-qualifications or any special knowledge?
Previously, instead of hiring juniors, we dealt with freelancers.
While the tasks were few, our seniors grudgingly took on these uninteresting tasks, since development must move forward. But this could not continue for long: projects grew, and the number of routine simple tasks increased. The situation started to resemble a joke where nails are driven in with a microscope instead of a hammer. To visualize this, consider the arithmetic: if you bring in a person whose rate is conditionally $50/hour for tasks that an employee with a rate of $10/hour could handle, then you have problems.
The most important takeaway from this situation is that the current hiring paradigm of only bringing in top specialists does not address our issues with routine tasks. We need someone who is willing to do the work that seasoned seniors see as a punishment and assigning which to them is simply inefficient. For instance, writing bots for our instructors' and course creators' Slack channels or handling minor improvement projects for internal needs that developers constantly lack time for, but where the quality of life would greatly improve.
At this point, an interim solution was developed. We started bringing freelancers into our projects. It was for such outsourcing that simple and non-urgent tasks were increasingly assigned: correcting minor details, verifying, or rewriting something. Our freelance wing was growing quite actively. One of our project managers gathered tasks from various projects and assigned them to freelancers, relying on the existing pool of contractors. At the time, we thought it was a good solution: we relieved the seniors of their workload, allowing them to be creative again instead of getting bogged down with basic tasks. Of course, there were tasks that could not be transferred to external contractors due to confidentiality, but these concerns were significantly less numerous compared to the amount of tasks going to freelancers.
But this couldn't last forever. The company faced the reality that the freelance department had turned into an unwieldy monster. The number of routine and simple tasks grew alongside the projects, and at some point, there became too many to manage effectively through external contractors. Furthermore, freelancers are not immersed in the specifics of the projects, which leads to constant time waste on onboarding. Clearly, when your team consists of 100+ professional developers, you can't hire even fifty freelancers to assist them effectively and manage their activities. Additionally, working with freelancers always carries risks of missed deadlines and other organizational problems.
It is important to clarify that a remote employee and a freelancer are two different entities. A remote worker is fully integrated into a company, has designated working hours, a team, a manager, and so on. A freelancer works on a project basis, mostly regulated by deadlines. Unlike a remote employee, a freelancer is primarily left to their own devices and interacts little with the team. Hence, there are potential risks associated with working with such contractors.
How we came to create the 'simple tasks department' and what we achieved
Having analyzed the current situation, we concluded that we need employees with lower qualifications. We didn't harbor any illusions about the idea that we would turn all the juniors into future superstars, or that hiring a dozen juniors would cost us next to nothing. In general, the reality with juniors is as follows:
- In the short term, hiring them is economically unfeasible. Instead of hiring five to ten juniors 'right now', it's better to hire one senior and pay them a substantial salary for quality work than to spend budgets on newcomers.
- Juniors have a long onboarding period and require training.
- At the moment when a junior learns something and is supposed to start 'justifying' their investment during the first six months of work, they either need to be promoted to mid-level, or they leave for that position in another company. Therefore, hiring juniors is suitable only for mature organizations that are ready to invest in them without guarantees of short-term profit.
But we have grown to a size where having juniors in the team is essential: the number of routine tasks is increasing, and wasting the man-hours of seasoned professionals on them is simply a crime. This is why we created a department specifically for junior developers.
The period of work in the simple tasks department is limited to three months — that is, this is the standard probationary period. After three months of fully paid work, the newcomer either joins the team that wants them as a junior developer, or we part ways with them.
An experienced PM heads our newly created department, overseeing the distribution of tasks among juniors and their collaboration with other teams. The junior receives a task, completes it, and gets feedback from both the team and their manager. During the initial phase in the department, we do not assign newcomers to specific teams and projects — they have access to the entire pool of tasks according to their skills (currently, we are hiring front-end developers skilled in AngularJS, back-end developers in PHP, or looking for candidates for a web developer position with both languages) and can work on multiple projects simultaneously.
However, hiring juniors is not the only focus — we also need to create acceptable working conditions for them, which is a task of a completely different nature.
The first thing we established is voluntary mentorship in reasonable volumes. This means that, aside from the fact that we did not force anyone among our existing specialists to mentor, it was clearly stated that training a newcomer should not replace their main work. No '50% of the time working, 50% teaching the junior.' To have a clear understanding of how much time mentorship would take, we created a small 'training plan': a list of tasks that each mentor was to complete with their mentee. The same was done for the project manager of the juniors, and as a result, we developed a very smooth and understandable scenario for preparing newcomers and integrating them into the work.
We accounted for the following aspects: checking theoretical knowledge, preparing a set of materials in case the junior needs to learn something, and establishing a unified principle for conducting code reviews for mentors. At each stage, leaders provide feedback to the newcomer, which is crucial for them. The young employee understands in which areas they are strong and where they need to pay more attention. To simplify the training process for juniors and experienced developers, a general chat was created in Slack, allowing other team members to join the learning process and answer questions instead of the mentor. All this makes working with juniors a quite predictable and, importantly, manageable process.
At the end of the three-month probation period, the mentor conducts a final technical interview with the junior. Based on the results, it is determined whether the junior can transition to a permanent position in one of the teams.
Total
At first glance, our department for juniors resembles an incubator or a specially created sandbox. However, in reality, it is a genuine department with all the attributes of a full-fledged operational team that tackles real, not just training, tasks.
But the most important thing is that we provide people with a clear horizon. The department of simple tasks is not an endless limbo where one can get stuck forever. There is a defined three-month term during which the junior solves simple project tasks but can also showcase their skills and join a team. The newcomers we hire know that they will have their own project manager, a mentor from the seniors (or perhaps several), and the opportunity to fully integrate into a welcoming team that is eager for them.
Since the beginning of the year, 12 juniors have been hired in the department of simple tasks, and only two did not pass the probation period. One guy didn't fit in with the team, but since he is very capable in terms of work, he was returned to the department of simple tasks for another term, during which, we hope, he will find a new team. Working with juniors has positively impacted our experienced developers as well. Some of them, after a mentoring period, discovered their strength and desire to try out for team lead roles, while others, inspired by the juniors, improved their own knowledge and advanced from a mid-level to a senior position.
We will continue to expand our practice of hiring young developers, as it brings numerous advantages to the team. Juniors have the opportunity for full remote employment regardless of their place of residence: members of our development teams live from Riga to Vladivostok and manage to handle the time differences well thanks to established processes within the company. This opens the door for talented individuals living in remote towns and villages. We're talking not only about recent high school graduates and students but also about people who have chosen to change careers for various reasons. A junior can successfully be 18 or 35 years old; after all, being a junior is about experience and skills, not age.
We are confident that our approach can be easily applied to other companies that use a remote development model. It simultaneously allows for targeted hiring of talented juniors from anywhere in Russia or the CIS while also enhancing the mentoring skills of experienced developers. Financially, this approach is very affordable, ensuring that everyone benefits: the company, our developers, and of course, the juniors, who do not have to move to large cities or capitals to become part of an experienced team and work on interesting projects.
Source: habr.com
