Kirill Safonov: “It's like racing in small yachts across the ocean”

    Introducing the first issue of the podcast on technology, processes, infrastructure, and people in IT companies (you can listen to and read the zero issue here ). Today, visiting CTOcast is Kirill Safonov, technical director of RuTarget.

    Listen to the podcast

    1st part of the text version of the podcast

    Text version of the podcast (Part 2)


    Alexander Astapenko: Now I propose to move away from the discussion of technologies 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 professionals in the industry to come to gaining momentum, but still a startup?

    Kirill Safonov: I will object to you. Not really a startup. Nevertheless, the company has already been several years old, although from the point of view of the spirit it is, of course, a startup. We have a fairly small team, peppy high pace, interesting tasks and people in the team. I think that, basically, the complexity of tasks and the absence of any bureaucratic brakes or high control are what people like.

    Alexander Astapenko:Absolutely right. But finding such people is not a trivial task. I understand and, after reading the interview with you, I was convinced that when searching, you really encountered difficulties and even had to attract an external HR who would do the screening, initial filtering of the candidates. Where else can you look for such unusual specialists related to 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 working in the Russian market that are somehow related to RTB: companies showing banners, advertising spots, and so on. And it’s wise to look for people in these companies. We in St. Petersburg and Moscow, I think, have a lot of people, and have good chances to find someone there.

    Alexander Astapenko: I want to clarify by data science specialists who form an even narrower niche. Are there any ready-made specialists in 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, the answer is approximately the same: companies that are engaged in advertising, data processing or some social things - you can also find specialists there. Those guys who came to us, they came for a long time and, perhaps, to some extent by chance, but I am very glad that this happened. For example, with regard to Java developers: we have vacancies open, and we are constantly looking for them, we conduct interviews, but new people come to us very slowly. We are not ready to continue to work with the majority. With data science, it turned out that we have guys, they have proven themselves excellently. In this regard, the department is staffed, and it is very nice that, despite a more complex niche, it works and does not cause problems.

    Pavel Pavlov:You mentioned the interview and the people selection process. Are there any features associated with interviewing for a job at RuTarget? How do you choose truly qualified professionals among candidates? What qualities do you pay attention to?

    Kirill Safonov:First, we arrange a regular interview on Skype, in particular, to candidates from other cities. We get acquainted with a person, ask to tell about his work experience and ask some questions along the way. We understand what he was doing, what his successes or, conversely, his failures were, and what a person is all about. Then we invite him to a technical interview, during which we ask directly about Java. I'm talking about an interview for a Java developer position. We ask questions on Java and at the same time do not require any super deep knowledge, exotic things. What we need is a very good knowledge of J2SE, threading, concurrency. And, in principle, that's all. Then we ask him to write a small program, see how high-quality code he writes, how well he is familiar with the design.

    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, sorting of linked lists. Do you pay attention to this or is it important to you that you have a serious knowledge of the practical context - Java, technology?

    Kirill Safonov: When writing a test program, in any case, a question about algorithms will pop up. There is nowhere to go.

    Pavel Pavlov: You mentioned that you conduct interviews on Skype with people who are in other cities. Invite them to your home 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 speak the same language, everyone equally understands how the system works. And after that we basically allow a person to leave for a while, go to his hometown or go abroad, for example, and work from there. That is, after a certain stage of initial acquaintance and grinding, 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 coincide with the St. Petersburg one.

    Alexander Astapenko: Maybe there is a best practice for working with a remote team? How to keep them all so that everyone is, as they say, on one page?

    Kirill Safonov: I would say that best practice is to take the right people. It’s just hard to find people who not only know programming and Java well, but also with whom you are also close in spirit, who are interested in you, who are interesting to you. Just given the fact that we have a very good team, we have no problem staying on the same page, on the same wavelength. We all think alike, close enough, let’s say so. Of course, we argue on some architectural issues or on the code, it happens. But the general trend, the vector is very good, it coincides. This gives us the opportunity to let people go, to let them work not in the office, but somewhere else, because we are sure that they will work the same way we do here.

    Alexander Astapenko: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 kernel, there is a small data mining department, and there are still people for different tasks - now there are only about ten people in the development department. This is for RuTarget. Next up is Segmento, which has salespeople, sales and product manager, there are actually even two people between Segmento and RuTarget, a bridge that conveys business requirements and takes back feedback from the development department.

    Alexander Astapenko: I see. Cyril, what tasks do you do as CTO in RuTarget? And how is your time distributed throughout the week for different types of activity?

    Kirill Safonov:Since the company is small, there are many tasks, we have to combine many roles. Firstly, this, of course, is directly involved in product development, code writing, architecture discussion, code review and testing. That is, CTO at RuTarget is in fact one of the core developers. Then there is a certain coordination of development activity, coordination between team members, so that everything goes as it should and everyone understands who is doing what, fulfill deadlines. Further, another important task is coordination of integration with technical partners, networks, data providers, that is, all those technical people who communicate directly with RuTarget from the outside. A lot of organizational and technical issues come up there: meeting deadlines, workloads, high availability, and so on.

    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 happening.

    Pavel Pavlov: Is that what you wanted or does it make sense to try to change something, switch to some other activities? Or do you think that this is the best solution, given your expertise, the ability to quickly solve problems?

    Kirill Safonov:I think that with the current size of the company - this is the best option, the optimal distribution. With the growth of the company, of course, part of the functions will need to be delegated to other people. Well, the more interesting the current work is for me, because I have to solve a lot of problems: both those related to programming, and not really, which keep you in good shape, and there is always something to think about.

    Alexander Astapenko: Cyril, do you now feel more like a technical specialist or more like a manager who runs and solves problems where he burns?

    Kirill Safonov: Technical specialist who solves problems. I would say so.

    Pavel Pavlov: You already had experience working with CTO 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 addressed.

    Pavel Pavlov: Was there more development work at JetBrains?

    Kirill Safonov: Yes, although I had to solve a lot of issues related to user reviews, bug reports, respond to feedback, but the pace there, of course, was lower. Everything happened in a certain such operational cycle, more or less understandable. Here the pace is higher and the questions are more diverse.

    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 crossing it on a big ferry with a pool and a concert hall, something like that. Of course, there is a risk, high speed, wind blowing, high waves, but it is much more interesting, and ultimately there are more achievements.

    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 even over the very highest specialists? And how rigidly is this process built for you?

    Kirill Safonov:We do a code review of all the code that gets 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 a code review is not meaningless. We consider the code review to be very important, and it has been proved more than once or twice that this is really the case and really necessary. Because some things came out that were worth doing differently and which saved us a lot of headache and a lot of time spent.

    Pavel Pavlov: Is it clear that there are best practices related to this? What solutions are used?

    Kirill Safonov:We do a code review when moving commits from the main branch to the release branch. We now have a problem with the tool, because I have not seen good tools for code review yet. I hope that such tools will appear soon, I won’t say where ...

    Pavel Pavlov: JetBrains?

    Kirill Safonov: Notice, I didn’t say that. Here, perhaps, that best practices are all obvious - code reviews and tests. It is very important to write these tests, now, it seems to me, everyone writes them. Therefore, popularization is not required here. Tests - this is the only thing that allows you to sleep peacefully, 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 any disputes. It is understood that along with the code are tests for this code.

    Pavel Pavlov: It turns out that test driven development is used methodologically: first a test is written, then a patch?

    Kirill Safonov: Perhaps not, rather it is all written together. First, code, then test, first test, then code, whatever. We try not to set any strict requirements and try to minimize the amount of bureaucracy that requires some kind of routine action. We look forward to the responsibility of all team members. And not in vain.

    Pavel Pavlov:I would still like to close the topic of code review. You said that there are no good solutions, but we already know who will have it. Can you name two or three decisions that you would not recommend to other people?

    Kirill Safonov: I would not say that you need to strictly recommend something. It seemed to me that some decisions are too bureaucratic, and the code review is supplanted by the process of opening and closing tickets, clicking with 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 for myself.
    There are hosting solutions on GitHub, but since we have a repository locally and a bug tracker of our own, such solutions do not suit us.

    Pavel Pavlov: If there is some QA in the team, testing people who are not directly related to the development?

    Kirill Safonov:No, now we do not have dedicated QA. In fact, we partially test ourselves, partly product managers watch how the system works. And in the end, I look, other members of the team look at the monitoring system, which is configured so as 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 know about it very quickly, 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 ad networks and data providers, quite often something goes wrong with us, but with them. And it affects our system. But we quickly find out about this, understand, write a letter or otherwise contact and ask the question: “Guys, how are you doing when you return to duty?” or "When will you give us quality data again?"

    Alexander Astapenko: Cyril, in this vein, I would like to clarify whether the process of supporting your counter-agents, for example, data providers, companies like Segmento, which sell RTB services to end customers, is somehow organized.

    Kirill Safonov: Segmento has an account and support department that communicates with business clients and solves their issues. There is a division between Segmento and the outside world. Between RuTarget and the world around me, I have a customized monitoring and receipt system that helps me a lot.

    Pavel Pavlov: It turns out that if there is a system for reporting 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 is going well, then yes, no problem. But we are constantly developing, improving the system, so the operational activities both in development and administration, of course, are ongoing. System administrators are needed, and they are.

    Pavel Pavlov: Are they more concerned with fire fighting or changing the system? At the moment when something bad happens, are you correcting it or are people helping?

    Kirill Safonov: Fire extinguishing as such is never required, because the system is configured so that if a unit fails, it goes into emergency mode, and from the outside it behaves as if everything is fine. We just do not place bets and respond with caps. No urgent action is required. Next we find out what the problem is. Sometimes it’s part technical, sometimes part administrators.

    Also popular now: