This is a series of articles. The following can be read here.
What to expect and how to help grow a trainee developer into a confident junior?
The level of the developer is what everyone is used to measuring and what everyone is running from company to company for.
In the past few years, the market trend is such that real work experience is reduced in relation to the offer :: tag ::.
This topic bothers me especially for the reason that years of experience still talk about something. They talk about the amount of time during which you worked the work. And it is purely statistically true that more makaps and pairs can occur in m
time than in n
, provided that m > n
. That's all. This is evidenced by years of experience. This is not the indicator by which I will sift people out of positions (I will, if it’s a senior, with 1.5 years of real experience), but the one by which I will decide between two identical candidates if I can’t take two.
So, my favorite type of developer is trainee . These are absolutely beginner guys, it does not matter what their age_pol_religion is, they show from the first day whether their eyes are burning. Further, a technical matter, as one good friend of mine says: “you can teach a monkey how to write a code,” and we teach ... not a monkey, of course ... but a person. We teach, we tell, we drive out of work when they linger, and they like to linger, because everything is interesting. At this stage, the task of the developer is to learn how to work with tools, to understand that the water is wet, the fire is hot, and the stand-up from the word "stand". Each language has a typical task. In Rub - Hartle and his aka Twitter. In javascript, everyone wildly loves that kind of sheets and all kinds of implementations for the framework with which you work. If he can write it on a step-by-step guide, he fits the trainees. When he can write it without a step-by-step guide, you can talk about June. I specifically emphasized step-by-step here, because no matter how much experience you have, you will run on MDN to look at the order of parameters in reduce
and forget the basic constructions.
Further Junior - and there is no abrupt transition. He is smooth. And that is why our company has made a division into Junior Beginner / Junior / Junior Strong. But this is the stage at which you can immediately see what culture is in your team, I will end with this thought the section on Junior.
At the Junior level , a person already knows how to write code, but this code does nothing more than solve a business problem here and now. And this is normal, this is what technical team, mentor or training department will have to work with. At this stage, you need to explain to the person the life cycle of the bug, why self-testing is important, how the cost of the bug changes depending on the stage at which it was found.
To help him think and understand what he is dealing with most of the time. That is, if he sends requests from the browser to the backend for half a day, he figured out what the request is and why the browser sends 2 requests when you have a backend on another Origin. He begins to become aware of the processes in development. Gradually notices how wrong he is in the estimates.
This is the stage when it is worth playing scrum poker with a person and making a top-down assessment of the task, even if you haven’t accepted this as a team.
He should learn to formulate thoughts, to argue position, for this we must begin to point out things that are not obvious. Why I said about scrum poker and top-down. This is a great way to show a person the nuances that you are paying attention to because of already accumulated experience, what details you are clarifying, which specs you no longer seem vague, and HOW you do it.
The results of a joint assessment will show technical skills, but it is equally important to teach how to formulate questions, show how to communicate with clients or stakeholders, how to enter the received information into the system.
The sooner a developer learns to pay attention to details and how to communicate on tasks with stakeholders, the easier it will be for him. Because projective communications and the analysis of incomprehensible is our conscious way to shove ourselves into the unknown and get a +1 new case in our experience.
Personally, I do not expect at all that at the junior level he will at least get a little into his grades in big features, in small ones - maybe, but not a fact. In large - no, still knows little about risks, does not take into account testing, client psychology and does not understand the difference between the rating in hours and ETA.
What is also important is to learn the basic skills of application debugging, to understand how to find changes, several sessions of pair programming with the June, and you will give him the skills of primitive, but so "ingenious" techniques for the June like instance.freeze
to catch the mutation of the object. He needs to learn how to use this whole multitool, not always efficiently, but at least he should know that there is a screwdriver and do not hammer the screws with a hammer.
Finishing to describe Junior` , we will return to team culture. At this level, a person will absorb the team’s communication culture, if you shake testers and consider them useless, but don’t realize this, look at June and remember if he was like that half a year / year ago. Did he behave the same way towards these people? If "no" in the negative direction, then here's the bell. He learned this from you and your environment. He still cannot clearly say why something is not important, but it is already sheimit. Moreover, we all already know that each stage in the development of an application is important and whatever the team, without a tester they will release the product worse or slower and more expensive.
Initially, I published an article on Medium , but it seems to me for the segment with which I want to start a conversation - this is a bad platform. I will omit part of the intro, if you want to talk, write to @_golubev .
I gave this section the name work & dev fun (damentals) . Because work and development is fun. But you need to learn fundamental things. It doesn’t matter whether it’s a soft skill or a hard skill.
Everything described below is the experience that I have gained. It is limited to my understanding of things happening in IT. The processes that take place here. The decisions that are made. This understanding allowed me from Trainee to one of their leads in a full-stack direction. In parallel, create a department that specializes in technical development and monitoring the emotional state of employees, in order to make their work comfortable and provide them with a concrete understanding of what is expected of them in the company and the project.