Introducing the first release of the podcast about technologies, processes, infrastructure, and people in IT companies (zero release can be heard and read
here ). Today, CTOcast is visiting Kirill Safonov, Technical Director of RuTarget.
Listen to the podcast1st part of the text version of the podcast')

Text version of the podcast (2nd part)
Alexander Astapenko: Now I propose to move away from the discussion of technology and talk a little about people. On the main page of your site, you can find information that programmers from Google and Yandex advertising systems work in the company. What motivates the best experts in the industry to come to a gaining momentum, but still a startup?
Kirill Safonov: I will object to you. Not really a startup. Still, the company for several years, although from the point of view of the spirit is, of course, a startup. We have a rather small team, vigorous high pace, interesting tasks and people in the team. I think that, basically, the complexity of the tasks and the lack of any bureaucratic brakes or high control and people like.
Alexander Astapenko: Absolutely. But finding such people is not a trivial task. I understand and, after reading the interview with you, I became convinced that while searching you really encountered difficulties and even had to involve an external HR, who would do the screening, the initial filtering of candidates. Where else can you look for such unusual specialists associated with RTB-technologies, except in Google and Yandex?
Kirill Safonov: Perhaps, even Google and Yandex are not 100% suitable companies where you can search for people. In fact, there are quite a lot of other advertising companies in the Russian market that are somehow related to RTB: companies showing banners, advertising places, and so on. And it is reasonable to look for people in these companies. I think there are a lot of people in St. Petersburg and Moscow, and there are good chances for someone to find there.
Alexander Astapenko: I want to clarify on the data science professionals who form an even narrower niche. Are there any ready-made specialists on the market or do you have to train people who come from science, for example, mathematics? Or from high-frequency trading or some other things, where there are a lot of algorithms?
Kirill Safonov: In my opinion, data science is more difficult, because it is a more exotic area. But, nevertheless, about the same answer: companies that are engaged in advertising, data processing, or some kind of social things - you can also find specialists there. Those guys who came to us, they got a long time ago and, perhaps, to some extent by chance, but I am very glad that this happened. Here, for example, with regard to Java-developers: we have vacancies open, and we are constantly looking for them, we hold interviews, but new people come to us very slowly. We are not ready to continue working with the majority. With data science, it turned out that we have guys, have proven themselves well. In this regard, the department is staffed, and it is very pleasant that, despite the more complex niche, it works and does not cause problems.
Pavel Pavlov: You mentioned the interview and the process of selecting people. Are there any features associated with an interview when applying for a job at RuTarget? How do you choose really qualified specialists among the candidates? What qualities do you pay attention to?
Kirill Safonov: First, we arrange a regular Skype interview, in particular, candidates from other cities. We get acquainted with the person, we ask to tell about his experience and ask some questions along the way. We understand what he was doing, what his successes were or, on the contrary, falls, and what a person is like. Then we invite him to a technical interview, during which we ask directly about Java. I'm talking about a job interview for a Java developer. We ask questions on Java and at the same time do not require some kind of super deep knowledge, exotic things. What we need is a very good knowledge of J2SE, threading, concurrency. And, in principle, everything. Then we ask him to write a small program, we look at how high-quality code he writes, how well he is familiar with the design. After that, we communicate by the results of writing this program and make a decision - yes or no.
Pavel Pavlov: And one more small question. For example, in many American companies, the classic standard rule is that at least one interview is deeply connected with computer science, algorithmization, and sorting of related lists. Do you pay attention to this or is it important for you to have a serious knowledge of the practical context - Java, technology?
Kirill Safonov: When writing a test program, the question about algorithms will pop up anyway. It's not going anywhere.
Pavel Pavlov: You mentioned that you conduct an Skype interview with people who are in other cities. Do you invite them to your place in St. Petersburg or work remotely?
Kirill Safonov: We can work with a person remotely, if we know him well, and he knows us well. In the sense that the employee worked on-site with his colleagues, talked, everyone understood that they spoke the same language, everyone understood the same way how the system works. And after that we basically allow a person to leave for some time, go to his hometown or go abroad, for example, and work from there. That is, after a certain stage of initial acquaintance and lapping, which, in our opinion, should last one or two months, a person can go back and work where he wants. The only thing, of course, is that the time zone more or less coincides with the Petersburg one.
Alexander Astapenko: Maybe there is a best practice for working with a remote team? How to keep them all, so that all were, as they say, on one page?
Kirill Safonov: I would say that best practice is to take the right people. Just now it is difficult to find people who not only know programming and Java well, but with whom you are also close in spirit, who are interested with you, with whom you are interested. Just taking into account the fact that we scored a very good team, we have no problem staying on the same page, on the same wavelength. We all think the same, close enough, let's say. Of course, we argue on some architectural issues or on the code, it happens. But the general trend, the vector is very good, it is the same. This gives us the opportunity to let people go, to give them work not in the office, but somewhere else, because we are confident that they will work the same way as we do here.
Alexander Astapenko: And how many people work for you now? What units are in the company? How is it structured?
Kirill Safonov: In the development department, we have several people writing the core, there is a small data mining department, and there are still people for different tasks - there are only about ten people in the development department. This is what concerns RuTarget. Next - the company Segmento, in which there are sales people, sales and there is a product manager, there are actually even two people who are between Segmento and RuTarget, a kind of bridge that conveys business requirements and makes feedback from the development department back.
Alexander Astapenko: Clear. Kirill, what tasks are you doing as a CTO in RuTarget? And how is your time distributed throughout the week across different types of activity?
Kirill Safonov: Since the company is small, there are many tasks, you have to combine many roles. Firstly, it is, of course, direct participation in product development, writing code, discussing architecture, conducting code review and testing. That is, CTO in the company RuTarget is in fact one of the core-developers. Further, some coordination of development activity, coordination between team members, so that everything goes as it should and everyone understands who does what and what, fulfilled the deadlines. Then another important task is to coordinate the integration with technical partners, networks, data providers, that is, all those technical people who communicate directly with the outside company “RuTarget”. There are a lot of organizational and technical issues coming up: keeping deadlines for responses, workloads, high availability and so on. And one more key task - maintaining the system in a “combat” state - now also on me, that is, monitoring and solving some operational problems that arise.
Pavel Pavlov: It turns out that the first line of fire falls on you and is not delegated to other people?
Kirill Safonov: In fact, yes. This is what happens.
Pavel Pavlov: Is this what you wanted or is it worth trying to change something, switch to some other activities? Or do you think that this is the optimal solution, given your expertise, the ability to quickly solve problems?
Kirill Safonov: I think that with the current size of the company is the best option, the optimal distribution. With the growth of the company, of course, some of the functions will need to be delegated to other people. Well, the more interesting is the current work for me, because I have to solve a lot of tasks: both related to programming and not quite, which keep you in good shape, and there is always something to think about.
Alexander Astapenko: Kirill, do you now feel more like a technical specialist, or already more like a manager who runs and solves problems where it burns?
Kirill Safonov: Technical specialist who solves problems. I would say that.
Pavel Pavlov: You already had CTO experience in another company. Similar functions or did something change in RuTarget?
Kirill Safonov: The difference is that there is a higher pace and more real, diverse tasks that have to be solved.
Pavel Pavlov: Was there more development work at JetBrains?
Kirill Safonov: Yes, although I had to solve a lot of questions related to user feedback, with bug reports, to respond to feedback, but the pace there, of course, was lower. Everything happened in some such operational cycle, more or less understandable. Here the pace is higher and the questions are more varied.
Pavel Pavlov: That is, in principle, the classic situation for small companies, let's say, startups in spirit.
Kirill Safonov: In the spirit of startups, yes. It's like racing across the ocean on small yachts instead of sailing it on a big ferry with a pool and a concert hall, somehow. Of course, there is a risk, high speed, the wind is blowing, high waves, but this is much more interesting, and ultimately achieving more.
Pavel Pavlov: Good. Look, you talked about a team of very qualified and responsible specialists, but also mentioned that you have to do a code review. That is, it turns out that you need some kind of control over even the highest specialists? And how tough is this process built?
Kirill Safonov: We do a code review of all the code that goes into production. First, so that team members know someone else's code, it is obvious that this is important. Secondly, despite the fact that all people are talented, responsible, and write good code, it is very important that the code be error free, work quickly and reliably. Therefore, in this case, wasting time on code review is not meaningless. We consider the code-review to be very important, and more than once and not twice it has been proven that this is indeed the case and is really necessary. Because we got out some things that had to be done differently and which saved us a lot of headaches and a lot of time spent.
Pavel Pavlov: It is clear, are there any best practices related to this? What solutions are used?
Kirill Safonov: We do code review when commuting from the main branch to the release branch. We now have a problem with the tool, because I haven’t yet seen any good code review tools. I hope that soon such tools will appear, I will not say where from ...
Pavel Pavlov: JetBrains?
Kirill Safonov: Notice, I did not say that. Here, perhaps, that the best practices are all obvious - code review and tests. It is very important to write these tests, now it seems to me that everyone is writing them. Therefore, there is no need for popularization. Tests - this is the only thing that makes it easy to sleep, in fact.
Pavel Pavlov: Should there be a high level of code coverage?
Kirill Safonov: There is no formal requirement, but the whole team understands that the tests should cover all the basic functionality that is. Therefore, we have problems with this or there are no disputes. It is understood that along with the code there are tests for this code.
Pavel Pavlov: It turns out that test-driven development is methodologically used: first a test is written, then a patch?
Kirill Safonov: Perhaps not, rather, it is all written together. First the code, then the test, first the test, then the code, as you like. We try not to put up any strict requirements and try to minimize the amount of bureaucracy that requires some routine actions. We very much count on the responsibility of all team members. And for good reason.
Pavel Pavlov: I would still like to close the topic of code review. You said that there are no good decisions, but we already know who will have it. Can you name two or three solutions without thinking that you would not strongly recommend to other people?
Kirill Safonov: I would not say that something should not be strictly recommended. It seemed to me that some decisions were too bureaucratic, and the code-review was supplanted by the process of opening and closing of tickets, clicking the mouse and pushing through endless windows.
Pavel Pavlov: Can you give examples of such decisions?
Kirill Safonov: We at JetBrains used Crucible, a commercial product. And I would not want to use it at home.
There are hosting solutions on GitHub, but since our repository lies locally and has a bug tracker of its own, such solutions do not suit us.
Pavel Pavlov: If there is any QA in the team, are people testing who are not directly related to the development?
Kirill Safonov: No, now we do not have a dedicated QA. In fact, we partially test ourselves, partly look at product managers, how the system works. And in the end, I look, the other team members look at the monitoring system, which is set up to immediately report on some strange behavior of the system. There are a sufficient number of business metrics, business checks that analyze the behavior of the system, and if something is wrong, we will quickly find out about it, we can see it all. And, accordingly, we can analyze these metrics, localize the problem and continue to look either at the code or somewhere else, try to understand what is happening. Unfortunately, since we ... Not unfortunately, in fact this feature is so simple ... Since we are dependent, integrated with a large number of advertising networks and data providers, quite often something goes wrong with us, but with them. And it affects our system. But we will quickly find out about it, understand, write a letter or otherwise contact and ask the question: “Guys, how are you doing when you return to the line?” Or “When will you give us qualitative data again?”.
Alexander Astapenko: Kirill, in this vein, I would like to clarify whether the process of supporting your counter-agents, for example, data providers, companies like Segmento, who sell RTB services to end customers, is organized in some way?
Kirill Safonov: Segmento has a department of accounts, a support that communicates with business customers and solves their problems. There is a department between Segmento and the outside world. Between RuTarget and the outside world, I have a customized monitoring and check system that helps me a lot.
Pavel Pavlov: It turns out that if there is a warning system about problems, then there is no need for any system administrators or people who would support, let's say, the system, by and large?
Kirill Safonov: If everything goes well, then yes, there are no problems. But we are constantly evolving, we are improving the system, so the operational activities of both development and administration, of course, are underway. System administrators are needed, and they are.
Pavel Pavlov: Are they doing more fire extinguishing or changing the system? The moment something bad happens, do you fix it or do people help?
Kirill Safonov: Fire extinguishing as such is never required, because the system is set up so that if some unit fails, then it goes into emergency mode, and from the outside it behaves as if everything is fine. We just do not place bets and answer with stubs. No urgent action is required. Then we find out what the problem is. Sometimes this is part of the technical, sometimes part of the administrators.