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.
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:
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:
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.
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:
Once the introductory smoke test is completed and the app is mastered, the newcomer can be considered ready for the next step.
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.
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:
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.
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.
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.
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.
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:
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.
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.
A checklist for a newcomer that you can adapt for your specific needs