Set on in Yandex continues. It goes in five directions: backend, ML, mobile development, frontend and analytics. In this blog, in other blogs on Habré and beyond, you can find a lot of inside information about how the internship goes. But much of the process remains a mystery to those outside the company. And if you look from the point of view of development managers, then even more questions arise. How to properly conduct an internship, how to maximize mutual usefulness with an intern, how to get to know him in three months and teach him everything that is required to continue working?
We have prepared this article with the five of us. Let's introduce ourselves: Ignat Kolesnichenko from the Distributed Computing Technologies Service, Misha Levin from the Market Machine Intelligence Service, Denis Malykh from the Application Development Service, Serezha Berezhnoy from the Search Interface Development Department and Dima Cherkasov from the Antifraud Development Group. Each of us presents his own area of internship. We are all leaders, we need interns, and we have some experience with them. Let's talk about some of this experience.
Pre-Internship Interview
Candidates will have several technical interviews. Success in an interview depends less on soft skills (the ability to communicate effectively) and more on hard skills (skills in mathematics and programming). However, leaders evaluate both.
Ignat:
Even if a person is very cool, but absolutely uncommunicative, he will not be able to apply all the skills. Of course, we pay attention to this, but this is not a reason not to take someone on an internship. In three months, everything can change, and besides, your first impression may turn out to be wrong. And if everything is correct, it will be necessary to explain to the person, to look for other commands. For interns, communication is definitely not a key factor. Still, professional skills are much more important.
Denis:
I like people who tell stories - in a good way. A person who can tell how he and his team heroically coped with some fuckup is interesting. I start asking follow-up questions when a story like this comes up. But this rarely happens if you just ask "to tell about something interesting in your projects."
One candidate once said a wonderful phrase, which I even wrote down: "Successfully avoided tedious tasks."
Since there is little time for communication, the interviewer tries to get useful information about the candidate every minute of the meeting. It's great if the intern figured out in advance what details of his experience (not from the resume) he could share. This should be a short story strictly to the point.
Denis:
I pay attention if a person says that he has tried many languages, approaches. People with a broader outlook come up with more elegant solutions in combat mode. But this is an ambiguous plus. You can grab on top, but seriously learn nothing.
Time for the stories described by Denis usually remains only at the final interview. Until then, it is necessary to demonstrate those fundamental and practical knowledge that will form the basis of future work. And, of course, you will need to write the code on the board or on a piece of paper.
Mouse:
We test knowledge of probability theory and mathematical statistics. We look to see if the person has experience with metrics, with machine learning algorithms, with tuning their parameters, with retraining, etc. We expect that a person can write enough code to be an analyst.
Denis:
Those who come for an interview mostly know languages: we have a good school of basic languages in Yekaterinburg, good institutes. But to be honest, an internship candidate with good hard skills is a rare case, at least in our epsilon neighborhood. Take Swift for example. It has very complicated work with strings, and there are few people who can work with them offhand. For such immediately clings to the eye. I often give a task at interviews, which is just related to the processing of strings. And for all the time there was only one person who, right off the bat, on a piece of paper, was able to write such a Swift code. After that, I went and told everyone that someone was finally able to solve this problem in Swift on a piece of paper.
Checking algorithms in an interview
This is a separate topic, since candidates still have a question - why do we always evaluate knowledge of algorithms and data structures? Even future mobile developers and front-end developers are subject to such a test.
Mouse:
At the interview, be sure to give some kind of algorithmic problem. The candidate needs to figure out how to implement it in Python, preferably without errors. You need to understand how to test your program and fix it yourself.
Experience in algorithms is useful immediately for three reasons. Firstly, it will obviously be required in algorithmic tasks - which are infrequent, but still happen. Secondly, the developer will be able to more effectively solve problems related to algorithms, even if they do not require getting into the algorithms themselves (and there are already quite a few of them). Thirdly, if you were not taught algorithms at a university, but you still know how to work with them, then this characterizes you as an inquisitive person and will raise your authority in the eyes of the interviewee.
Denis:
A big part of mobile development is "JSON slicing". But once every six months there are cases when algorithms are needed. I am currently drawing beautiful maps for Yandex.Weather. And in a week I had to implement the smoothing algorithm, the Sutherland-Hodgman algorithm and the Martinez algorithm. If a person did not know what a hashmap or a priority queue is, he would sit down with this for a long time and it is not clear whether he would have coped or not without outside help.
Algorithms are the basis of development. This is what helps a developer to be a developer. It doesn't matter what you do. They are also needed in simple projects, where the main work consists of "transferring JSON". Even if you do not write the algorithms yourself, but implicitly use some data structures, it is better to understand them. Otherwise, you will end up with applications that are slow or not working correctly.
There are programmers who came to development academically: they entered the university, honestly studied for five years, and received a specialty. They know algorithms because they have been taught. And then the very knowledge of algorithms does not in any way characterize the horizons of a person, this horizons must be checked in another way.
And there are self-taught people, to which I count myself. Yes, formally I have an IT education, a degree in software engineering. But self-taught people learned to program “in spite of”. They didn't have a university program. Usually they are not familiar with algorithms - because they have never faced the need to learn them. And when such a person understands algorithms, it means that he spent time and figured them out. After graduating from the university, I realized that I had blank spots in terms of fundamental algorithms - the fact is that the specialty was applied. I went and studied online courses from Princeton University, well known Robert Sedgwick. Understood, did all the homework. And when a person tells a similar story at an interview, I immediately become interested in whether there is a desire to work with him or at least continue the conversation.
Ignat:
When you interview an intern, in a sense you expect even more than from an experienced developer. We are talking about the ability to solve algorithmic problems, quickly write at least some correct code. Candidate for an internship - he's still at the university. Literally a year ago, he was told everything about algorithms in detail. It is expected that he can reproduce them. If a person is adequate and listened to lectures carefully, he will simply know everything, get it out of the cache.
What tasks does the trainee solve
Usually the internship program can be outlined and discussed at the final interviews. Only at the very beginning of work, an intern can get training tasks, the result of which will not be used in production. Moreover, the probability of getting such tasks is low. Most often, combat projects are given from the backlog, that is, recognized as worthy of attention, but not priority and “separable” - so that other components do not depend on their implementation. Managers try to distribute them so that the trainee gets acquainted with different parts of the service, works in the same environment with other team members.
Ignat:
These are extremely useful tasks. They may not increase cluster utilization by 10%, they may not save a million dollars for the company, but they will make hundreds of people happy. For example, we now have an intern who is working on our client to run operations on our clusters. Before starting, the operation must load some data onto the cluster. Usually it takes 20-40 seconds, and before it happened silently: I launched it in the console and you sit, looking at a black screen. The intern came and made a feature in two weeks: now you can see how the files are uploaded and what happens. The task, on the one hand, is simple in description, and on the other hand, there is something to dig into, which libraries to look at. The best part is that you did it, a week has passed, it turned out to be on clusters, people are already using it. You write a post to the internal network - they say thanks to you.
Mouse:
Interns prepare models, collect data for them, come up with metrics and conduct experiments. Gradually, we just start to give him more freedom and responsibility - we check if he can handle it. If so, he moves on to the next level. We do not assume that when a trainee comes, he knows all this. The manager helps him figure it out, gives a link to an internal resource or an online course.
If the intern shows himself at his best, he can be given something of priority, important for the department or other services.
Dima:
Our intern is now working on hardcore modifications of the antifraud. This is a system that fights against a variety of abuse and fraud on Yandex services. At first, we thought to give things that were not very complex and not very important for production. We try to think over the tasks of the trainee in advance, but then we saw that the person “burns”, solves problems quickly and well. As a result, we began to entrust him with the launch of antifraud for new services.
In addition, there is a small chance of getting a task that colleagues have not approached before because of its volume.
Dima:
There is one old system, and there is a new one, not yet completed. You need to move from one to the other. In the future, this is an important project, although with high uncertainty: you need to communicate a lot, read incomprehensible legacy code. At the final interview, we honestly told the intern that the task was difficult. He replied that he was ready, he came to our team, and everything worked out for him. It turned out that he has the qualities of not only a developer, but also a manager. He was ready to walk, learn, ping.
Mentoring an intern
An intern needs a mentor to immerse himself in the processes. This is a person who is aware of not only his tasks, but also the tasks of the trainee. Regular communication has been established with the mentor, you can always turn to him for advice. The mentor can be either the head of the group (if it is a small group), or one of the colleagues, permanent members of the team.
Ignat:
I try to come up at least every other day, ask how the intern is doing. If I see that I have dug in, I try to help him, ask him what the problem is, and dig it out together with him. It is clear that this takes away my strength and makes the work of an intern not so integrally effective - I am also wasting my time. But this allows him not to dig into anything, to get the result. And it's still faster than if I did it myself. I myself need a conditional 5 hours for the task. The intern will do it in 5 days. And yes, I will spend 2 hours during those 5 days talking to the intern and helping out. But I will save at least 3 hours, and the trainee will be pleased that he was prompted, helped. In general, you just need to communicate closely, watch what a person is doing, not lose contact.
Serge:
The trainee is constantly in touch with his mentor and communicates with him several times a day. The mentor reviews the code, does pair programming with an intern, and helps when some problem areas arise. It is in this way, by combining the help of a mentor and real combat missions, that we train front-end developers.
Dima:
To prevent the intern from being abandoned, we discuss who will mentor him even before hiring. This is also a big pumping for the mentor himself: preparation for the role of a team leader, a test for the ability to keep in mind both his task and the task of the trainee. There are regular meetings, which I myself sometimes go to to keep abreast. But it is the mentor who communicates with the trainee quite regularly. It takes a lot of time at first, but it pays off.
However, the presence of a mentor does not mean that all emerging issues are resolved through him.
Mouse:
It is customary for us that people who are faced with a problem ask neighbors and colleagues for advice and quickly find help. The faster a person grows, the more often he needs to go to colleagues to find out something. It is even useful to just learn about other people's tasks in order to come up with new tasks. When an intern himself is able to agree, understand what is important to the other side, and come to a result in a team, he will grow much faster than the one for whom the leader should do all this.
Serge:
There is documentation, but most of the information is dissolved in the air. If you absorb it at the start of your career, that's an added benefit, and we can focus the person on what needs to be learned.
The ideal intern is someone who works for a few months, becomes a junior developer, then just a developer, then a team leader, etc. This requires a student archetype who does not hesitate to ask if something is not clear to him, but at the same time is capable independent work. If he was told that you can read about it there, he will go, read it and really return with new knowledge. He can make mistakes, but he must not make more than one mistake, maximum two times in the same place. The ideal trainee should develop, absorb everything like a sponge, learn and grow. The one who sits, tries to figure everything out on his own, pokes around for a long time, does not ask any questions, is unlikely to take root.
End of internship
Before starting work, we sign a fixed-term contract with each trainee. Of course, the internship is paid for, arranged according to the Labor Code of the Russian Federation, and the intern has the same benefits as any other Yandex employee. Three months later, the program ends - we then transfer many interns to the state (on an indefinite contract).
On the one hand, it is important for the manager that the developer fulfill his trainee minimum. This is where the trainee leads, starting with the interview. However, this is only the beginning of the story. An intern for us is always a potential candidate for the staff. The minimum program for a manager is to recognize at the very beginning such a person, whom after three months he will not be ashamed to recommend to other departments. The maximum program is to keep him in the same team, taking him on staff. At the same time, we take into account that a second or third year student - even if he became an intern - will need to continue his studies at a university with the onset of the academic year.
Serge:
First of all, interns are a personnel potential for us. We are trying to grow people inside Yandex so that they are ideally suited to our tasks. We give them everything, from the culture of communication and teamwork to encyclopedic knowledge about all our systems.
Ignat:
Taking an intern, we immediately try it on so that he gets into our team. And as a rule, the only obstacle is the lack of a vacancy. We try to take young enough as interns. If a person has five years of development experience, he comes to Yandex and is an intern in terms of level, then alas, for us this means that, although he is a good fellow, once he gets a job at Yandex with five years of experience, he will not be able to grow up to a senior developer . Usually it's about speed: slow growth in the past will mean slow growth for us. Yes, sometimes the understanding that a person does not pull comes only after three months. But this is rare enough. In more than half of the cases, we are ready to hire people. In my memory, there was no such thing that a person successfully interned, but could not pass an interview for a full-time position.
Mouse:
We invite all successful interns to stay with the company. After the internship, we usually take more than half for full time. It is more difficult with a summer internship, because often students come to us, for example, third-year students and it is difficult for them to combine work with study.
Dima:
Let’s say an intern is doing a great job and has a lot of potential to grow into a good developer, even if he doesn’t have enough experience right now. And suppose there is no vacancy for an indefinite contract. Then everything is simple: I need to go to my leader and tell him - this is a very cool person, we must leave him with all our might, let's offer him something, find a place to attach him.
Intern Stories
Denis:
The girl who got an internship with us in 2017 was from Perm. This is 400 kilometers from Yekaterinburg to the west. And every week she came to us from Perm by train to the School of Mobile Development. She came during the day, studied in the evening, and left late in the evening. Having appreciated such zeal, we called her to work, and it justified itself.
Ignat:
A few years ago, we participated in an exchange program for trainees. It was interesting to work with foreign guys. But the trainees from there are no stronger than, for example, from the ShAD or from the FKN. It would seem that EPFL is in the top 20 universities in Europe. I had at that moment - as a not very experienced interviewer - I had such an expectation: unbelievable, we are interviewing people from EPFL, they will be super-cool. But people who have received a basic education about coding with us - including in key regional universities - are quite up to par.
Or another story. Now I have a guy on staff, very young, about 20 years old. Works in St. Petersburg, came for an internship. He is very cool. You, as usual, give a person tasks, he solves them, and a month later he comes and says: I solved it, I look, and it seems that your architecture is poorly built. Let's redo. The code will become simpler, clearer. Of course, I dissuaded him: the amount of work is large, there is no profit for users, but the idea sounds absolutely reasonable. A person figured out a complex multi-threaded process and proposed improvements - maybe untimely, refactoring for the sake of refactoring. But as soon as you want to complicate this code, you can still do this refactoring. In fact, several months passed, and we took up this task. I gladly took him on. We are all not geniuses. You can come, figure something out and point out our problems to us. It's appreciated.
Mouse:
We have such perfect interns. Despite the lack of experience, they see the challenge not only on a technical level, but also on a global level. Suggest major improvements. They have an understanding of how to translate tasks from the real world into the technical world without losing their meaning. They think about what the final goal is, whether it is worth digging into the details now, or whether it is possible to completely change the approach to the task or even the formulation of the task. So, they have a backlog to be several levels higher. To go this way, they just need to pump some skills and internal tools. Plus to launch several successful projects.
Source: habr.com