Hi, Habr! My name is Andrey Gomenyuk, I am a team leader of one of the Badoo server development teams .

In May, Badoo Techleads Meetup , dedicated to managing development, I shared the experience of integrating newcomers into the team. And today I am sharing a text supplemented and improved version of my report.

Imagine today your first working day at Badoo. What kind of knowledge and skills does the department expect from you, and in particular, I, the manager? At least such:



Notice that there is nothing like “writing in PHP” and “know MySQL”. We ask about this at the interview. And in this list - all our tools, technologies and terms, as well as common things that we most likely do not like everything. And the sooner you get to know all this, the better.

Badboard onboarding

The term onboarding means entering a person into a team, familiarizing him with the project and processes. Since our server development department has doubled in the last couple of years (there are more than forty of us now), we were the first to join Badoo in intensive adaptation of newbies and their integration into work.

I highlight the two main objectives of onboarding.

The first is short-term. We, like most IT companies, really want to put a person on the code on the very first day, put his tickets in production on the very first week so that a person can learn as quickly as possible. However, this is not the main thing for us.

The second goal is long-term. We want people to reach a certain level of independence as soon as possible.and began to effectively solve the tasks.

To do this, we spend a newbie through five not very obvious stages. But before I talk about them in order, I will note two equally important points.

Who will meet the novice

On the first working day, we will definitely meet a newcomer. This should make the lead, and we in the department try to follow this rule. Lid meets a man, shows him the office and introduces him to the team. Then a pre-arranged meeting with the personnel department is held, during which documents are drawn up.


Source

It would seem that after that you can already put a person at the table, but there is another important detail.

Who will "lead" the novice

In some companies, the entire onboarding process is “tied” to the mentors. These are people who explain everything, show that, where and how, they answer the questions of a novice and bring him to the right people.

We do not use this term, but as it is sung in a famous song, there is a mentor, but there is no word. Just this role is assigned to the lead, which can delegate it to someone from the staff. As a rule, a lead (or a person appointed by him) is for the beginner an entry point for all questions. During a small meeting, he introduces the newcomer to the project, talks about the processes adopted in the company. This is the beginning of the transfer of our culture to a person who has previously worked in other companies and is used to doing things differently. And it is very important that the newcomer understand what, how and why we are doing.

Stages of onboarding

I will allow myself to break our whole process into several stages, each of which has some kind of result:

• man sits at a laptop
  
• with a customized working environment
  
• and makes tickets.
  
• Can design a new feature
  
• and work independently.
  

Next, consider what happens at each stage.

1. Laptop

Firstly, we want the newcomer to focus on work, rather than think about something unimportant, and we are trying to do a lot in advance. Therefore, we contact him in advance and find out the wishes of the equipment: what the monitor, laptop, keyboard, mouse wants. We create for the beginner all accounts and issue privileges, add it to groups and chats. Many of these procedures are automated, while others are added to the checklists so that a person doesn’t run around the office on the first day, figuring out why he cannot get to Jira or why he doesn’t see the ticket that was assigned to him.

2. Working environment

Then a person sits down at a laptop to set up a working environment. But the whole setup is that he enters a special interface, chooses a login and downloads an SSH key. Is done.

The fact is that we have a platform platform, an analogue of our production infrastructure, raised in the office. Moreover, in order to emulate several DCs, we have a platform platform in both offices: in London and in Moscow. This approach has many advantages. On the dev, there are always current versions of the code and the latest software - absolutely the same as in production. Even if something does not work, you can be sure that someone is already engaged in solving the problem. A newbie, in fact, simply clones the repository, opens the IDE - and is ready to work. It’s enough for Lida to make sure that he was able to enter all the chats and started receiving mail.

At this stage, I am ready to give the novice the first ticket.

3. Tickets

Suppose the first ticket came this way:



Or this:



Probably, these tickets for you are united only by one thing - nothing is clear. I singled out the orange words that most likely will cause you the most questions, and even if not, I will tell you about them anyway.

As it was before

When I came to Badoo seven years ago, it was like this. Lead sits down to the newcomer and begins to tell: “Look, we have queues, a scripting framework. They work like this. Pay attention to this. In this ticket you will need to do it . "

The problem is that the lead spends his work time on these stories. Every time he explains the same thing to newbies, but he always forgets about something. Each lead tells in his own way.

Naturally, the lead will only give specific introductory notes on the ticket, which relate to this ticket, losing moments that the newcomer may not need right now. If you are lucky, the latter will be able to find a link to the description of a tool. But usually all such documentation is written for internal use, that is, it is assumed that the user is already familiar with the specifics. There are a lot of details in the documentation, which in the first stages are definitely not needed for a beginner. As a result, a paradoxical situation developed: the person worked in the company for a year or two, but there is no guarantee that he familiarized himself with everything and knows how the entire infrastructure works.


Frame from the movie " Groundhog Day "

In addition to colleagues who answered various questions, Aleksey Rybak, who was in charge of the Platform at the time, gave a lecture to all new employees on basic principles, infrastructure, and basic services. At some point he got tired of it, and he recorded it on video. But in a two-hour story, everything does not fit, a lot of details. And then this lecture is very difficult to update. Of course, it's cool that in seven years it is not very old, but some of its parts are irrelevant.

At some point, someone created the “Welcome new developer” page on the Wiki. They put a bunch of links there that it would be good to read to the developer.

Probably not much mistaken if I say that in any company there are two main sources of obtaining new information: this is some kind of analogue of the Wiki (or Google Docs) and a smoking room. Unfortunately, only in one of them the information will be relevant, and this is not a Wiki.

That page of ours did not have a common structure. She replenished like this. The lead of the other team comes up to me and says: “Andryukha, your developers are doing badly. To do well, I wrote an article on the Wiki. I added it to Welcome new developer so that all your developers must read it . ”



Naturally, he considers his article to be the most important, places it in the most prominent place, highlights it in bold, red. As a result, one large page falls on a newbie with a bunch of links that he may need. With plentybold phrases , MUST READ and "Read a must!".

At some point, we realized that lectures, videos and Wiki are no longer suitable for us. We decided to take all the best of these tools and make something new. And we threw the right idea to us ... the Laravel framework. Do not think for advertising. Just at that time, we just picked up a framework for one project, in a search engine at the request of the “best PHP framework” Laravel jumped out in the first place, and we took it. And we really liked the Quick Start section of the document, where the real example tells about the basic principles and the tools available (and, having understood the basics, you can start reading the detailed description).

Quick start

We really liked this format, and we decided to write a similar article for our newbies. But how to do that? There is a lot of information - how to strike a balance between conciseness and informational content, while retaining the possibility of timely updating, so that newcomers do not have to draw knowledge from the smoking room? And how to stimulate to read the document of those who have been working in the company for some time, but surely have gaps in knowledge?


A source

We started by compiling a list of tools, technologies and approaches that we think every developer in the department should know. Then they structured the information in the form of a table of contents, from simple to complex: from databases and services to performance and testing. Then one person wrote the first few chapters so that the rest understand how to submit the material. After that, we voluntarily-forcedly distributed the remaining topics to other employees, and each wrote a chapter. The result was a huge document, a week for two readings alone.

We could not come up with one common task for the entire Quick Start section. Yes, it would be ineffective. Imagine that you give a person a task - in fact, one huge feature that covers all sections. He will work on it for a month or two, and all this time you can not distract him with tickets, and this is contrary to the first goal of onboarding.

Then in each section we placed one or two tasks that are as similar to the real ones as possible. A beginner reads a section, works on tasks, gets acquainted with specific tools. Some of the tasks we recommend to our leads are carried out according to the standard process: a ticket is put, a person is pushing a code, a code is being revised, a person receives a lot of feedback. After that, the branch is removed, and with it the ticket.

Then the question arose of how to maintain the relevance of all this array of information. And here the same tasks helped us. For example, we have spots (virtual shards) and a service that is responsible for matching users and spots. In normal life, developers do not need to know about this, because they use a high-level API. But we require them to understand how it works inside.

We give the task: to register a user on the devel, to get a spot identifier by his mail address, to obtain database data on a spot, go there, select and see what is there. If something changes in this procedure, then ordinary developers will not know about it. They will not know what to enter and correct the description. But the developer, who is currently engaged in this, will understand: something is wrong. He will approach the lead and say that something is not working. The lead will sit down with him, figure it out - and we will update the document. We try not to encourage developers to change Quick Start on their own so as not to disturb the structure and style of presentation. Instead, we created Google Doc, in which they can write their wishes. Then this list is viewed by a responsible officer who makes changes to our article.

New information is added to Quick Start in the same way: someone is faced with a new tool that is not described in the document, and writes about it in Google Doc. And the responsible people then decide whether this is a particular case, which is not interesting to most developers, or is it worth writing about it in Quick Start.

The developers themselves sometimes add funny “ryushechki” to the document. For example, in each chapter added a reading time counter and the number of pages. Also in some sections added links that immediately open the desired class in PhpStorm.

Then we began to think about how to make the document of the “oldies” go through? After all, Quick Start turned out to be huge, and nobody wanted to spend two weeks on reading it. Then we came up with a test: on the basis of the document, we compiled about 100 questions on various topics and offered everyone to anonymously pass it. Each developer was given a choice of about 40 questions. The goal was not to test knowledge, but to help people understand what they do not know. That is, the test was a learning tool, not a test, and if you answered the question incorrectly, you were immediately offered hints and links where you can read about it in Quick Start.


Sample test question

We have no control over the passing of the test by beginners. It is believed that for them it will be a logical conclusion to the study of Quick Start. At the same time we keep statistics on all the answers. When the “oldies” passed the test, we selected a few questions that they did not answer the way we would like, and asked the experienced guys to write articles on these topics.

Quick Start and the test is the most impressive part of our onboarding process.

More tickets

Usually, together with Quick Start, one or two simple tickets are given to a person at once. Gradually, their number increases, and the lead ensures that the new tickets correspond to what the developer had time to read. Thus, the reading process is diluted with real work, and all this takes about two months. Ideally, by the end of the trial period, the person should be perfectly oriented in our infrastructure, tools and approaches.

After you read Quick Start, the meaning of the above tickets will be much clearer to you:



From here, as a lead, you only need to give a small introductory one: there is a field in the spot and a field in the service, they are not synchronized for the user; need to fix the bug and synchronize. And what script to run and how to do it, the novice already knows.

Or a second example:



Here is the same thing: the photo got into the wrong album; most likely, the client just sent the wrong album; you need to understand whether there are still such cases, and fix it.

Tickets are, in fact, simple, for an hour of work.

4. Designing a new feature

By “design,” I mean not the organization of classes and code, but how a novice will work with data, create tables, what events will add, where they will be transferred, and what services a person will access. At this stage, the novice is ready to make technical decisions about how features are made. This is usually achieved by practice. The more tasks, the more knowledge and experience.

True, this is not always possible, because it is not possible to find a sufficient number of interesting problems for each beginner. In the test, such topics are often also difficult to cover, because situations are different. In different cases, you need to apply to different services, and everywhere their features.

As a result, we simply collected a dozen really large features in which different services, queues, spots were involved, and the developers prepared brief descriptions for them (an analogue of the technical task). When the novice is ready, the lead gives him a choice of one task. He thinks about it for a while and says that he is ready to discuss the decision. A meeting with the author of the feature is scheduled, at which the developer explains his scheme: he would have done so, would have turned to such a service, would have kept the data here, would have subscribed to such events. In response, the author tells how he did and what he paid attention to. As a result, the developer learns a lot of new things, he begins to take shape the overall picture. He understands how this or that process works, how we make decisions. It's okay if he got into the code in advance and looked at how the feature is implemented,

At the end of the meeting, the lead collects feedback and may offer the developer to study a section more carefully and think about what he has learned.

5. Independent work

The fifth stage, in fact, is not expressed in any way. These are the things that we do throughout the work in the company. We really appreciate the desire of the developer to communicate with other teams, to find out how it works. If something does not work, you need to know who to ask for help. The task of the lead is to introduce the newcomer to everyone, show who sits where, tell whom and in which case you can apply.


A source

A person should be guided in our processes. Although we do not have Scrum and Agile, the workflow is quite flexible. We really appreciate when the developer does not just mindlessly follow our processes, but understands why they are and what tasks they solve. This allows him in some situations to find workarounds. For example, to understand that one or another ticket can be sent without conducting full testing, and the other one needs to be done quickly. We tell you who to contact and how to set priorities so that the ticket goes into operation today.

We expect from a new developer that during the trial period he will get acquainted with the maximum set of our features and components. Ideally, by the time the trial period ends, he will know some component or feature deep enough to be able to accompany it.

We also almost immediately add a person to the performance review , just so that he can receive feedback not only from his lead, but also from everyone with whom he interacts: from grocery, QA- and client teams.

Results

Here, perhaps, are the five main components of our newbie entry process:

• Minimum attention unimportant. We do everything so that a person concentrates on work and is not distracted by trifles (including household ones).
  
• Quick start We didn’t dare to start it for a long time and believed that this was impossible to do. But it turned out to be easier than we thought, but it paid off many times already.
  
• Test. In terms of the ratio of the benefit gained to the time spent, he somewhat loses Quick Start, but is also an important element of the learning process.
  
• Practical tasks.
  
• Feedback from the team and lead. The bigger, the better.
  

results

I have not come up with any objective measurable indicator that would demonstrate the obvious effectiveness of the approach to integrating newcomers into a company described in this article. But if they came to me a couple of years ago and asked if I was ready to hire more than one person at a time, I would definitely refuse, because my team would simply not “digest” it.

Previously, we spent a lot of time on putting newcomers into service. And now we carry out the whole events on hunting . We allow ourselves to hire two or three people in a team at once. That is, an indicator that we have exactly improved - the scaling of hiring.


A source

What's next

We have an idea - to turn Quick Start into a framework, that is, to break it into logical elements, by pages. All engineering teams will be able to write their articles and form their own Quick Start.

In addition, we are not entirely satisfied with the existing format for solving practical problems. If Quick Start greatly simplifies the work of the lead, then practical tasks complicate it, because the leader needs to choose a task, allocate time for the developer to work on it, agree with the accompanying feature, hold meetings, collect feedback. Instead, we are thinking of holding mandatory meetings with every newcomer once a week for a month or two with several team members. At these meetings, he will be able to ask questions about everything that is incomprehensible to him. And if he has no questions, you can offer to discuss one of the tasks.

Finally, remember the first picture with a bunch of terms? You probably thought: "Why so much?". It looks as if everything is too complicated and the developer probably does not need to know about all this. Reading Quick Start, it is very easy to see things that can be simplified, and we are working in this direction.