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 newbies 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 (now there are more than forty people), 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 in the very first week so that a person learns as quickly as possible. However, this is not important for us.



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



To do this, we spend a beginner 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.





A 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 mentors. These are people who explain everything, show that, where and how, they answer the beginner's questions and bring him together with the right people.



We do not use this term, but as it is sung in a famous song, there is a mentor, but no words. 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 novice an entry point for all questions. During a small meeting, he introduces the beginner 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 previously worked in other companies and was 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 work 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 the person on the first day does not run around the office, figuring out why he cannot get to Jira or why he does not 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 consists in the fact that he enters a special interface, chooses a login for himself and loads 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 current 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 beginner, in fact, simply clones the repository, opens the IDE - and is ready to work. It is 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 like this:







Or this:







Probably for you these tickets 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 give only 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 some 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 that 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 Wiki (or Google Docs) analogue 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 as the most important, places it in the most prominent place, highlights it in bold, red. As a result, one large page falls on the newbie with a bunch of links that he may need. With an abundance of bold 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, which, using a real example, describes 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 worked for some time in the company, 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 reading alone.



We could not come up with one common task for the entire Quick Start section. Yes, it would be inefficient. 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 contradicts the first goal of onboarding.



Then in each section, we placed one or two tasks that are as close to real as possible. The beginner reads the section, works on tasks, gets acquainted with specific tools. We recommend our leaders to carry out some of the tasks according to the standard process: a ticket is put, a person pulls a code, a code is revised, a person receives a lot of feedback. After that, the branch is deleted, 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, ordinary developers will not know about it. They do not know that you need to go in 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 for 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 they added a counter for the duration of reading and the number of pages. Also in some sections added links that immediately open the desired class in PhpStorm.



Then we began to think how to make the document “old men” look 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 new tickets correspond to what the developer had time to familiarize with. 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, I need only give a small introduction: 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 address. 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 some time and says that he is ready to discuss the decision. A meeting is scheduled with the author of the feature, in which the developer explains his scheme: he would have done so, would have applied 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 noticed. As a result, the developer learns a lot of new things, he begins to take shape the overall picture. He understands how a 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, it is even more likely a plus.



At the conclusion 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 prioritize, 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 it was impossible to do this. But it turned out to be easier than we thought, but it paid off many times over.
  
  
• Test. In terms of the ratio of the benefits to the elapsed time, 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 production. And now we are carrying 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 precisely improved is 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, into 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 lead 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 makes it very easy to see things that can be simplified, and we are working in this direction.