Why is it worth hiring a junior

When I started out as a Rails developer, I was constantly tinkering with frameworks all my free time, which, however, I had enough. I was not married, I worked in Coles and worked on freelancing, completing orders for PHP and Rails.

I once heard about Ruby Meetup in Adelaide. Immediately after work, I rushed to the train and went to this event. When I got there, several people asked me what I was doing. I talked about working at Coles, about PHP and Rails, to which I was told “you shouldn’t work at Coles anymore” and three of them handed me their business cards, telling me to give them a resume. I sent the application to Sealink and they took me.
')
In Sealink, I was apprenticed to a team of Rails developers who had a lot of patience to put up with my 19 year old antics. I am very grateful to them for the time that they spent on my training and, as I believe, it was their mentorship that laid the foundation of my career and all that I have been doing for the next ten years.

Melbourne has a lot of junior attending Ruby Meetup. I know this for sure, since I helped organize the nightly hackathons that they also go to. Imagine if a newcomer on a mitap would tell you that he is actively looking for work would you hire him? Probably no. It seems that at such events an atmosphere of disgust for hiring juniors reigns, because it is because they, juniors, take so valuable team time that could be spent on development, on their training.

There used to be a serious shortage of talented and skilled developers, and companies had to hire those they could find. That is why I once so easily got a Rails developer. I think that now everything has returned to normal and the presence of talent does not matter in order to take a person to work.

Recently, I have been discussing a lot in the Ruby community about how to avoid companies from hiring juniors. Instead, companies seek to hire midles and signors, and do not want to have junior teams that will learn from the same midles and signors.

Lawyers, mechanics, mechanics and many other professions have an apprenticeship culture (and apprentices), so why are programmers worse? This is rather strange, because in IT companies there is a sufficient turnover, which was supposed to convey to the management a lesson that you should always think about training personnel for the future. We are a young community with less than fifteen years of experience and we need to think about the long term: who will maintain our code after we leave?

Hiring seniors

Let's look at why companies want to hire a Signor first. In the company where I worked, we wanted to hire a new middle / senior developer, because our workload reached a level when we were already physically unable to cope with the tasks. I suppose it happens in other companies too. Wherever I worked, including to this day, I, and you, I believe, always had people breathing to the back of their heads and periodically asking when bugs were fixed or some new features were implemented.

And to solve such questions, you hire a new developer, or rather, you are trying to hire him. You want the developer to be at the middle-senior level, as he has all the necessary skills to instantly join the work without seriously participating in his “entry” process by the management in order to immediately start receiving ready-made code from him.

However, now it is not so easy to find at least someone suitable for these requirements. In the current situation it is almost impossible to hire a middle-senior Ruby developer who is ready to move into your company. Usually the following happens: developers get aggressive offers from competitors with which the latter are trying to lure them to themselves.

Companies spend thousands of dollars on the maintenance of recruiters and a lot of time for theoretical work, the profit from which is incredibly small. Companies spend thousands of dollars on the hunt for the mythical rock star of the world of development, the “unicorn” that costs ten ordinary developers. But the "unicorns" no longer graze in the sunny meadows, where they just catch. They, these "stars", are already working somewhere and they are satisfied with everything.

We, as a community, have already devastated the "pool" of talents.

There are no free rock stars left, so it's time to grow your own.

Companies are so keen on trying to hire a specific 5% or 10% of the total pool of developers that they no longer pay attention to everything else. There are more talented people in the remaining 90%, but they need mentors. If they get it, we can attract the smartest people to our community. What if the person who trained in your company was promoted higher and made technical director? And if he had become that engineer, who is worth ten, and who could help anyone and with anything? I believe that companies completely ignore the talents of people, if they are not completely obvious to them.

Too many organizations have focused on the short-term goals of obtaining a working code, instead of paying attention to the long-term prospects for the development and professional growth of their own teams.

Companies hire the best of the best - people with a guaranteed high skill - and are forced to engage in what, in essence, is another fantasy on the subject of concatenation

If you compare it with the hiring of pianists, then you hire Chopin, Bach and Franz Liszt so that they play “Mary had a little sheep”.

You do not need to hire a signor. You need to hire a developer of any skill level, train them and grow them. Give people a chance, train them on what is really used, because today's juniors may be great developers in your company tomorrow, but you just don’t give them the opportunity to become them.

Receipt of compensation

You might think: what are we, (as an organization) having with it? I believe that we need to think in the opposite direction: "we have earned on this community and now it's time to do something for it." If you invest (in the long term) in the health of the population, then in the future you will receive your dividends from this. In our case, you will have an active personnel reserve of developers who can support your product. In the short term, you will receive support for the performance level of your team by a new talented developer.

You may think that you need only the best, “tough assholes,” because your application is one big, unstructured monolithic hippopotamus, which only these tough assholes can cope with. You need signors who can navigate the noodles of the code of which the application consists. Maybe it is so. But in each monolithic project there is a bit of functionality, which not only the signor can cope with, on which the non-signor can increase his skill, provided that he works in conjunction with a senior developer.

It is normal to hire a team without a signor in order to work with the code of an already working product. We did this with Marketplacer and we are still in business. Understand that your company will not be caught in flames just because you start hiring juniors.

Yes, it is risky. Initially, the cost of maintaining such an employee is higher than the profit he brings to the company. But having the opportunity to grow, they can grow into the best asset you have ever had.



At the time of the start of work of juniors, the dollar value of their products is less than the cost of their maintenance. But with a good mentor, they can change and go into a state where their productivity is higher than their salary. Yes, there is a drawdown in labor productivity - this is true, but it lasts only 6 months, if you do everything correctly. In the end, instead of one developer, you already have two. Even if the junior is half as productive as a signor, then you have a developer and a half, which is more than just one, and this results in a one-and-a-half increase in team productivity.

At Marketpalacer, we hired juniors over the past year, and I believe they have become very productive and valuable team members. We would have missed them if we were focused solely on hiring signers or people who already have experience developing Rails applications.

You can think "what if they leave"? This risk exists when hiring an employee of any skill level. If people leave the company, you must draw conclusions for yourself and understand why this is happening. Do they leave for their own reasons, or is it your company? Is there a corporate culture in your company that you don’t want to leave? Or do people work here solely because they are interested in the software code for sea freight?

Junior search

Where can I start searching for juniors? Well, for starters - code-academy. No specific, but my favorite is Turing . The code academy now allows to partially solve the problem of the absence of mentoring. People pay "academies" thousands of dollars to master the basics. Some of the “academies” even offer job security at the end of their course. Most often they teach the basics of HTML, CSS, Javascript and Ruby and, as a rule, “graduates” are easy enough to link their future path specifically with Ruby. Initially, these people are very “green”, but they nevertheless become part of the community and start working.

Unfortunately, because of our desire to find the signors, we do not hire these newcomers. Talents are formed in academies, but we ignore them. These people have to fight for several months in order to get at least an internship - I talked with many of them.

Not all academy graduates have the time to hone and develop their skills, as they often work somewhere full-time or have other duties that require their attention. Fortunately, they often receive support from code academies even after completing the course. Well, in any case, this is done in good academies.

I would like companies to change their predilection for hiring experienced developers and pay attention to graduates of these same academies. More and more companies need to tutor and teach what they are doing. The people who graduate from the academy code really want to learn, and, based on my experience, they are very seriously motivated.

Of course, there are juniors who are also eager for knowledge and have the same motivation, but never the code academy has finished. They studied independently, periodically seeking advice from other members of our community. I can name five, no, even ten people who show great hopes in terms of learning from their mentors in our company.

If I were responsible for recruiting in our organization, I would hire a motivated Junior, pay him enough wages for life, and come to grips with his training.

Asim Aslan (chuhnk) had a good tweet on this topic:

If you didn’t have the experience. Hire smart raw talent and mentor them.

- Asim Aslam (@chuhnk) April 14, 2016

There is also a great book that I recommend reading to everyone, called The Talent Code. In its slogan it says: "They are not born great, they become." The book covers examples of improvement in areas such as sports, music and other areas. All industrial branches described in it, in one way or another, use the model of mentorship and submarines. However, this does not bother anyone in the programmer community: we are still too young a community.

In secret I will tell you the main idea of ​​this book: if someone is really good at something, he must send the hell out of it and deal with it. Where do we get the signors if we don’t hire juniors and don’t let them hone their skills in real conditions?

A lot of people talk about this issue, about hiring juniors. So let's start doing it.

Mentoring

Now that, as I hope, I have convinced you to hire a junior, you may be surprised and ask yourself “what am I doing?” As soon as he appears on your team.

I helped launch the night hackathon “Melbourne Ruby Hack night” where people were not limited to any framework where everyone could take any Ruby project with them and work with it. Some, even seeing Ruby there for the first time, have shown great interest. These nightly hackathons actually work, because these new developers feel safe, feel a friendly atmosphere and that not a single question is too “stupid” to ask.

You can start by mentoring your company by trying to recreate the atmosphere of these nightly hackathons. In the order of things there should be a situation when you are clapped on the shoulder and asked a question. If the questioner receives an eye roll, sighs, or other passive-aggressive signals, then this is not the kind of atmosphere in which the junior can learn something.

A great way to simulate the atmosphere of a hackathon is pair programming. Giving small unpretentious tasks to the junior is initially a great way to gain his confidence. When I taught the Juns, the first thing they needed, I think, is self-reliance. They know the answer, but they are not sure if it is correct. They question everything: whether they use the correct syntax or correctly write the code. When a senior developer is with a couple, he can encourage them to practice and learn something new. If a juna fails to do something, having a more experienced developer nearby will ensure that he explains that mistakes happen and will guide the novice on the right track. Such "bundles" are the fastest way to increase the skill of the junior and I highly, very much recommend it.

I worked daily with a couple of developers during my days at GetUp, and after a few years they turned into confident Rails developers. I did the same in other companies, and every time I saw the rapid professional growth of juniors, who was a mentor. One of the best feelings in the world is when June says: “Ah, I get it!”.

Twin work also helps to strengthen their own knowledge. If you can't explain something clearly enough to someone, then you don't know it well enough. Pair work is useful for younger developers, because they gain new knowledge, but it is also useful for their older comrades: in the course of communication with other people on the topic, for a clearer presentation, they structure their knowledge.

How exactly should you be paired with a junior? Well, Lydia Guarino has a couple of intelligent tweets on this topic:

5) For junior devs, a good guideline for scope is something that can be completed in 2-3 days. You want to keep your feedback loop short.

- Lydia Guarino (@lydiaguarino) April 13, 2016

5) Tasks with more than 3 days are tasks that are not defined well. Break them down further.

- Lydia Guarino (@lydiaguarino) April 13, 2016

And I agree with both. Junas develop the fastest when they manage to quickly achieve a positive result. When they have constant feedback, their confidence in you grows, and every time they “win” in the code, their self-confidence grows, which makes them only stronger.

Once they have gained some confidence in their own abilities, you can let the juniors work on their own. There is no clear time frame when this moment comes, it all depends on how capable your newcomer is.

Give them the will to do something small and the opportunity to ask any questions, and most importantly, let them know that there are no “wrong” ways to implement it. After completing the assignment, make them show what they have done, sit side by side and disassemble the written code together.

Joint analysis of the code is important because it doesn’t say “why are you doing this?”; There are no emotions in it, unlike in a situation where a living person speaks to you. But be careful: the junior can interpret your question “Why did you do this?” As aggressive “Eh! Why do you do it like this? ”

Visual contact helps to establish a connection between a student and a mentor much better than, for example, messages in the messenger.

If the junior made a mistake in the request, then you can discuss it with him and correct it. This will reduce the likelihood that it will appear again.

The review of the code also allows senior colleagues to assess how well your newcomer copes with the tasks. If he copes well with small two-day tasks, maybe it's time to give him something for four days? If not, then, apparently, will have to learn it.

In the end, the essence of mentoring is to make the junior feel needed and safe in your team. In fact, this applies to absolutely all members of the team. Google launched a project they called Project Aristotle, in which they tried to find a way to create effective teams . They interviewed employees and got five points:



And point number 1 was “Psychological Safety (Comfort)”: team members feel safe and can afford to be vulnerable.

Google is not a unique company. It also consists of people, like any other organization. And you must bear this in mind when you train your new recruits and work with other team members.