🥇How to tame a junior?

How to get into a big company if you are a junior? How to hire a worthy junior if you are a big company? Under the cut, I’ll tell you our story of hiring beginners for the front-end: how we worked out test tasks, prepared to conduct interviews and built a mentoring program for the development and onboarding of beginners, and also why standard interview questions don’t work.

Me, trying to tame a junior

Hello! My name is Pavel, I'm doing the frontend in the Wrike team. We create a system for project management and collaboration. I have been working on the web since 2010, worked for 3 years on a foreign remote, participated in several startups and taught a course on web technologies at the university. In the company, I am involved in the development of technical courses and the Wrike mentoring program for juniors, as well as directly recruiting them.

Why we even thought about hiring juniors

Until recently, we recruited middle or senior level developers for the front-end — independent enough to do product tasks after onboarding. At the beginning of this year, we realized that we wanted to change this policy: over the year, the number of our product teams has almost doubled, the number of front-end developers has approached a hundred, and in the near future, all this will have to double again. There is a lot of work, few free hands, there are even fewer of them on the market, so we decided to turn to the guys who are just starting their journey in the front-end and realized that they were ready to invest in their development.

Who is a junior?

This is the very first question we asked ourselves. There are different criteria, but the simplest and most understandable principle is this:

Junior needs to be explained what feature and how to do it. Middle needs to be explained what feature is needed, and he will deal with the implementation himself. Signor himself will explain to you why this feature does not need to be done at all.

One way or another, a junior is a developer who needs advice on exactly how to implement a particular solution. What we decided to start from:

Junior - one who wants to develop and is ready to work hard for this;
He does not always know in which direction he wants to develop;
Needs advice and seeks help from outside - from his lead, mentor or in the community.

We also had several hypotheses:

There will be a storm of responses to the position of the june. It is necessary to filter random responses at the stage of sending a resume;
The primary filter won't help. - Need more tests?
Test tasks scare everyone away - they are not needed.

And of course, we had a goal: 4 juniors in 3 weeks.

With this awareness, we began to experiment. The plan was simple: start with the widest possible funnel and try to gradually narrow it down so that you can keep up with the flow, but not reduce it to 1 candidate per week.

Posting a job

For the company: There will be hundreds of responses! Think filter.

For junior: Do not be afraid of a questionnaire before sending a resume and a test task - this is a sign that the company has taken care of you and set up the process well.

On the very first day, we received about 70 resumes from candidates “with knowledge of JavaScript”. And then more. And further. We physically couldn't call everyone for an interview in the office and chose the guys with the coolest pet projects, live github, or at least experience.

But the main conclusion that we made for ourselves on the very first day was that the storm had begun. It's time to add a questionnaire form before submitting your resume. Her task was to weed out candidates who were not ready to make the minimum effort to submit a resume, and those who did not have the knowledge and context to at least enough to google the right answers.

It contained standard questions about JS, layout, web, Computer Science - everyone who knows what they ask at a front-end interview knows them. What is the difference between let/var/const? How to apply styles only for screens smaller than 600px wide? We didn’t want to ask these questions at a technical interview - practice has shown that they can be answered after 2-3 interviews, without understanding the development at all. But on the other hand, they were able to initially show us whether the candidate understands the context in principle.

In each category, we prepared 3-5 questions and day after day changed their set in the form of a response, until we excluded the most passing and the most difficult ones. This allowed us to reduce the flow - in 3 weeks we received 122 candidateswith which to work further. These were IT students; guys who wanted to move to the front from the backend; workers or engineers aged 25-35 who radically wanted to change their occupation and put a different amount of effort into self-education, courses and internships.

Getting to know each other better

For the company: The test item doesn't scare off candidates, but it does help shorten the funnel.

For junior: Do not copy-paste the test ones - this is noticeable. And keep your github in order!

If we called everyone for a technical interview, we would have to do about 40 interviews a week only for juniors and only on the front end. Therefore, we decided to test the second hypothesis - about the test task.

What was important for us in the test:

Build a good scalable architecture, but without overengineering;
It’s better to do it longer, but do it well, than to make a craft overnight and send it with the comment “I’ll definitely bring it to the end”;
The history of development in the git is the engineering culture, the iterative nature of development, and the fact that the solution is not completely brazenly accumulated.

We agreed that we wanted to look at one algorithmic problem and a small web application. Algorithmic ones were prepared at the level of laboratories of initial courses - binary search, sorting, checking for anagrams, working with lists and trees. As a result, we settled on binary search as the first trial option. Tic-tac-toe was supposed to be a web application using any framework (or without it).

The test task was mastered by almost half of the remaining guys - we were sent solutions 54 candidates. Incredible insight - how many implementations of tic-tac-toe, ready for copy-paste, do you think there are on the net?

How many?In fact, it seems that only 3. And in the vast majority of decisions there were precisely these 3 options.
What did not like:

copy-paste, or development according to the same tutorial without its own architecture;
both tasks are in the same repository in different folders, of course there is no commit history;
dirty code, DRY violation, lack of formatting;
a mixture of model, view and controller into one class hundreds of lines of code long;
lack of understanding of unit testing;
a head-on solution is a hardcode of the matrix of winning combinations 3x3, which will be quite difficult to expand to 10x10, for example.

And we also paid attention to neighboring repositories - cool pet projects were a plus, and a bunch of test tasks from other companies was more like a wake-up call: why couldn’t the candidate go there?

As a result, we found cool options for React, Angular, Vanilla JS - there were 29 of them. And we decided to invite one more candidate without test ones for his very cool pet projects. Our hypothesis about the benefits of test items was confirmed.

Technical Interview

For the company: Not middles/seniors came to you! Need more individual approach.

For junior: Remember that this is not an exam - do not try to keep silent on the top three or fill up the professor with a stream of all your possible knowledge so that he gets confused and puts "excellent".

What do we want to understand in a technical interview? A simple thing - how the candidate thinks. He probably has some hard skills, if he passed the first stages of selection - it remains to be seen if he knows how to apply them. We agreed on 3 issues.

The first is about algorithms and data structures. With a pen, on a piece of paper, in pseudo-language and with the help of drawings, we figured out how to copy a tree or how to remove an element from a singly linked list. An unpleasant discovery was that not everyone understands recursion and how links work.

The second is live coding. We went to codewars.com, chose simple things like sorting an array of words by the last letter, and for 30-40 minutes, together with the candidate, they tried to make all the tests pass. It seemed that there should be no surprises from the guys who mastered tic-tac-toe - but in practice, not everyone was able to realize that the value must be stored in a variable, and the function must return something through return. Although I sincerely hope that it was jitters, and the guys were able to deal with these tasks in more light conditions.

Finally, the third is a little about architecture. We discussed how to make a search bar, how debounce works, how to render various widgets in search tips, how the frontend can interact with the backend. There were a lot of interesting solutions, including server-side rendering and web sockets.

We conducted 21 interviews in this manner. The audience was completely motley - let's go to the comics:

"Rocket". He never calms down, he gets in everywhere, and during an interview he will overwhelm you with a stream of thoughts that are not even directly related to the question asked. If it were at the university, it would be an attempt, familiar to many, to demonstrate, well, in general, all your knowledge, when you only remember about the ticket that came across that you decided not to study it last night - you still won’t get it out.
"Groot". It's hard enough to get in touch with him, because he is Groot. In an interview, you have to swing for a long time, pulling out answers word by word. Well, if it's just a stupor, otherwise it will be very difficult for you in your daily work.
"Drax". Previously, he was engaged in cargo transportation, and from programming he only taught JS on Stackoverflow, so he does not always understand what the conversation is about at the interview. At the same time, a good person, has the best intentions and wants to become a cool front-ender
Well, probably "Star Lord". In general, a good candidate with whom you can negotiate and build a dialogue.

At the end of our research 7 candidates reached the final, having confirmed their hard skills with a cool test task and good answers to interviews.

Cultural fit

For the company: You work with him! Is the candidate really ready to work extremely hard for his development? Will he fit right into the team?

For junior: You work with them! Is the company really ready to invest in the growth of juniors, or will they just dump all the dirty work on you for a low salary?

Each junior, in addition to the product team, the leader of which must agree to take him, gets to the mentor. The task of the mentor is to guide him through the three-month process of onboarding and pumping hard skills. Therefore, we came to each cultural fit as mentors and answered ourselves the question: “Will I take the responsibility to upgrade the candidate in 3 months according to our plan?”

This stage was uneventful and eventually brought us 4 offers, 3 of which were accepted, and the guys went to the teams.

Life after the offer

For the company: Take care of your juniors or others will!

For junior: AAAAAAAAAAAA!!!

When a new employee comes out, he needs to be onboarded - introduced into the course of processes, told how everything works in the company and in the team, and how he should work in general. When a junior comes out, you need to understand how to develop it.

When we thought about it, we formed a list of 26 skills that, in our opinion, a junior should have by the end of the three-month onboarding period. It included hard skills (according to our stack), knowledge of our processes, scrum, infrastructure, project architecture. We combined them into a roadmap distributed over 3 months.

For example, here is my junior's roadmap

We assign a mentor to each junior who works with him on an individual basis. Depending on the mentor and the current level of the candidate, meetings can take place from 1 to 5 times a week for 1 hour. Mentors are self-motivated front-end developers who want to do more than just write code.

Part of the load from mentors is removed by courses on our stack - Dart, Angular. Courses are held regularly for small groups of 4-6 people, where the guys study on the job.

For 3 months, we periodically collect feedback from juniors, their mentors and leads and adjust the process individually. 1-2 times for the entire period, the pumped skills are checked, the same check is carried out at the end - on their basis, recommendations are formed on what exactly is worth tightening up.

Conclusion

For the company: Is it worth investing in juniors? Yes!

For junior: Look for companies that carefully select candidates and know how to develop them

For 3 months, we reviewed 122 questionnaires, 54 test items and conducted 21 technical interviews. This brought us 3 great juniors who have now completed half of their onboarding and acceleration roadmaps. They are already closing real product tasks in our project, where there are more than 2 lines of code and more than 000 repositories on the frontend alone.

We found that the funnel for juniors can and should be quite difficult, but in the end only those guys who are really willing to work very hard and invest in their development pass through it.

Now our main task is to complete three-month development roadmaps for each junior in the mode of individual work with a mentor and general courses, collect metrics, feedback from leads, mentors and the guys themselves. At this point, the first experiment can be considered completed, conclusions can be drawn, the process improved and restarted to select new candidates.

Source: habr.com

How to tame a junior?