In continuation of the previous part about a searching of juniors and their integration into your team.
In this part I’d like to share my experience of forming a job page, or rather its format. I’ll try to tell you how to create the most attractive, honest and, not less important, informative job page.
Like in the first part, I’d like to remind you, that I’m just sharing my own experience and expressing my 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 to use 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 “Frontend developer”. However, if you want to cover all kinds of cases, you may have some issues, since there are a lot of them:
Here you can either spend a lot of money (but why?), or you can try to squeeze them all in one header. But you’ll be abducted by UFO for further experiments.
It all depends on who are you looking for and for what specific goals. According to the theme of this article it’s an intern/junior. I don’t know why Habr splits them, and makes it possible to save money on interns, so be it.
I take Interns when I’m looking for Juniors for a full cycle training. According to my criteria, an Intern is someone who knows the basics of programming languages, but knows nothing about technological aspects. I hope everyone agrees, that it’s much easier to teach well-read guys already soaked in prejudices and legacy of the previous developers’ generations.
Juniors are the guys who know programming languages and some technologies in an advanced way: React, Vue, Angular and suchlike, these guys can write something that looks like a web-application. Recently, I’ve started to demand the knowledge of “hooks”, because 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, initiative and are overall qualified, you can raise a salary up to ₽50k.
For juniors, I consider it’s fair to pay them from ₽50k to ₽70-80k, depending on their skills.
It’s a dynamic thing, I’ve never had firmly established tariffs. Let me tell you about a special case from my own pratice. I had me a junior, Sasha. His HTML skills were decent, but when it came to a store, logic and all that, he would either stall or dissapear. In the end he had just simply burned out and vanished. He had finally contacted me after a month and change. For a people like that 40k rub is a maximum.
I think it’s important to use blocks, while describing your job page by splitting it on sections through headers – it increases the readability. Everyone should decide for himself what is important and what is not, but I have my favorite template:
I try 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 your target audience won’t see the main blocks in the first seconds (and they are crucial) by which you have to hook a person.
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.
In this block I will describe an approximate “picture” of a person I’d like to see in my team. By the way, about skills and tools knowledge, I also try to mention them in this block. For example, I often write that our team is activily using various Githab features and hope that our new candidate favors them too.
At the same time, I’m trying to mention a social activity. For example, someone can write something in social nets (it’s a rare case in our circles), or they can be subscribed on top web-designers like Behance and such. I mean my point is: “ I’d like you to have skills like that, but if you don’t, 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’m 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, especially 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.
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.
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 mad 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.