Continuing the previous part, let's talk about junior programmer candidates searching and their integration into your team. In this part I'd like to share my experience of forming a vacancy, more precisely its format. I'll try to tell you how to create the most attractive, honest and, not less important, informative vacancy card.
Like in the previous part, I'd like to remind you, that I'm just sharing my own experience and expressing the personal opinion. No more than that.
One of the most important criteria of your search success is the right choice of HR platform. Since we are working with IT segment, I'd like to recommend the Habr Career.
For an extra traffic source you can use Head Hunter, LinkedIn (blocked in RF) and various telegram channels. For example: a good channel to find java developers, this will help to find mobile developers, or you can use your personal sources, if you have them.
Now, important thing. I always recommend to keep your writing short and to the point. If you're looking for a frontend developer, just write so. However, if you want to cover all of the relevant cases, you may have some trouble with it. Therefore, here is the list of the keys:
Consequently, now you have two options. Either you spend a lot of money (but why?), or you'll try to squeeze all of them in one header. However, there is a chance, that after you'll do it, UFO will kidnap you for experiments.
Basically, it depends on who are you looking for and for what specific goals. Since this article's theme has been stated, we will discuss intern/junior positions. I don't know why Habr splits this position, making you able to save money on interns, so be it.
Personally, I'm taking interns when I'm looking for junior developers, whom I'm going to give a full cycle training. According to my criteria, an intern is someone who knows programming languages basics, but knows nothing about technological aspects. I hope everyone agrees, that it's much easier to teach the well-read guys soaked in misconceptions and legacy of the previous developers' generations.
In the same vein, juniors are the guys who know parts of the programming languages and some technologies in an advanced way: React, Vue, Angular and suchlike. Usually these guys can write something that looks like a web-application. Recently, I've started to demand the knowledge of “hooks” for applicants of a junior developer position in my team. You won't get far without knowing them nowadays.
I think it's fair to pay your intern at least ?30k. And if they're smart enough, don't afraid of overtime work, and are overall qualified, you can raise a salary to ?50k.
Meanwhile junior developer's fair salary comes from 50k to 70-80k, depending on his skills.
It's a dynamic thing, I've never had constant established tariffs. For example, I'd had a junior programmer working for me. His HTML skills were decent, but when it comes to internal logic there were a lot of problems. In the end he'd simply burn out. For people like that ?40k is a maximum.
Above all, I think it's important to use blocks, while describing your vacancy. Split it on sections, use headers – readability will be better. Everyone should decide for himself, but I have my favorite template:
I'm trying to present my team in the most friendly and informal way, at least as much as I can.
However it's hard to present all relevant points in one paragraph. The first one must be short, otherwise it won't hold the target audience's attention, and therefore they won't be hooked.
Here I'll try to tell you about our team's main kind of activity. Usually I write in general, trying to explain in what fields and directions we work. I mean, I write that we like to make various *aaS, eCommerce, B2B, Digital projects and also a couple of other already launched examples or what we work on public with; just for illustrative purposes.
It's also necessary to indicate the current projects where Junior's run-in will be. It's important for the reason that someone may not like Digital field, or someone just fiercely hates rap, and won't agree to work on any project under any conditions.
This block will be dedicated to the description of people I'd like to see in my team. By the way, about skills, I always prefer to mention them in this block. For example, I often write about our team using various Github features and hope that our new candidate favors them too.
At the same time, I'm trying to mention a social activity. For example, candidate can write something in social nets, or they can be subscribed on top web-designers. The main idea: “I'd like you to have skills like that, or at least I want you to aspire to have skills like that”.
I also find that it's important to write about things that we like or don't like. It'll help to weed out people that won't fit in your team. For instance, the questions like: “ Do we have 8-hour work day?” or “ Are we free on that holiday?” — are the prime indicators of candidates' work ethic. Same goes for ardent supporters of technologies we, as a team, choose to avoid.
Usually this block is dedicated to the technological stack and tools we expect to work with.
Especially, I tend to focus on Github and Octokit
The point is, ">Github has an excellent search, actions and its own API and knowledge of them is necessary for our work, and therefore it's better to know in advance if you can work with Github or not, because our further work with a junior will directly depend on it.
I don't know who gives what bonuses, but I always root for the Apple computers at work, and for those who lasted longer than a trial period I provide any «config» to choose, by installments, interest-free, without deadlines and for any period of time.
By the way, recently I have started to encourage a healthy lifestyle. Since I sick and tired by constant complaints about headaches, loss of concentration, lack of sleep and other outcomes of our practice.
I have always been thinking about it. But there has always been the question of expediency and resources. Resources have come, expediency haven't lost, and guys still moping and lollygagging in the critical days.
That's why in such bonuses (especailly for developers and other types of sedentary) I would also include a payment for a healthy lifestyle. Of course everything will be considered indvidually, because someone can't swim, someone can't jog and someone can't just lift weights etc.
In short, take care of your teammates or you'll have a constant staff replacement.
Firstly, I'd like to address to recruiters and owners of such companies. Always! No… NEVER! Never write in your job pages that aspirants can write you on an e-mail, especailly their code examples, last projects and other rubbish. Why? Because all that should already be on a resource where job is posted. I mean, such resources are being made to avoid all these excess, intermediate links no one even give a damn about.
In my additional instructions I severely punish in response to leave a link to a solved introductory task, the rest is optional.
All responses without references to forks with a solved introductory I was just deleting. On the last job page were 90 people total who left responses.
Sad fact, according to Github statistic there were almost a 1000 of those, who couldn't solve the task. If you've managed to hold your attention till this point, congratulations, we're getting to the most interesting part of this article.
After four years of headhunting, I'd come to conclusion – don't try to do everything yourself I'd lost a lot of money, when i'd decided to spend my time looking for good employees, instead of looking tor a customers.
We'd decided to create fully functional repository with functional backend and frontend services and then… to break it.
To clarify, the whole testing was split on introductory and test task.
I am using monorepo approach for most of our projects.
So, monorepository was broken and this way introductory task was created.
Additionally, we'd broken some parts of redux and other code. That's how frontender's test task was created. Backender's task was made similarly.
However, I have to admit, that at that point frontender's circumstances for completing their task were better. There was a fully functional GraphQL API on our technical domain for them to work.
Backenders were less lucky. Back then I didn't know how to give them a task without connecting them to our devops environment. I'd found solution, but after we'd already started.
Additionally, I can say that backenders task was pretty hardcore. But we'd found people who'd managed to solve it. People who were interested in this particular stack: Typescript, NestJS, GraphQL, CQRS, Protobuff, gRPC, *DD. There was two of them.
In conclusion of the second part, I'd like to say:
In the next part we'll talk about how to integrate new junior programmers in your team's processes and how to help them to adapt in the new team or maybe even in their first team.
Like in the previous part, I'd like to remind you, that I'm just sharing my own experience and expressing the personal opinion. No more than that.
Making a vacancy card
One of the most important criteria of your search success is the right choice of HR platform. Since we are working with IT segment, I'd like to recommend the Habr Career.
For an extra traffic source you can use Head Hunter, LinkedIn (blocked in RF) and various telegram channels. For example: a good channel to find java developers, this will help to find mobile developers, or you can use your personal sources, if you have them.
How to name a vacancy
Now, important thing. I always recommend to keep your writing short and to the point. If you're looking for a frontend developer, just write so. However, if you want to cover all of the relevant cases, you may have some trouble with it. Therefore, here is the list of the keys:
- Front-end
- Front end
- Front-end developer
- Front end developer
- Front-end dev
- et.c
Consequently, now you have two options. Either you spend a lot of money (but why?), or you'll try to squeeze all of them in one header. However, there is a chance, that after you'll do it, UFO will kidnap you for experiments.
Qualification
Basically, it depends on who are you looking for and for what specific goals. Since this article's theme has been stated, we will discuss intern/junior positions. I don't know why Habr splits this position, making you able to save money on interns, so be it.
Personally, I'm taking interns when I'm looking for junior developers, whom I'm going to give a full cycle training. According to my criteria, an intern is someone who knows programming languages basics, but knows nothing about technological aspects. I hope everyone agrees, that it's much easier to teach the well-read guys soaked in misconceptions and legacy of the previous developers' generations.
In the same vein, juniors are the guys who know parts of the programming languages and some technologies in an advanced way: React, Vue, Angular and suchlike. Usually these guys can write something that looks like a web-application. Recently, I've started to demand the knowledge of “hooks” for applicants of a junior developer position in my team. You won't get far without knowing them nowadays.
Reward
I think it's fair to pay your intern at least ?30k. And if they're smart enough, don't afraid of overtime work, and are overall qualified, you can raise a salary to ?50k.
Meanwhile junior developer's fair salary comes from 50k to 70-80k, depending on his skills.
It's a dynamic thing, I've never had constant established tariffs. For example, I'd had a junior programmer working for me. His HTML skills were decent, but when it comes to internal logic there were a lot of problems. In the end he'd simply burn out. For people like that ?40k is a maximum.
A vacancy description
Above all, I think it's important to use blocks, while describing your vacancy. Split it on sections, use headers – readability will be better. Everyone should decide for himself, but I have my favorite template:
About company
I'm trying to present my team in the most friendly and informal way, at least as much as I can.
However it's hard to present all relevant points in one paragraph. The first one must be short, otherwise it won't hold the target audience's attention, and therefore they won't be hooked.
What we do?
Here I'll try to tell you about our team's main kind of activity. Usually I write in general, trying to explain in what fields and directions we work. I mean, I write that we like to make various *aaS, eCommerce, B2B, Digital projects and also a couple of other already launched examples or what we work on public with; just for illustrative purposes.
It's also necessary to indicate the current projects where Junior's run-in will be. It's important for the reason that someone may not like Digital field, or someone just fiercely hates rap, and won't agree to work on any project under any conditions.
Who are we looking for?
This block will be dedicated to the description of people I'd like to see in my team. By the way, about skills, I always prefer to mention them in this block. For example, I often write about our team using various Github features and hope that our new candidate favors them too.
At the same time, I'm trying to mention a social activity. For example, candidate can write something in social nets, or they can be subscribed on top web-designers. The main idea: “I'd like you to have skills like that, or at least I want you to aspire to have skills like that”.
What we don't like
I also find that it's important to write about things that we like or don't like. It'll help to weed out people that won't fit in your team. For instance, the questions like: “ Do we have 8-hour work day?” or “ Are we free on that holiday?” — are the prime indicators of candidates' work ethic. Same goes for ardent supporters of technologies we, as a team, choose to avoid.
What we are working with
Usually this block is dedicated to the technological stack and tools we expect to work with.
Especially, I tend to focus on Github and Octokit
The point is, ">Github has an excellent search, actions and its own API and knowledge of them is necessary for our work, and therefore it's better to know in advance if you can work with Github or not, because our further work with a junior will directly depend on it.
Bonuses
I don't know who gives what bonuses, but I always root for the Apple computers at work, and for those who lasted longer than a trial period I provide any «config» to choose, by installments, interest-free, without deadlines and for any period of time.
By the way, recently I have started to encourage a healthy lifestyle. Since I sick and tired by constant complaints about headaches, loss of concentration, lack of sleep and other outcomes of our practice.
I have always been thinking about it. But there has always been the question of expediency and resources. Resources have come, expediency haven't lost, and guys still moping and lollygagging in the critical days.
That's why in such bonuses (especailly for developers and other types of sedentary) I would also include a payment for a healthy lifestyle. Of course everything will be considered indvidually, because someone can't swim, someone can't jog and someone can't just lift weights etc.
In short, take care of your teammates or you'll have a constant staff replacement.
Further instructions or CTA
Firstly, I'd like to address to recruiters and owners of such companies. Always! No… NEVER! Never write in your job pages that aspirants can write you on an e-mail, especailly their code examples, last projects and other rubbish. Why? Because all that should already be on a resource where job is posted. I mean, such resources are being made to avoid all these excess, intermediate links no one even give a damn about.
A living example, just recently I was contacted by some Katlyn from BlueReceipt company, another sub-integrators of Shopify.
She had suggested to skip the first part, and start «30-minutes JavaScript test» to test my skills. Apart from the fact that website was awry, there also were not working links and grammatical mistakes are as stupid as a personnel itself.
……
Well. OK. It's acceptable. But not when they contact me via CodersRank profile...
Don't do that. If you use instruments for mundane tasks' automation, just use them and don't irritate people with your obsoleteness and stupidity.
In my additional instructions I severely punish in response to leave a link to a solved introductory task, the rest is optional.
All responses without references to forks with a solved introductory I was just deleting. On the last job page were 90 people total who left responses.
Sad fact, according to Github statistic there were almost a 1000 of those, who couldn't solve the task. If you've managed to hold your attention till this point, congratulations, we're getting to the most interesting part of this article.
Introductory and test tasks
After four years of headhunting, I'd come to conclusion – don't try to do everything yourself I'd lost a lot of money, when i'd decided to spend my time looking for good employees, instead of looking tor a customers.
We'd decided to create fully functional repository with functional backend and frontend services and then… to break it.
To clarify, the whole testing was split on introductory and test task.
I am using monorepo approach for most of our projects.
So, monorepository was broken and this way introductory task was created.
Additionally, we'd broken some parts of redux and other code. That's how frontender's test task was created. Backender's task was made similarly.
However, I have to admit, that at that point frontender's circumstances for completing their task were better. There was a fully functional GraphQL API on our technical domain for them to work.
Backenders were less lucky. Back then I didn't know how to give them a task without connecting them to our devops environment. I'd found solution, but after we'd already started.
Additionally, I can say that backenders task was pretty hardcore. But we'd found people who'd managed to solve it. People who were interested in this particular stack: Typescript, NestJS, GraphQL, CQRS, Protobuff, gRPC, *DD. There was two of them.
Summarizing
In conclusion of the second part, I'd like to say:
- You should try to optimize the amount of time you'll spend looking for employees. Delegating is important and interaction between current and potential members of your team will further test candidates personal qualities.
- If you want your team to be united, long term — make your people happy. And high salary is not everything, because some people do not know how to spend their money properly. Encourage a healthy lifestyle, buy useful tech for your team, don't forget their birthdays and so on.
- Don't be stupid. Don't make them do same routine procedures, like sending you info about their latest project. It's 2020, do the background check yourself.
- Make sure your teammates are qualified by the modern standards, otherwise, sooner or latter your team won't be able to answer the challenges that developing technologies are constantly presenting.
In the next part we'll talk about how to integrate new junior programmers in your team's processes and how to help them to adapt in the new team or maybe even in their first team.