🥇 How to tame a junior?

How to get into a big company as a junior? How to hire a worthy junior if you are a big company? Below, I'll share our story of hiring novice front-end developers: how we developed test assignments, prepared to conduct interviews, and built a mentoring program for the growth and onboarding of newcomers, as well as why standard interview questions don’t work.

I am trying to train a junior.

Hello! My name is Pavel, and I work on the front end for the Wrike team. We create a project management and collaboration system. I've been involved in web development since 2010, spent 3 years working remotely for companies abroad, participated in several startups, and taught a course on web technologies at a university. In the company, I am involved in the development of technical courses and the Wrike mentoring program for juniors, as well as their recruitment.

Why did we even consider hiring juniors?

Until recently, we were hiring mid-level or senior front-end developers—those who are independent enough to tackle product tasks after onboarding. At the beginning of this year, we realized that we wanted to change this policy: over the past year, the number of our product teams has nearly doubled, the number of front-end developers approached a hundred, and in the near future, this is expected to double again. There's a lot of work, but few hands available, and even fewer in the market, so we decided to reach out to those who are just starting their journey in front-end development and realized we were ready to invest in their growth.

Who is a junior?

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

A junior needs to be explained how to implement a feature. A mid-level developer needs to be told what feature is needed, and they will figure out the implementation themselves. A senior will explain to you why that feature doesn’t need to be developed at all.

In one way or another, a junior is a developer who needs guidance on how to implement a particular solution. Here’s what we decided to base our approach on:

A junior is someone who wants to grow and is willing to work hard for it;
They don’t always know exactly which direction they want to develop in;
They need advice and seek help from outside—whether that’s from their lead, mentor, or in the community.

We also had several hypotheses:

The position will attract a storm of applications from junior candidates; We need to filter out random applications at the resume submission stage;
The initial filter won't help — we need additional test assignments;
Test assignments will scare everyone off — they are unnecessary.

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

With this realization, we began to experiment. The plan was simple: start with the widest funnel possible and gradually narrow it down to manage the flow, but without reducing it to just 1 candidate per week.

Post the job opening

For the company: There will be hundreds of applications! Think about the filter.
For juniors: Don't fear the questionnaire before submitting your resume and test assignment — it's a sign that the company cares about you and has properly set up the process.

On the very first day, we received about 70 resumes from candidates "with knowledge of JavaScript". And then more. And more. We physically couldn't invite everyone for interviews at the office and selected those with the most impressive pet projects, active GitHub profiles, or at least some experience.

But the main conclusion we reached on the very first day — the storm had begun. It was time to add a questionnaire form before submitting resumes. Its purpose was to filter out candidates who weren't willing to make minimal efforts to submit their resumes, and those who lacked knowledge and context to at least Google the right answers.

It included standard questions about JS, markup, web, Computer Science — questions that anyone who knows what to expect in a frontend interview should know. What's the difference between let/var/const? How can you apply styles only for screens narrower than 600px? We didn't want to ask these questions in the technical interview — experience showed that they could be answered after 2-3 interviews without really understanding development. But they could initially show us whether the candidate understood the context at all.

In each category, we prepared 3-5 questions and day by day changed the set in the application form until we eliminated the easiest and the most difficult ones. This helped reduce the flow — in 3 weeks we received 122 candidates, with whom we could continue working. They were IT students; guys who wanted to move from backend to frontend; workers or engineers aged 25-35 who wanted to radically change their career path and put in varying amounts of effort into self-education, courses, and internships.

Getting to Know Each Other Better

For the company: The test task doesn’t scare off candidates, but helps narrow down the funnel.
For juniors: Don’t copy-paste tests — it’s noticeable. And keep your GitHub in order!

If we invited everyone for a technical interview, we would have to conduct about 40 interviews a week just for juniors and only for frontend positions. Therefore, we decided to test the second hypothesis — about the test task.

What was important for us in the test task:

To build a good scalable architecture, but without over-engineering;
It’s better to take longer and do it well than to whip something up overnight and send it with the comment “I’ll definitely finish it.”;
The development history in Git — engineering culture, iterative development, and the fact that the solution is not copied entirely shamelessly.

We agreed that we wanted to see one algorithmic task and a small web application. The algorithmic tasks were prepared at the level of initial course laboratories — binary search, sorting, checking for anagrams, working with lists and trees. In the end, we settled on binary search as the first trial option. The web application was supposed to be tic-tac-toe using any framework (or without it).

Almost half of the remaining guys managed to complete the test task — they sent us solutions 54 candidates. An incredible insight — how many implementations of tic-tac-toe, ready for copy-pasting, do you think are online?

How many?In fact, it seems that there are only 3. And in the overwhelming majority of solutions, there were precisely these 3 variants.
What we didn't like:

copy-pasting, or development based on the same tutorial without any personal architecture;
both tasks in one repository in different folders, with no commit history, of course;
messy code, violation of DRY, lack of formatting;
a mix of model, view, and controller in one class spanning hundreds of lines of code;
lack of understanding of unit testing;
A direct solution would involve hardcoding a matrix of winning combinations 3x3, which would be quite challenging to expand to 10x10, for example.

We also paid attention to neighboring repositories—great pet projects were gaining traction, while a lot of test assignments from other companies raised the question: why couldn't the candidate pass there?

In the end, we found some excellent candidates on React, Angular, and Vanilla JS—totaling 29. We also decided to invite one more candidate without a test due to their impressive pet projects. Our hypothesis about the usefulness of test assignments was confirmed.

Technical Interview

For the company: You're not dealing with mid-level or senior developers! A more personalized approach is needed.
For juniors: Remember, this isn't an exam—don't try to remain silent just to scrape by or overwhelm the interviewer with all your potential knowledge to the point they get confused and give you a passing grade.

What do we want to understand in the technical interview? A simple thing—how the candidate thinks. They likely possess some hard skills if they passed the initial screening—now, we need to find out if they can apply them. We settled on three tasks.

The first task is about algorithms and data structures. With a pen, on paper, in pseudocode, and using drawings, we discussed how to copy a tree or remove an element from a linked list. An unpleasant discovery was that not everyone understands recursion and how references work.

The second task is live coding. We went to codewars.com, selected not-so-complex tasks like sorting an array of words by the last letter, and during 30-40 minutes tried to get all tests to pass together with the candidate. It seemed there shouldn't be any surprises from those who managed to tackle Tic-Tac-Toe—but in practice, not everyone realized that the value needs to be stored in a variable and that a function must return something via return. Although I sincerely hope this was just nerves, and the candidates were able to sort out these tasks under less pressure.

Finally, the third task—some discussion about architecture. We talked about how to create a search bar, how debounce works in this context, how to render various widgets in search suggestions, and how the frontend can interact with the backend. Several interesting solutions were discovered, including server-side rendering and web sockets.

We conducted 21 interviews in this format. The audience was quite diverse — let's illustrate with comics:

‘Rocket’. It never settles down, gets involved everywhere, and during interviews, it overwhelms you with a stream of thoughts, not directly related to the question asked. If it were in a university setting, it would be a familiar attempt to demonstrate all one’s knowledge when you only remember last night’s decision not to study the material — you still wouldn’t draw it out.
‘Groot’. It is quite difficult to connect with him, because he is Groot. In the interview, you have to work hard to get responses word by word. It's good if it's just a mental block — otherwise, it will be very challenging in daily work.
‘Drax’. He used to work in freight transportation and only learned JS through Stack Overflow, which is why he doesn’t always understand what the discussion is about in the interview. However, he is a nice person, has good intentions, and wants to become a great frontend developer.
Well, and probably, ‘Star-Lord’. Overall, a decent candidate with whom a dialogue can be established.

Towards the end of our explorations 7 candidates made it to the finals, confirming their hard skills with a great test assignment and solid interview responses.

Cultural fit

For the company: You will work with him! Is the candidate really ready to work exceptionally hard for his development? Will he fit into the team?
For juniors: You will work with them! Is the company truly willing to invest in the growth of juniors, or will it just dump all the dirty work on you for a low salary?

Each junior, apart from the product team, whose lead must agree to take him, is assigned a mentor. The mentor's task is to guide them through a three-month onboarding process and hard skill development. Therefore, for each cultural fit, we acted as mentors and asked ourselves: ‘Will I take responsibility for developing the candidate over three months according to our plan?’

This stage went without any issues and ultimately brought us 4 offers, 3 of which were accepted, and the guys joined the teams.

Life after the offer

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

When a new employee joins, they need to be onboarded—introduced to the processes, informed about how everything works in the company and the team, and guided on how to perform their job. When a junior joins, it's important to understand how to develop them.

When we thought about this, we created a list of 26 skills that, in our opinion, a junior should possess by the end of the three-month onboarding period. This included hard skills (related to our stack), knowledge of our processes, Scrum, infrastructure, and project architecture. We organized them into a roadmap, distributed over a three-month timeline.

For example, here is the roadmap of my junior.

Each junior is assigned a mentor who works with them individually. Depending on the mentor and the candidate's current level, meetings can occur from 1 to 5 times a week for 1 hour. Mentors are voluntarily those proactive frontend developers who want to do more than just write code.

Part of the load on mentors is alleviated by courses in our stack—Dart, Angular. Courses are regularly held for small groups of 4-6 people, where participants work without interruption.

Throughout the three months, we periodically gather feedback from juniors, their mentors, and team leads, and we adjust the process individually. 1-2 times during the entire period, we conduct skill assessments, and a similar evaluation is carried out at the end—based on these, recommendations are formed on what should be improved.

Conclusion

For the company: Should we invest in juniors? Yes!
For juniors: Look for companies that carefully select candidates and know how to develop them.

In three months, we reviewed 122 surveys, 54 test tasks, 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 tackling real product tasks in our project, which has more than 2,000,000 lines of code in the frontend and over 400 repositories.

We found that the funnel for juniors can and should be quite challenging, but ultimately only those who are truly ready to work hard and invest in their development pass through it.

Currently, our main objective is to complete the three-month development roadmaps for each junior through individual work with a mentor and group courses, gather metrics, feedback from leads, mentors, and the juniors themselves. This will allow us to consider the first experiment complete, draw conclusions, improve the process, and restart it for selecting new candidates.

Source: habr.com

How to train a junior?