Hello, Habr!
My name is Vladimir. I am in charge of mobile development at Vivid Money.

Vivid Money is a fintech startup for the European market with a wide range of functionality – payments and transfers, multicurrency, financial analytics, account sharing, investments and much more. The closest competitors are Revolut and N26.

We managed to make and successfully launch a mobile fintech application in a year. During this year, I collected ideas that were forming in my head for about 4 years, while I was a lead on other projects. In this article, these ideas are collected in the form of tips for software engineering managers / leads who start long-term and large-scale projects from scratch.

Introduction

A little over a year ago, I came to the project as the lead of an Android team. I was faced with an ambitious and interesting task – to choose technologies, assemble a team, set up processes and, most importantly, do it all well. Good is a loose concept, but for me it is a quality product from a product and technical point of view.

Starting a project from scratch is a task as interesting and exciting as it is incomprehensible and difficult. At first you don’t know what to grab onto, then there are so many things to do that the whole process of work is like putting out fires.

To prevent this from happening, you must first of all clearly prioritize activities.
In my opinion, the main activities of a lead can be arranged in the following order:

1. Building the hiring process;
2. Selecting a technology stack;
3. Setting up team interaction;
4. Building a development and testing process.

In this part of the article, I will focus only on the first point.

Disclaimer:
The article contains my reflections and conclusions based on my experience in large and long-term projects. Some of the tips may seem hackneyed, but as practice has shown, not all of them are applied even in large companies and projects.

Hiring building

For me, this point is in the first place, since the further work of the team depends on the “quality” of people.
We had a very ambitious timeframe for launching the bank – 1 year. During this time, it was necessary to qualitatively make a huge amount of functionality. There was simply no time for dependent, poorly trained employees. Hence the following advice follows:

Council number 1. Remember the importance of hiring.

In addition to the fact that a weak developer directly affects the quality of the code and the number of bugs in the product, it is impossible to delegate to him, since there will not be full trust and constant monitoring will be required. Therefore, difficulties will arise in a rapidly growing project.

Council number 2. Check not only hard skills at the interview, but also soft ones.

Often a developer interview in Russia boils down to language / framework questions. In fact, soft skills play an equally important role, and they are more difficult to develop. Plus, a person with a similar mindset is more likely to fit into the team.
For ourselves, we have identified the following soft skills:

• Systematic thinking;
• Neatness and healthy perfectionism;
• Relying on experience, not advice; questioning unverified facts.

And, of course, basic non-conflict and the ability to communicate with people.

For example, we ask a candidate a question: “Why are you leaving your old job and what are your criteria for choosing a new job?”. The answer itself is not so important as the systematic approach is important – we expect the candidate to be aware that he is not satisfied, that he was able to come to this in a logical way and sort everything out in his head.
Examples of such questions that help us understand the mindset and principles of a candidate might be, “What does your ideal team look like?” or “What does the ideal development process look like?”

Council number 3. Optimize your interview.

The interview should be seen as a mechanism that can be improved and optimized. Or as a program that can be refactored.
I will give examples of the optimizations that we did.

Example 1

It takes about 1.5 hours of two developers to interview each candidate. To optimize this time and not waste it on obviously weak candidates, we introduced screening. Screening is a few simple, closed questions that have prepared answers. Recruiters themselves ask these questions to the candidate, which takes about 10-15 minutes.
Few numbers:
Out of 100 candidates, after screening, about a third, that is about 30, is eliminated. A recruiter spends about 15 minutes on each screening, that is, approximately 8 hours of net time for 30 eliminated candidates. In a classic interview for the same 30 candidates, we would have spent about 60 man-hours in the most optimistic scenario.

Example 2

The purpose of the interview is to select the most relevant candidate. We analyzed and identified critical for the project hard-skills and skills, taking into account the stack of selected technologies, which allowed us to remove some of the irrelevant questions and reduced the interview time.
For example, we have removed the questions related to parts of the Android SDK that are not used in our project – ContentProvider, JobScheduler, etc. SDKs are rarely used.

Example 3

Initially, the technical interview took place in two separate stages – theoretical questions and practical tasks. This greatly increased the time it takes for a candidate to complete all stages of the interview, and a lot of applicants were lost, since the IT market is very competitive – good developers get offers quickly.
In order to optimize the funnel, we collapsed the interview into stage 1 – removed uninformative questions and solving algorithmic problems. I wrote about non-informative questions in the previous paragraph. But we replaced the algorithmic tasks with practical tasks for the framework. They also test your coding skills and SDK knowledge.
As a result, there was only one technical interview for 1.5 hours, but it became as polished as possible in content.

Council number 4. “Understanding is more important than knowledge.”

The most important criterion for choosing a developer was “understanding”. For a person not only to be able to give definitions and academic knowledge, but to demonstrate understanding devices of this or that framework. A developer without this understanding, faced with problems, will not be able to find a solution on his own or will not solve the problem optimally enough. Therefore, we made all the interview questions open so that the candidate does not give out the learned terms, but reason on one topic or another. And we follow his knowledge of the topic and the course of his logic.
For example, we ask an open-ended question: “How to make an ANR (Application Not Responding) detector in Android?”. This question tests knowledge of how threads work in Android, but avoids the direct question about Looper and Handler. It also allows you to concisely switch to a topic with multithreading.

Council number 5. Distribute the function of interviews.

With the rapid growth of the team, interviews become so numerous that it takes the whole day, and there is no time left for other activities. Therefore, it is useful to partially delegate the interview function to the team.
This not only relieves the burden on the lead, but also includes the developer in the choice of his potential colleague, which additionally motivates him.
Plus, the candidate gets to know the team and creates a more holistic impression for himself.

Council number 6. Balance the composition of the team.

When hiring, you should always remember about the balance of people by competencies in the team. Too many senior developers can lead them to come up with new solutions, but developers will not make features. But at the start of the project, when the technical base is laid for years to come, it is necessary. Moreover, for writing the usual code of features, the signor will be unreasonably expensive. Too many juniors, in turn, will degrade the codebase and, as a result, sink the project in the long run. However, smart juniors quickly grow into middles and become much more loyal to the company and the team than middles from the market. In my opinion, this balance is different for each project and specific situation, so I will not give specific percentages.

Often times, teams are diluted with contractors to speed up development. Balance is also very important here, since a large number of contractors can also degrade the code in the project. Contractors rarely have the same motivation and interest in a project as in-house employees.

Council number 7. Don’t be afraid to fire.

Finally, there is no need to be afraid to fire people from the team. A person who does not fit the team in terms of principles and spirit or technical skills will do much more harm in the long term than the benefit of short-term coding.

It sounds easy to fire, but how to do it as painlessly as possible for the employee and the team? The principle works here: “It doesn’t matter, what you will, but it is important as”. If you do everything in advance – discuss expectations from the role, give feedback about the work on time, without waiting for the end of the probationary period, and give reasons for your comments – this will not come as a surprise to the employee.
It is also important to publicly make the team understand why the employee was fired. Otherwise, you can instill fear in the team and spoil the team atmosphere.

Council number 8. Collect feedback from newcomers.

The recruitment process consists of 2 stages – interview and newbie onboarding.
Onboarding should be useful not only for the beginner, but also for the project.
After immersion in the project, new people can see problem areas with an open look and give fresh ideas. Therefore, we have developed a rule – to consciously listen and analyze their opinions and recommendations for improving approaches and code base. Some of these recommendations have been successfully implemented in the project.
For example, after the arrival of one of the members of the Android team, we completely revised the approach to storing data in the in-memory cache.

Outcome

In conclusion, I would like to say that our mobile team has grown to 26 people in almost a year and a half. All the developers do a good job, and no one left the team of their own accord. We have successfully released the product and passed the test of remote work without loss in quality and development speed.

I hope the tips collected in this article will be useful to you too.

In the next parts, I will talk about our approaches to choosing a technology stack and setting up team interaction.