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, it is necessary first of all to clearly define the priorities of activities.
In my opinion, the main activities of a lead can be arranged in the following order:
- Building the hiring process;
- Selecting a technology stack;
- Setting up team interaction;
- Building a development and testing process.
In this part of the article, I will focus only on the first point.
Disclaimer:
This article contains my thoughts and conclusions based on my experience of working 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 an interview, but also soft skills
Often a developer interview in Russia boils down to language / framework questions. In fact, soft skills play an equally important role and 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 approximately 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.
A 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 the critical hard-skills and skills for the project, 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 questions related to parts of the Android SDK that are not used in our project - ContentProvider, JobScheduler, etc. Answers to these questions will not give us an understanding of whether it will be included in the development of regular project features in which these parts 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 for passing all stages of the interview for the candidate, and many 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”. So that a person not only knows how to give definitions and academic knowledge, but demonstrates an understanding of the structure of a particular 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 discusses on a particular topic. 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 squad
When hiring, you should always remember about the balance of people in terms of 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 run than the benefit of writing code at the moment.
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 do, but how important it is.” 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 let the team understand whythe employee was fired. Otherwise, you can instill fear in the team and ruin the team atmosphere.
Council number 8. Collect feedback from newly arrived employees
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 and give fresh ideas with a clean look. 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.