How to hire people in a huge company with an unpopular stack. Conversation with Wrike

To see a new and so far little-known programming language in a small startup or pet project with friends is commonplace. You’ll ask why they took it, they will say that you just learned it out of curiosity, liked it and decided to experiment, because you are tired of the eternal Java / .Net / JS at work.

But if a company speaks about itself in phrases like “international business”, “offices around the world”, “cult of productivity”, “the result is important to us, not the process”, “we need burning eyes and the desire to develop” - usually they don’t waiting for surprises. Some even put stoplists on new technologies until they gain weight in the industry. To questions about the minuses of tools evasively say: "the main thing is people, not languages."

Wrike, with around 400 developers, has a different approach. They did not turn a blind eye to the shortcomings of JavaScript and did not even choose a compromise, such as Flow or TypeScript - but went in a completely radical way. They rewrote the front into a language that a thousand people hardly knew then, and, it seems, are still absolutely confident in themselves.

Wrike took an honorable third place among medium- sized companies in the ranking of the best employers in My Circle IT with an average rating of 4.82. The top most highly rated qualities of the company include: social package, comfortable working conditions, relationships with colleagues, adequate salary and professional growth.

---

- Wrike was founded by Andrey Filev in 2007 in St. Petersburg. Then he began to develop business in America, in Silicon Valley. Then it was a completely different company, and now we have grown a lot.

In the beginning, Andrey had an outsourcing company. They began to look for software in it that would allow it to work more efficiently - to manage time and resources. There was no really cool tool at that time, and the idea came up to create your own. Then Wrike was born.

We started with simple things, but gradually the product began to grow. This was 12 years ago, and we can say that we took part in the formation of a market for such work management systems. Wrike is now used by over 18,000 companies worldwide.

- Does that outsourcing company still exist?

Yes, it’s called Murano Software. But she has nothing to do with us. Wrike is a full-fledged single-product company, which was an experiment in the framework of an outsourcing company, but soared and separated very quickly.

“Are they still using it there?”

Yes, still.

What is Wrike

Wrike is a platform for project management and collaboration in a very broad sense: from a personal to-do list up to a system that is suitable for large companies.

Inside, you can create projects with many tasks and subtasks, set up reports for data collection, display Gantt charts, track tasks in the calendar, and edit them simultaneously with other participants. Wrike add-ons help you manage your workload in real time or run complex multi-channel marketing campaigns. There is an API for integration into other tools. There are extensions, for example, for Adobe Creative Cloud. It allows you to view and comment on files without leaving the system.

Wrike does not seek to focus on a particular function, industry, or profession. It is positioned as a universal tool for everything - up to replacing the mail system, messenger, knowledge base, bug tracker and much more.

- Defocusing on everyone and for everything does not make individual parts worse?

- We deliberately do not go into narrow-profile niches. For example, we don’t want to do exclusively bug tracking systems for developers like Jira. We do not want to make software only for programmers or only for designers. We are interested in making a universal product. At the same time, we understand that there are highly specialized cases that we do not cover.

But this is not our goal - to please everyone, or to fully occupy the IT niche. Although we, developing Wrike, use it as a system for tasks and a bug tracker.

- That is, you can take the bug tracker faster, the messenger is faster, but it will be five different tools and it will be difficult to synchronize between them.



- But then you have to compete with everyone. Atlassian on the one hand. Slack as a messenger - on the other.

- Yes, now only the lazy ones are not developing project and product management systems.

- But in fact, there are not so many companies that would compete with us on all counts.

- Isn't Atlassian like that?

- He is more focused on the IT market. For example, for designers Jira is too complicated.
It is very difficult to customize. There is even a profession - Jira Setup Manager. We try to make sure that you go to the site, take a free account and that’s all - from the first day you can use it without problems.

- But you say that you also work closely with clients and also direct managers who establish processes.

Yes, we have a team of Customer Success and Deployment managers, as well as a whole system of tours, guides, e-books and all kinds of documentation. There are managers who will help you configure Wrike for ready-made processes. Sometimes they work with large one-to-one clients. Sometimes immediately with many (for example, recording webinars). Even if a person registered a trial and did not understand the product, he will have the opportunity to chat live with one of the rikers and understand how that works.

- In general, introducing a product into a company with thousands of users is another task.

- It happened that it was very difficult with one of the big clients?

Usually the larger the company, the more work processes it has - the harder it is to work. We are, of course, not outsourcing. There is no such thing that some kind of moneybags comes and says: “here is a lot of money for you, do me such a thing. Our product managers determine the product development paths themselves. But there are customers with interesting requests.

Airbnb, for example, uses the platform in very unusual cases. Each apartment and each person who rents it is a separate project in Wrike.

Or the car company Coil [name changed]. Customers order spare parts from them. Giving these people Wrike accounts is just an idea. You will not be each owner of Coil do your account. But the company really wanted a convenient opportunity to work with customers.

Of course, we did not say that right now we will make such a feature for them. But managers realized that she would improve the product as a whole. This is how “external request forms” appeared for people who do not have a Wrike account.

- It turned out, did you do for Coil [name changed], but did it suit everyone else?

“Not really.” We simultaneously analyzed the market and hypothesized - this task lay in a potential roadmap. If there was a request that does not suit us at all, we would not do it.

---

The internal structure of Wrike

We work on Scrum. The company is divided into teams by features - about 10 people each. They are of different composition, but each has a backend, frontend, scrum-master, QA, QA automation, UX-designer, product obouner, product analyst (analysts sometimes come in several teams). Such a composition is fully functional and can make a feature from and to.

There are internal teams that make frameworks, components, design kits, and are engaged in the transition from one version of a programming language to another.

Some teams are common to the entire company. For example, these are SysOps, which are engaged in server infrastructure, and DevOps - they are engaged in deployment and product delivery. We have releases from one to 3 times a day.

We also partially use the well-known Spotify structure with guilds. For example, the frontend, where the front-end consists of all teams. There are front-end leads that deal with management and architecture. And there are guild leads.

We have not yet reached the point of isolating them from the teams. But in general it is logical and organic. Now people with high technical architectural skills are in infrastructure teams.

Wrike is not really about a bureaucratic structure. But this does not mean that chaos is happening in our country. If a person does what he likes and does it well, then he will have opportunities for growth, regardless of what position he occupies.

- And in what office what is being done?

- In St. Petersburg and Voronezh engineering r'n'd offices. We have 400 people in St. Petersburg and 40 in Voronezh. There are offices in San Jose, San Diego. An office in Prague will open this year. Recently expanded office in Dublin. In January of this year, an office was opened in Melbourne, Australia.



- In American offices we have a sales department, marketing, managers (CSM). Dublin also has CSM and sales. There is also a team of analysts. In St. Petersburg - the largest and unifying office. Here we have customer service managers, product managers, analysts, designers, development and back office.

- Does everyone work in offices or are you open to a remote location?

- Remote scrum commands are very difficult. We want people to be close and in contact with each other. In departments that may involve remote work (for example, Customer Support), we do not limit the guys much.

- Udalenka in development - a moot point. Now there is a lot of talk about it, in English-language Twitter we constantly discuss this topic. There are pros and cons. In our opinion, there are more “cons”. As a team manager, it would be difficult for me to ensure productivity and a common spirit, to grow and coach remote employees.

We have a fairly flexible schedule, people do not sit in the office strictly from ten to six. If there is a stand-up, please be kind - come, and when it passes and how long it will take, the teams choose for themselves. If something happens, also without problems - the person writes that he works from home.

- When the product is international, developers are often required to have a good knowledge of English in order to speak with customers.

- We have no customers, we are not outsourcers. The company is international, and part of the communications is, indeed, conducted in English, but this does not apply to everyone. For developers in Russia, we do not have a special requirement to know English.

Once a month there are meetings at which we talk about all the changes in the company and financial performance. Communication with support takes place in English. Tickets with customer bugs are also, of course, in English. For those who want to tighten or learn a language, there is such an opportunity - we have ongoing classes with teachers, for employees they are free.

But my opinion is that if a developer did not start developing yesterday, he knows English at least at the level of reading documentation. Without a tongue, you can't even google anything.

Of course, the developers may not have a true British accent and there is no Oxford behind them, but they usually can speak and read something.

---

Why Dart is Better than JavaScript and TypeScript

- Now all this is a big complex system. But it grew out of internal development a very long time ago and has changed a lot since then. Because of this, there were no architectural miscalculations that now interfere with living?

- Of course, the project is big. We have on the backend either one and a half, or two million lines of Java code. The front end is also comparable. But I do not know a single person who can design the system for five years in advance, and it will develop without rebuilding.

It happens that something falls. Sometimes we realize that two years ago were dumber. But this is natural from the point of view of the engineer. How else?

- Therefore, there are internal teams that periodically rewrite old parts.

- Yes, I sometimes say that we need to sit down and refactor, otherwise it will shoot so that everything will be shot. We sit down and refactor. Architecture interferes - we make architecture.

- What is your stack?

- On the Java backend. SQL database. At the front end, an interesting thing. Once upon a time we had JavaScript, but we realized that it did not scale at all and chose Dart.

- What have you chosen ??

- Dart. Yes, this is a normal reaction. A typed language from Google, which is now almost seven years old. We are probably the most important evangelists of this stack in Russia.

- The most important or the only ones?

- By the way, now it is actively developing. Google launched Flutter - this is such a mobile framework written just on Dart. There is a Russian Dart Communitythat we have created and support. There are already about one and a half thousand people. Of course, by the standards of JavaScript, this is not very impressive, but also a lot.

Last December, we organized the DartUp conference - there was a huge hall and a lot of people came. And many actually use Dart in production. The language is gradually developing, and it is very cool.

“So we're on horseback now.” Saying "in the world" is probably pretentious, but, in fact, it is. DartUp is the largest Dart conference in the world. Even more than Google.

- There were about three hundred people at the conference. Although two years ago it seemed that we were alone in the field of warriors.



- This is all interesting, but how to work on such a large-scale project, if you don’t hire people, there are no libraries or frameworks.

- It's a delusion. Recently, we took on the team a man for whom Dart was generally the first programming language.

- In Dart, everything is there. This is a language from the category of C # and Java - everything you need is built in there. And it’s generally not true that everything is empty there and the tumble rolls around. There is even more built in than in some twenty-year-old languages. Libraries, tools, framework support - Angular is there too.

Of course, there is no infrastructure like on JS. But the problem is that when people write millions of libraries, they get millions of bad libraries. And maybe only a hundred normal.

And if the libraries are written by Google, which uses Dart in AdWords and AdSense, then the average quality is much higher.

The beauty of the language is that it is simple and C-like. That is, we hire developers in C ++, C #, Java, JavaScript - anyone. We do not require knowledge of Dart. Naturally, there is no dart developer on the street.

In my team there is a developer with the experience of C Sharp, who knows. At the front, he never even wrote. And in five days he washed down a feature. Because the language is as if you've been writing on it all your life.

In a good way, development engineers write business logic, no matter what language.

“But people don’t start writing in their old language?” The same JS nicknames came from a dynamic language to a static one.

- Therefore, our selection process is not the easiest. But fair and honest.

- Ok, why is the language good?

I would say it is one of the most strongly typed that compiles in JS. When we were sitting on the front end four years ago and there were about 8 of us - you can at least cover yourself with all sorts of linters, rules, everything in the world - but he will still miss something. We needed a static typing, as strict as possible.

On Dart, if you write something wrong, you will immediately understand it. It has earlier error detection, which allows even without testing the code to understand whether it works or not.

There is no chaos in the built-in library when one is updated and the other falls off. Because the SDK is supplied with the language, which ensures that everything works after the upgrade. You do not need to connect a million libraries to get streams and streams - everything is already there.

Now in the world there are two languages ​​that allow you to write for all platforms — for mobile, for backend, for desktop, for web. This is JS and Dart. JS cons know how many. And Dart has a huge plus - typing.

Therefore, there is only one hard-typed language that allows you to write for all platforms with normal tuning. Many cite Kotlin as an example, but for the web it’s not very.



- Now you do not regret that, for example, TypeScript was not chosen?

- Not now, but in principle we do not regret. I advise you to see the report of Victor Logov from JetBrains at the HolyJS conference [ The speaker probably mixed up the name, and it was a report of Anton Lobov ].

They make TypeScript support in their products, and it just puts TS on the shelves there, reasonably. And after that there is no desire at all to take it. One gets the feeling that features appear in it on the principle of “Let's add this? Come on. ”

- So that I believe, tell me what is bad in Dart? It may not be that everything is perfect.

Easily. There are problems, but not with the language, but with Google. They use a lot of tools inside, which do not rummage out. We now have a direct channel with Google, we are part of a number of internal organizations, and they are slowly giving away these tools.

But this is relevant only for us, for a very large code base. Small projects have no problems at all.

- After the experience with Dart, you did not want to replace Java with Go?

- What for? We selected Dart according to certain parameters. It was a balanced decision.

- One of our speakers says that there are companies that rewrite everything with new technologies, and there are companies that make money. Rewriting should not be an end in itself. There are business tasks, and there are tools that should implement them.

- We are experimenting with different technologies. If at some point we understand that Go works better, then we will try.

At the front end, we are moving towards independent applications. There is a monorepository on the backend. There are many advantages to this, but there are also certain disadvantages - you can talk about this for a long time. We look towards microservice architecture based on what will be useful in our environment.

Microservice architecture works well where there are few connections. If you have a lot of connections, then microservices turn into pain. There is no silver bullet. To do this, we have a whole team that explores what is best used in our environment.

---

Hiring engineers, not language experts

- What do you need to be to get to you?

- We take people who are interested in what they do. This is a cliche - about burning eyes. However, this is important. Even if you are a good developer, but you do not care what to cut, if only to work from ten to six and receive money - with a high probability this will not suit us.

- We take people who want to learn, develop. If you think that everything has already been achieved and now the king of the world is also not our option.

- Since we have a fairly good feedback channel from developer to business and vice versa, the “here, work” approach is not very suitable. We try to hire people who are ready to offer their vision, they have opinions and questions.

This moves the project forward much faster than if you hire three super-seniors who say "my work time is up and generally you pay me not enough." They will do less than the person who cuts the project in a day at the hackathon, brings it to production.

- We are looking for people who care, who are interested in moving forward.



- So I came to you, said that I’m all so purposeful, I have a lot of my opinion, my eyes are on fire. I still poked at them with something to shine, I say, take me. So take it?

- Interviews are not so simple. We create conditions close to work processes and watch how a person shows himself. If you are a developer, you will write code. If eychar - you will interview.

- Will the developer write the code at the interview?

- Yes, I know, this is very much discussed now.

It is clear that we look at several indicators when we interview developers. But our stack is not the most typical, and the code base is large, therefore, in addition to burning eyes, we expect that a person as an engineer knows how to understand complex concepts, regardless of language.

If a person says: “I am a React programmer,” this already sounds strange. That is, if not React, you will not understand?

We try to give tasks that we ourselves do every day. They do not require super knowledge of the subject area. We do not ask what is closure in JS. We may ask: “Here you have Jira and Wrike. How do you sync data between them? ”

It doesn’t matter in what language the candidate will write this task - at least on Go, at least on anything. You can even simply draw what to get and where to put it. Rather, we are recruiting engineers than language specialists.

- If a person came with ingenious engineering thinking and solved the problem in such a way that you really like it, but he doesn’t have “burning eyes and that’s all”, will he get into the company?

- This is a crafty question. If he is a cool engineer, then his eyes are on fire. There is no code in a vacuum. There are no people who solve olympiad problems, and they are happy with everything. Any programmer is an egoist and a narcissist. It's just that he expresses it in code. Any person wants the results of his work to be visible and beneficial to people.

And from this it follows that the person does not care what to do. Why, for example, is it hard to find people in the banking and financial sectors? It’s boring there. I do not speak for everyone, but to make payments for an Australian bank ... Let there be a super hierarchy - ask anyone, and almost everyone will say "I do not want" to you.



- The banks are bored. Do you have fun?

“So far, too much.”

I like Wrike because there are constantly new challenges that I can influence. It doesn’t happen that everyone has already come up with for us. We always discuss, express our opinion, invest in every feature, in every iteration.

- Are the tasks between the teams very different?

- The specifics are very different. One team does a gantt chart. They have Canvas there, their own logic. A team that does simultaneous editing of tasks, as in Google Docs - there is both math and Dart on the backend. There is only one stack from team to team, but the application is completely different.

- If a person says that he is tired of his team and wants something else, will he get it from a simple transition?

- Of course. Transitions are often any. People become fronts from back-ups, engineers become product-oeners. When I came to Wrike, I was struck by the number of horizontal connections between the teams. People constantly communicate, go somewhere together, hang out.

- How did it happen? Large company, 400 people in the office. How did they become friends?

- This is a matter of selection and culture. It's hard to talk about culture - these are ephemeral things. You feel them, but you cannot describe in words. During the selection, there is a Cultural fit stage, when we look how much a person fits the team.

- What kind of criterion is there? How do you determine whether it fits or not?

- There are TOP-5 stupid questions at the interview. One of them is who you see yourself in five years. It doesn’t sound very good, but in a different wording it is useful. For example, what are your goals, what do you want at all? And if a person can formulate them, this is a plus.

- If a person said, but you didn’t like what he wants?

- It rarely happens that a person wants something very contrary to our values. If he says that he wants to sing or ski, then yes, it will be strange.

Our task is to look for people who want to do the job well, to benefit and grow. And development is impossible in a vacuum. Need to communicate. Together with other people you achieve more. If you just come, not saying hello to sit down in your seats, work and leave for eight hours, then you will do much less for your own development.

- That is, it is bad if a person does not answer?

- Not. We will not put an end to it. All people want something.



- I'm just trying to understand whether it is possible not to pass this stage of the interview?

- Easy. We are a little freaky in terms of productivity and achieving goals, we are looking for people of our kind. There are those who like to be in the process, and there are people who like the result. We are about the second.

“That's why you can’t get through.” Wrike is a safe place. The same Google said that one of the most key criteria for a successful team is psychological safety. I can only take responsibility if I know that I am safe.

If a person is frankly toxic, we know that he will bring more destruction to the team - even if he is a super cool programmer.

- Do you need to criticize people to study?

- To criticize is not quite the right word. Be sure to need feedback. We are not here to look for the guilty - we are here to do the job efficiently.