Over the past 4 years, we’ve developed an adaptation process enjoyed even by ultra-experienced newcomers. Today, we’ll share its main stages and a basic checklist. You can easily adjust them to fit engineers of any level that you hire.

Month 1: showing how we work

Everyone wants to start contributing as quickly as possible, but starting on a new job is always stressful, even for someone experienced. The newcomer knows neither the people nor the way things work. Still, their opinion of you starts forming on the very first day. That’s why we came up with a checklist for newcomers:

• Seeing any kind of a plan is comforting and shows that we truly care about the newcomer’s well-being. Indeed, this is very important for successful adaptation. All the key information is presented in a concise manner, and the mentor and the team leader will be there if something’s unclear.
• The plan immediately addresses the issue of expectations: even the most mature senior expert wants to know what results of their probationary period will be deemed acceptable.
• By the way the newcomer interacts with the checklist you can see how they will do later: ask questions, tackle situations not provided for by the plan, etc.
• A checklist is easy to maintain, unlike a ton of haphazard Confluence documents :)

Week 1: addressing all paperwork issues

Every newcomer has a background and their own habits. The first thing they should learn is “how things work at the new place.” This applies to all processes on the company, department and team level. The newcomer should get knee-deep in such nuances from the very first day. The sooner they get comfortable, the more productive they’ll be later.

An understanding of how things work in the company and in the QA department in particular is the biggest thing we expect. At the introductory meeting, we establish the following things for the newcomer to do, following the checklist and, if necessary, seeking advice from the mentor:

• Solving organizational and legal issues, including registration, receipt of equipment, etc. On top of the checklist, the newcomer is given a handbook covering all the most important company-level things.
• Getting access to all the necessary projects, services, tools, and test benches.
• Starting the review of documentation, getting acquainted with the workflow, dashboards, regulations, builds, etc.

Of course, there’s no strict need to complete the entire process in just a week. Everyone works at their own pace. This is normal, and we respect this.

Week 2: getting started with the product

Once the newcomer gets a good idea of how the processes and their work look in theory and stops getting lost on their way to the coffee maker (and back), immersion into practice begins.

Running a smoke test. Our applications are covered in test cases, over 200 of them in total. Tackling them all is a long and quite difficult process. Therefore, we selected about 60 cases for the key components of our entertainment UGC apps, such as push notifications, content feeds, etc.

After going through them, the newcomer will get an understanding of how things work in the app, while also mastering our processes in practice. Each case is atomic and should take up to 10 minutes, but the mentor is always there if something isn’t going quite as planned.

All documentation becomes outdated at some point, and we also do a lot of A/B tests and experiments, so some of the cases may be irrelevant already. Then, it becomes part of the newcomer’s training to go find out how to fix things.

Meanwhile, a series of mini-lectures by the mentor begins. These are four short meetings, each taking about 15 minutes. They help the newcomer to get a better grasp of the basic internal terms, processes and tools. Instead of making educational clips, we conduct such lectures in person, because:

• Things tend to change, and a video can quickly become obsolete.
• The newcomer will be able to immediately ask questions and sort things out with the mentor in real time.
• The newcomer gets more than a mere introduction to another instruction: live communication is crucial in modern teams.

Once the introductory smoke test is completed and the app is mastered, the newcomer can be considered ready for the next step.

Weeks 3 and 4: getting hooked up with real regression tests and teamwork

Over the first weeks, the newcomer studies the basic components and processes usually shared by all products, before moving on to a specific product team. They plunge into the specifics, begin to visit daily meetings, and get assigned the first bugs and minor tasks.

At this point, the newcomer starts compiling checklists to check their own tasks. The mentor and their future colleagues check them out, suggesting what to add and closing possible knowledge gaps. The guys are willing to help each other. They understand full well that the sooner their new colleague gets up to speed, the easier things will be for everyone. However, if an all-hands-on-deck situation happens (and these tend to happen), the team leader will ask an experienced QA expert to help review the beginner’s work.

Checkpoints

Although it is believed that senior pros don’t like having many meetings, we communicate a lot with the newcomer in the beginning. Scheduled meetings are held:

• on Day 1,
• on Day 2,
• at the end of Week 1,
• at the end of Week 2,
• at the end of Month 1 and Month 2.

At each one, we ask if reality has matched their expectations. Here’s a list of topics we cover each time:

Plus, we always cover topics that the newcomer wants to discuss. They can also initiate meetings outside of the planned schedule, if needed.

Month 2: seeing if the newcomer can work with us

Over the first month, our new Senior QA gets gently immersed in the processes, the product and the team. We don’t demand any productivity yet; it’s crucial to allow some time for getting used to things.

However, there comes a time when we have to see what they’re like on the job. First of all, a senior pro must be independent. This is where we start actively involving them in mid-sized and major tasks. For example, they get acquainted with our support and start helping with sorting out complaints from users at this stage. They get assigned a complaint, and we can judge their responsibility level and ability to work independently by the way they deal with it.

Weeks 5 and 6: release duty

When you need to make sure that the newcomer knows how to work at the right pace and follow the rules, you get them involved in the release. It takes place once every couple of weeks on average.

Each team has a release manager who appoints the engineers on duty and controls them. The engineer on duty is given instructions with exhaustive information on what to do. Then, they go on to collect data on the release check progress, report on it every evening in the right chat, etc.

The mentor, the leader and the team assess how their new colleague behaves in this role, checking whether they are able to meet the deadlines, whether they ask questions if something’s wrong or unclear, and so on.

Week 7: collecting feedback

After the first few big tasks, we ask the newcomer to interview colleagues and collect their feedback on themself. There’s no template for that; everyone does it as they see fit. Some compose unique messages, others come up with a survey template and mail it out to colleagues. The craftiest ones ask the mentor for a couple of feedback request examples and use them.

Feedback from colleagues should primarily be used as food for thought by the newcomer themself. Meanwhile, the mentor also makes rounds, collecting opinions on the new coworker. This information is analyzed by him together with the team leader and then also communicated to the newcomer.

We also ask for feedback on us; the way the engineer gives it says a lot, too.

Week 8: moment of truth

Two months should be enough for us and the new employee to get a good idea of each other. If for some reason the parties don’t want a clean break at this point (this sometimes happens!), we set up a new meeting and discuss two key points.

One: growth points. Usually, a Senior QA has no issues developing some missing hard skills, and there’s no obvious lack of soft ones. However, newcomers often can get stuck on the minor things, and working slowly is a bad thing for a QA engineer. Here’s where we agree to focus on priorities. We also issue additional tasks to help support this agreement with practice, if necessary.

Two: is the new QA happy? We try to hire everyone who’s cool, and then find an optimal role for them. Sometimes, the newcomer tends to dislike specific tasks (for example, routine ones), while liking the people, the product and the company. Then, we have to try to understand what will make them happier, and agree on how this can be done. It can be potential development in the management or automation directions. Then, the newcomer can be transferred to a team that’ll help them achieve their goals quicker. Or, we can find a new challenge within the current team, like, again, automation, if it doesn’t exist yet.

If at this stage we understand that the newcomer:

• is versed well enough in the specifics of the team’s work and the product;
• can work independently and is comfortable around the processes and regulations;
• has mastered the toolkit (if they didn’t know something before);
• and is a fit for our culture…

Then everything’s OK! Our new Senior is done with onboarding (which is not always equal to the formal probationary period). If there are more questions about work, but the parties still think they’re a match, then we keep getting a better idea of each other.

Month 3 (optional)

The third month is structured in a similar way as the second, but this time, we focus on ironing out the negative points that colleagues highlighted in their feedback. This may be the aforementioned focusing issues, low (but not critically low) work rate by our standards, or the fact that the new employee keeps asking the same questions.

We draw up an action plan, assign individual tasks and watch them tackling the challenge. Then, they once again collect feedback, and we discuss their progress.

Bonus

A checklist for a newcomer that you can adapt for your specific needs

Week 1

• paperwork
• equipment
• access
• office introduction
• the first meeting with the leader and mentor: getting acquainted, discussing organizational issues
• studying regulations and workflow
• installing software needed for work
• start of the mini-lecture course on the product

Week 2

• smoke test to get acquainted with the app
• team introduction
• gradual involvement in production tasks
• meeting with the mentor and leader based on the results of two weeks

Weeks 3 and 4

• mid-level production tasks in the team
• introduction to release duty
• involvement in support tasks
• meeting with the mentor and leader based on the results of Month 1

Month 2

• major production tasks in the team
• collecting feedback from colleagues
• meeting with the mentor and leader based on the results of two months, discussing the feedback

Month 3

• major production tasks in the team, more personalized ones
• collecting feedback from colleagues again
• meeting with the mentor and leader based on the results of three months, discussing the feedback