Internship in IT: manager's point of view

Recruitment for the summer internship 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 insider information about how the internship takes place. But much in this process remains a mystery to those who do not work in the company. And if you look from the point of view of development managers, then there are even more questions. How to conduct an internship correctly, how to maximize mutual usefulness with an intern, how to get to know him in three months and teach everything that is required to continue working?

We have prepared this article together. Let us introduce ourselves: Ignat Kolesnichenko from the service of distributed computing technologies, Misha Levin from the service of machine intelligence of the Market, Denis Malykh from the application development service, Seryozha Berezhnoy from the department of the development of search interfaces and Dima Cherkasov from the anti-fraud development group. Each of us represents his or her internship direction. We are all managers, we need interns, and we have some experience working with them. Let us tell you something from this experience.
')

Interview before internship

Candidates waiting for 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, managers evaluate both.

_Ignat:

Even if a person is very cool, but absolutely uncommunicative, he will not be able to apply all the skills. We pay attention to this, of course, but this is not a reason not to take someone for an internship. For three months, everything can change, and besides, your first impression may be wrong. And if everything is correct - it will be necessary for a person to explain, look for other commands to him. Communication for trainees is definitely not a key factor. Still, professional skills are much more important.

_Denis:

I like people who tell stories - in a good way. The person who can tell how they and the team heroically coped with some facac is interesting. I begin to ask additional questions when such a story pops up. But this rarely happens if you just ask "to tell about something interesting in your projects."

One candidate once said a wonderful phrase that I even wrote down: “I successfully avoided solving 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 is great if the trainee estimated in advance what details of his experience (not from the summary) he could share. This should be a short story strictly in the case.

_Denis:

I pay attention if a person tells that he tried many languages, approaches. People with a wider outlook come up with more elegant solutions in combat mode. But this is a mixed plus. You can grab on tops, but seriously not learn anything.

Time for the stories described by Denis usually remains only at the final interview. Until then, it is necessary to demonstrate the fundamental and practical knowledge that will form the basis of future work. And, of course, you will need to write code on a blackboard or on a piece of paper.

_Misha:

We test knowledge of probability theory and mathematical statistics. We look at whether a person has experience with metrics, machine learning algorithms, setting up their parameters, retraining, etc. We expect that a person can write code sufficiently to be an analyst.

_Denis:

Those who come to the interview mostly know languages: we have a good school of basic languages ​​in Yekaterinburg, good institutions. But honestly, an internship candidate with good hard skills is a rare case, at least in our epsilon-neighborhood. Here for example, Swift. It is very difficult to work with strings, and people who offhand from the head can work with them are few. For such immediately clings to the eye. I often give the task of interviewing, which is just related to the processing of strings. And for all the time there was only one person who at once, 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 on Swift on a piece of paper.

Algorithm Testing at Job 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-tenders are tested.

_Misha:

At the interview must give some algorithmic problem. The candidate has to figure out how to implement it in Python, preferably without errors. You need to understand how to check your program and fix it yourself.

Experience in algorithms is useful for three reasons at once. First, it is obviously required in algorithmic problems - 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 to get into the algorithms themselves (and there are already quite a few of them). Thirdly, if you were not taught the algorithms at the university, and 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:

Most of the mobile development is “shifting JSON”. But every six months there are times when algorithms are needed. I now draw beautiful maps for Yandex. Weather. And for a week I had to implement a smoothing algorithm, Sutherland-Hodgman algorithm and Martinez algorithm. If a person did not know what a hashmap or a priority queue is, he would have sat down with this for a long time and it is unclear whether or not he would have coped without help.

Algorithms - the basis of development. This is what helps the developer to be a developer. It doesn't matter what you do. They are needed in simple projects, where the main work consists of “shifting JSON”. Even if you do not write the algorithms themselves, but implicitly use any data structures, it is better to understand them. Otherwise, you will get applications that are slow or incorrect.

There are programmers who came to the development academically: they entered the university, honestly weaned for five years, received a specialty. They know the algorithms because they have been taught. And then the knowledge of the algorithms itself does not characterize a person’s horizons; this horizon must be checked in another way.

And there are self-taught people to whom I also rank myself. Yes, technically I have an IT education, a degree in software engineering. But self-taught programmers learned how to "contrary to". They did not have a university program. Usually they are not familiar with the algorithms - because they have never encountered the need to study them. And when such a person understands the algorithms, it means that he spent time and figured out them. After graduating from university, I realized that I have white spots on the part of fundamental algorithms - the fact is that the specialty was applied. I went and studied online courses at Princeton University, the well-known Robert Sedgwick. Understood, did all the homework. And when a person at a job interview tells a similar story, it immediately becomes interesting to me, 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. An internship candidate - he is still at university. Just a year ago, he was told everything about the algorithms in detail. He is expected to be able to reproduce them. If a person is adequate and listened to the lectures carefully, he will simply know everything, get from the cache.

What tasks does the intern decide?

Typically, an internship program can be scheduled and discussed during final interviews. The trainee only at the very beginning of the work can get training tasks, the result of which will not be involved in production. Moreover, the probability of obtaining such tasks is small. Most often, combat projects from backlog are given, 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 in such a way that the trainee gets acquainted with different parts of the service and works in the same environment with other team members.

_Ignat:

These are extremely useful tasks. Perhaps they will not increase cluster utilization by 10%, they will not save a million dollars to the company, but they will make hundreds of people happy. For example, we now have an intern who deals with our client to run operations on our clusters. Before starting the operation must download some data to the cluster. It usually takes 20-40 seconds, and before that it happened silently: launched it in the console and you sit, you look into the black screen. The intern came and made a feature in two weeks: now you can see how the files are uploaded and what is happening. The task, on the one hand, is simple in the description, and on the other, there is something to dig into, which libraries to look at. The best part is that you did it, a week passed, it turned out to be in clusters, people are already using it. You write a post to the internal network - they say thank you.

_Misha:

Trainees prepare models, collect data for them, come up with metrics and conduct experiments. Gradually, we simply begin to give him more freedom and responsibility - we check whether he copes. If yes - he goes to the next level. We do not assume that when the intern comes, he knows all this. The head helps him to understand, gives a link to an internal resource or online course.

If the trainee shows himself up to the mark - something priority may be given him that is important for a department or other services.

_Dima:

Our trainee is now engaged in antifraud hardcore revision. This is a system that fights with a variety of abuses and fraud on Yandex services. At first they thought of giving things that were not very complex and not very important for production. We try to think in advance about the trainee’s tasks, but then we saw that a person “burns” and quickly and well solves problems. As a result, we began to entrust him with the launch of antifraud for new services.

In addition, there is a small chance to get a task to which colleagues have not previously approached because of its size.

_Dima:

There is one old system, but there is a new one, not yet completed. You need to move from one to another. In the future, this is an important project, although with high uncertainty: you need to communicate a lot, read the incomprehensible legacy code. We at the final interview honestly told the intern that the task is difficult. He replied that he was ready, came to our team, and everything worked out for him. It turned out that he has the qualities of not only the developer, but also the manager. He was ready to walk, learn, ping.

Trainee mentoring

An intern needs a mentor to dive into the process. This is a person who is aware of not only their tasks, but also the tasks of the trainee. There is regular communication with the mentor, you can always turn to him for advice. A mentor can be either a team leader (if it is a small group), or someone from colleagues, regular team members.

_Ignat:

I try to come up at least in a day, asking how the intern is doing. If I see that I have dug, then I try to help him, ask what the problem is, and dig up with him. It is clear that it takes my strength and makes the intern's work not so efficient integrally - I spend my time too. But this allows him not to dig in anything, to get a result. Still, it's faster than if I did it myself. I myself need a conditional task for 5 hours. An intern will do it in 5 days. And yes, I will spend 2 hours during these 5 days to talk with the intern and help. But at least 3 hours I will save, and the trainee will be pleased that he was prompted, helped. In general, you just need to communicate tightly, watch what a person does, do not lose contact.

_Seryozha:

The intern is constantly in touch with his mentor and communicates with him several times a day. The mentor reviews the code, is engaged in pair programming with a trainee, it helps when some problem areas arise. In this way, a combination of the help of a mentor and real combat missions, we train the front-tenders.

_Dima:

So that the trainee does not turn out to be abandoned, we discuss, even before hiring, who will mentor him. It is also a big pumping for the mentor himself: preparing for the role of a tmilid, checking for the ability to keep in mind both his task and the trainee's task. There are regular meetings that I sometimes go to myself to keep up to date. But the mentor communicates with the intern quite regularly. He initially spends a lot of time, but it pays off.

However, the presence of a mentor does not mean that all issues that arise are solved through it.

_Misha:

It’s accepted here that people facing a problem ask their neighbors for advice, colleagues and quickly find help. The faster a person grows, the more often he needs to go to his colleagues to learn something. It is even useful to simply learn about the tasks of other people in order to come up with new tasks. When the trainee himself is able to agree, understand what is important to the other side, and arrive at a result in a team, he will grow much faster than the one for whom the leader must do it.

_Seryozha:

There is documentation, but most of the information is dissolved in the air. If you absorb it at the start of a career, this is an additional advantage, and we can focus the person on what needs to be learned.

The ideal trainee is someone who has been training for several months, becomes a junior developer, then just a developer, then a team leader, etc. For this, you need an archetype of a student who is not ashamed to ask if something is not clear to him, but at the same time he is capable of independent work. If he was told that you can read about it there, he will go, read and really come back with new knowledge. He may be wrong, but he should not err more than one, 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 himself, picks himself up for a long time, does not ask any questions, is unlikely to take root.

The end of the internship

Before starting work, we sign a fixed-term contract with each trainee. Of course, the internship is paid for, issued by the Labor Code of the Russian Federation, and the intern has the same advantages as any other Yandex employee. Three months later, the program ends - many interns are then transferred to the state (for an open-ended contract).



On the one hand, it is important for the manager that the developer fulfill his trainee minimum. This is what the intern leads to, starting with the interview. However, this is only the beginning of the story. An intern for us is always a potential candidate for the state. The minimum program for a manager is to see such a person at the very beginning, who after three months will not be ashamed to recommend to other departments. Maximum program - to keep it in the same team, taking in the state. At the same time, we take into account that a second or third year student - even if he has become an intern - with the onset of the school year will need to continue his studies at the university.

_Seryozha:

First of all, interns for us - human resources. 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 interaction in teams to encyclopedic knowledge about all our systems.

_Ignat:

Taking the intern, we immediately try on him to get him to our team. And as a rule, the only obstacle is the lack of a vacancy. Interns try to take enough young guys. If a person has five years of development experience, he comes to Yandex and he is a trainee in terms of level, then alas, for us this means that he, although being a good boy, once settled in Yandex with five years of experience, will not be able to grow to a senior developer . Usually it's about speed: slow growth in the past will mean slow growth in our country too. Yes, sometimes the understanding that a person does not pull, comes only after three months. But it is quite rare. In more than half the cases, we are ready to take people to the state. In my memory, there was no such thing that a person successfully sat down, but could not pass the interview for a full-time position.

_Misha:

We offer all successful interns to stay in the company. After the internship, we usually take on more than half fulltime. It is more difficult with a summer internship because often students come to us, for example, of the third year and it is difficult for them to combine work with studies.

_Dima:

Suppose the trainee does an excellent job with tasks and has a lot of prospects to grow into a good developer - even if he doesn’t have enough experience now. And suppose there is no vacancy for an open-ended contract. Then everything is simple: I need to go to my leader and tell him - this is a very cool person, he should be left with all his might, let's offer him something, find where to attach him.

Internship Stories

_Denis:

The girl who joined us for an internship in 2017 was from Perm. This is 400 kilometers from Ekaterinburg to the west. And every week she came to us from Perm by train to the School of mobile development. In the afternoon she came, in the evening she studied and in the late evening went back. Assessing such zeal, we called her to work, and it justified itself.

_Ignat:

A few years ago we participated in the trainee exchange program. It was interesting to work with foreign guys. But the interns from there are no stronger than, for example, from a ShAD or with FKNa. It would seem that the EPFL is in the top 20 universities in Europe. At that moment - like the not very experienced interviewee - there was such an expectation: incredible, we are interviewing people from the EPFL, they will be super cool. But people who have received basic education about coding with us - including at key regional universities - are quite up to par.

Or another story. Now I have a guy in my staff, quite young, about 20 years. 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 decided, I looked, and it seems that your architecture is poorly built. Let's redo it. The code will be easier, more understandable. I, of course, dissuaded him: the amount of work is large, there is no profit for users, but the idea sounds absolutely reasonable. The man figured out a complex multithreaded process and suggested improvements — perhaps, 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 have passed, and we started this task. I gladly took him to the state. We are not geniuses. You can come, sort out something and point us to our problems. It is appreciated.

_Misha:

We have such perfect interns. Despite the lack of experience, they see the task not only at the technical, but also at the global level. Propose fundamental improvements. They have an understanding of how to translate tasks from the real world into a technical one without losing meaning. They wonder what the final goal is, whether it is worth digging into the details now, or you can completely change the approach to the problem or even the formulation of the problem. So, they have the groundwork to be several levels higher. To pass this way, they just need to pump over some skills and internal tools. Plus run a few successful projects.