Organization of internships for students: rakes and tricks
Internships are obviously different. In my company intern june. So that the context is clear: a company of ~ 300 people is developed in Java \ C # \ 10 types of JS, developers are trained in only 2 cities in Lithuania. Websites, banks, power plants, zoos - the projects are very different. The company is growing, we need people. One of the options for employment: internship.
Regular development trainee - a 2-4 year student, IT, mathematics; interning in parallel with studies in Vilnius or Kaunas. Starts an internship of 40 people, completes 30-35, 10 is hired by the Juny.
10 people is not just a beautiful number. For a hired joon you need at least one senior / leader who has free time and a project where the trainee can safely enter and download, where he will get an experience and benefit (and pass a client security check). Plus, there is no reason to hang a juna on a lady who is not eager to be a mentor. Plus, javista are not eager to hire .NET interns.
10 Jun are born six months, a team of 13 people.For a month, it still does not work, but progress is evident. It all starts with planning: leads are polled for “how many juns your team will pull in six months” (ha ha, so they answered), lecturers and mentors are selected and trained, a program is developed, an entrance exam is prepared.
After the entrance exam in each city, 20 candidates are selected, of which 4 teams are formed, each of which saws an educational project under the guidance of a mentor for 3 months. In parallel, all students listen to a set of lectures once a week: front, back, best practices, testing. Then another exam (graduation), a series of interviews - and new employees join the team.
In principle, nothing complicated, but the ability to dole is a lot.
Problems begin already when choosing mentors / lecturers. You can not just come to the lead and say: we will take 6 people from you, they will spend the order of the day a week for interns. You can not come to the developer and say: you will conduct lectures - you need volunteers. You need to think about travel and vacations (read, no summer internships). What pleases, there are no problems with motivation: money, new experience, team-leadership training is enough. When 2 lecturers (front + back) and 4 mentors in each city are selected, the lapping, called “preparation for the entrance exam”, begins.
Do you know how to conduct an interview? The entrance exam is not much more difficult. Problems begin with the preparation of questions. For example, in Kaunas, they like OOP, I would prefer to throw him out of the exam (and convinced Vilnius of this). EntityFramework vs Dapper, SQL vs JS, hardcore vs trivia - 4 Holy Wars have died down, now I am mentally preparing for the fifth. What is good is the local wars, and people are really trying to pick up arguments. What grieves - the argument takes time, which is money. To save time, a standard for preparing test tasks was developed.
At first everyone writes 5-10 tasks, 1-2 for each topic. Each team then assembles locally and discusses all tasks. For each resolution is put: fit, fit after revision (list of actions), slag (list_cause). If the task is approved by both cities: it falls intoclub final list. If there are not enough tasks, then tasks for revision are considered. If they are not enough, additional tasks are written, or slag is fixed. Two iterations are enough to fill the test part.
The logical part is still simpler: everyone chooses 3 tasks that they would like to see in the exam, the tasks with the highest number of votes are entered into the final list. In the past year, there were 4 tasks for three seats, and an additional vote was quickly held. Why fast? Because there is no fundamental difference between the best tasks.
After the exam, a review is conducted: which tasks were solved more, which fewer, which topics turned out to be the most difficult, are looking for correlations “problem solving - invitation for an internship”. Such an analysis will allow finding the optimal difficulty for the tasks and convincing the colleagues to abandon some tasks (let them only next year). Actually, this is how the tasks on the OOP theory were partially replaced by “the implementation of OOP in C #”.
After the preparation of the final list of tasks begins glossing. The text is formatted, tasks are solved by colleagues for searching for inaccuracies, tasks are checked in the IDE, matches with previous years are sought. In the last semester, we did not direct the gloss - and 5 test tasks out of 35 turned out to be incorrect.
In parallel with the preparation of the exam is advertising internships. Facebook, newspapers, own site - only about 10 channels and 30 activities. HR and marketing are responsible for this.
A separate moment - registration. Someone registers twice, someone does it at the last moment. Some come without registration at all. The number of students is important: it determines the number of tasks to be printed. Empirical formula: the exam will be 80% of registered participants.
A day or two before the exam is sent a reminder, FAQ, exam rules. The reminder is important: individual comrades register several months before the exam, and may well forget about it.
University, one or two points, a stack of tasks, 4 people from the company. It is in every city. It is necessary to agree with the university in advance, it is necessary to indicate the expected number of students, the arrival time of the host group, the departure time of the group, who will give the keys, who will take them. It is especially important "who will take" - the exam ends in the evening. You need to arrive half an hour before the exam: check the audience, the equipment, meet the students, answer the questions, bring the FAQ to the blackboard, if there is a projector, put handles and blank sheets on the table. It is important to understand: university staff will help you only of good will, so it is better to check everything in the office. In addition, spoiling the attitude today - you will not get an audience in the next semester. It is worth thinking about the earth - to prepare water for drinking (for yourself, students can bring with them what is written in the rules),
At the beginning of the exam, we repeat the rules, distribute tasks, and start. Boredom begins. The people decide that the examiners have nothing to do. Students do not cheat, or cheat unnoticed. Here it is important to find a lesson for observers, and there are few of them. The first is to verify that the student has written his name clearly, this is really important when checking the exam. The second is to collect exam reviews. The student comes out - and the observer asks him the question “what did you dislike most of all?”. It is in this form. You ask what was best - you will not hear anything interesting. Fidbek collect all observers in turn. One gathered a portion - went to write, the next comes to the post.
After the exam, all materials are collected, the lights are turned off, the doors are closed, the key is dealt. Begin tedious: check.
For verification, we prepare the sheet in advance in Google docks and agree on parallelism. First, test items are checked, then logical ones. The easiest option: one person checks 50-100 test tasks, then all materials are collected in one pile and the remaining team members parallel the verification of logical tasks: each logical task is checked by one person in the city.
Logic tasks are harder to check, but more fun: students joke, write thanks, and hope that “you guys will check what I've written here.” Sometimes there are solutions that are striking in their ruthlessness, such as calculating "in the forehead" the Flavel problem for 100 people. Sometimes the preliminary principles of assessment do not work - most students understand the task completely differently as planned. In such cases, you have to quickly look at a dozen solutions and come up with new evaluation criteria.
For a test task, we have formed a “designer’s dream” document for several years: fix a column with names on the left (tear out the names from the registration database), fix the task number and maximum points for the logic task from above, divide the columns with bold borders according to the layout on the sheets. Tests in this format are checked without the participation of the brain. For logical tasks, the reviewers may create additional columns.
Exam and check should be as fast as possible. A student has two time periods in an academic year when he is free - between sessions. It is necessary to have time to conduct an internship in these windows (you can slightly hook the winter session - but not the summer one, for graduation \ diploma). Therefore, it is important to check the tasks and send invitations as soon as possible. Ideally - 2-3 days, previously agreed with the authorities \ customers - the developers will be busy. Some students will refuse to train - so you need to prepare in advance the "second tier". From practice, 1-2 students from the second echelon will receive their invitations.
It's simple: theory, then exercise. Personally, I try to dilute the theory of suitable cool-storywith Habra . It is very important to allocate as much time as possible to the exercises. Trainees often say “everything is OK for me” even if something does not work - and then they do not understand the material. You have to check everything and everything, which takes time. The most frequent shoals are stored in the corporate wiki, come in handy next year. Initialization / configuration is a separate evil, for 1-2 interns at a lecture, something definitely does not work.
In the course of lectures, we start from the front and end with a back — so the interns see the results from the very second lesson. The first is marketing, Git, html \ css basics.
There is always the temptation to embrace nevpihuemoe instead of concentrating on key aspects of the lecture. It helps crushing exercises to the smallest elements, or 3-4 elements with increasing complexity - planning accuracy increases. At the end of the lecture, links to materials are left, ideally articles like "how to make X using Y". Required breaks, 10-15 minutes. Mandatory for interns, because at each break half of the interns go, and the second half is subjected to the help of a lecturer.
In addition to preparing the content, some of the time is spent on infrastructure - two repositories are being prepared: Starter, End. The first one opens for interns before class (ReadOnly), the lecturer will commit to it during the lecture. The second one opens at the end of the lesson - it will look like Starter, only a little smoothed. Key repositories should be made the same for all groups - if each lecturer has his own version, it is more difficult to replace one of them, especially on the front with a hell of dependencies. And yes, something regularly happens with the lecturers: a critical bug on the sale of an important client, a business trip of an important client, a particularly important release of a particularly important client. In this regard, it is very convenient to have two lecturers in the neighboring cities: if onegets hit by a bus , the second one will replace them.
You can give exercises at home, their implementation correlates with the recommendation of hiring. I don’t know, this is because strong trainees do exercises that are elementary for them, or because doing exercises makes trainees strong.
The key principle: you need to understand that the guys in the audience in a couple of months will work in the same team as the lecturer. Do not skimp on explanations now, it will save time later.
4 teams of 5 interns, led by a mentor engineer. A mentor is a cross between a lead, a scrum master and a project manager. The task is to make a project. Initially simple, but you can add features if necessary. Practice shows that half of the interns will fall off: it may completely stop going, it may just not pull the complexity, you need to be ready for the prioritization. Mentoring is a real new experience for the developer, allowing you to look at things from a completely different point of view. How to manage a team - everyone chooses himself; I will describe just a few of the features of our mentoring.
The first is a hard time limit. 8 hours a week for a team of 5 interns. All the sprints, all the questions, all the rituals, the whole setting of tasks - on the mentor. After this, it is much easier to understand the motivation of your lead.
Second, the dependence on lectures. To some extent helps in planning. It is useful to communicate with the lecturer: to find out what he will talk about, to ask to highlight some details in more detail.
Third, at the end the mentor leads a team of 3-4 full-stack juna. It is important as soon as possible to instill development discipline such as code review and pull requests, this allows you to keep the code at least in the minimum order.
Fourth, the mentor lives in a place where the bus factor is complemented by train, planeand UFO factors . Today you have 5 people in a team, and tomorrow there will be EXTREMELY three. In addition to trivial diseases, preparation for a diploma, a change of interests, and awareness of the time being eaten by an internship occur. In my memory, the most epic was a letter like "I checked and passed the exam, but did not know that you are learning web development. You are doing great things, but I am a Data Scientist, so let's continue without me . "
Fifth, the mentor evaluates the intern every week. If something happens to the mentor, someone else can pick up the team. The intern’s invitation to interview is largely depends on the recommendation of the mentor - so the impressions of the mentors should be recorded. At one of the meetings of the transfer of experience, one of the colleagues observed notes about himself as a favorite - the experience was transmitted by his former mentor.
Checks only those topics that were studied during the internship. It is performed in the office, with Google, but without instant messengers. Purely practical tasks: the intern gets access to the repository, kodit something, commit.
Trainees after the exam are sorted according to the sum of two parameters: points for the exam and the assessment of the mentor, after which they begin to receive invitations for an interview. Interview students colleagues who did not participate in the academy. Now we are thinking about the simplification of the system: the mentor says “I recommend \ no”, all recommended ones are sorted by exam scores.
Relaxation. Analysis of lectures, retro, data analysis, updating of documentation, preparation of the next semester - and team building with hired developers.
Regular development trainee - a 2-4 year student, IT, mathematics; interning in parallel with studies in Vilnius or Kaunas. Starts an internship of 40 people, completes 30-35, 10 is hired by the Juny.
10 people is not just a beautiful number. For a hired joon you need at least one senior / leader who has free time and a project where the trainee can safely enter and download, where he will get an experience and benefit (and pass a client security check). Plus, there is no reason to hang a juna on a lady who is not eager to be a mentor. Plus, javista are not eager to hire .NET interns.
First look?
10 Jun are born six months, a team of 13 people.
After the entrance exam in each city, 20 candidates are selected, of which 4 teams are formed, each of which saws an educational project under the guidance of a mentor for 3 months. In parallel, all students listen to a set of lectures once a week: front, back, best practices, testing. Then another exam (graduation), a series of interviews - and new employees join the team.
In principle, nothing complicated, but the ability to dole is a lot.
Recruit team
Problems begin already when choosing mentors / lecturers. You can not just come to the lead and say: we will take 6 people from you, they will spend the order of the day a week for interns. You can not come to the developer and say: you will conduct lectures - you need volunteers. You need to think about travel and vacations (read, no summer internships). What pleases, there are no problems with motivation: money, new experience, team-leadership training is enough. When 2 lecturers (front + back) and 4 mentors in each city are selected, the lapping, called “preparation for the entrance exam”, begins.
We are preparing the entrance exam
Do you know how to conduct an interview? The entrance exam is not much more difficult. Problems begin with the preparation of questions. For example, in Kaunas, they like OOP, I would prefer to throw him out of the exam (and convinced Vilnius of this). EntityFramework vs Dapper, SQL vs JS, hardcore vs trivia - 4 Holy Wars have died down, now I am mentally preparing for the fifth. What is good is the local wars, and people are really trying to pick up arguments. What grieves - the argument takes time, which is money. To save time, a standard for preparing test tasks was developed.
At first everyone writes 5-10 tasks, 1-2 for each topic. Each team then assembles locally and discusses all tasks. For each resolution is put: fit, fit after revision (list of actions), slag (list_cause). If the task is approved by both cities: it falls into
The logical part is still simpler: everyone chooses 3 tasks that they would like to see in the exam, the tasks with the highest number of votes are entered into the final list. In the past year, there were 4 tasks for three seats, and an additional vote was quickly held. Why fast? Because there is no fundamental difference between the best tasks.
After the exam, a review is conducted: which tasks were solved more, which fewer, which topics turned out to be the most difficult, are looking for correlations “problem solving - invitation for an internship”. Such an analysis will allow finding the optimal difficulty for the tasks and convincing the colleagues to abandon some tasks (let them only next year). Actually, this is how the tasks on the OOP theory were partially replaced by “the implementation of OOP in C #”.
After the preparation of the final list of tasks begins glossing. The text is formatted, tasks are solved by colleagues for searching for inaccuracies, tasks are checked in the IDE, matches with previous years are sought. In the last semester, we did not direct the gloss - and 5 test tasks out of 35 turned out to be incorrect.
From the interesting: what do you think, what glyphs to choose for answers to test tasks, 1-2-3-4 or abcd?
1-2-3-4. When checking saves time, because the keys are slightly more convenient.
Media
In parallel with the preparation of the exam is advertising internships. Facebook, newspapers, own site - only about 10 channels and 30 activities. HR and marketing are responsible for this.
A separate moment - registration. Someone registers twice, someone does it at the last moment. Some come without registration at all. The number of students is important: it determines the number of tasks to be printed. Empirical formula: the exam will be 80% of registered participants.
A day or two before the exam is sent a reminder, FAQ, exam rules. The reminder is important: individual comrades register several months before the exam, and may well forget about it.
Entrance examination
University, one or two points, a stack of tasks, 4 people from the company. It is in every city. It is necessary to agree with the university in advance, it is necessary to indicate the expected number of students, the arrival time of the host group, the departure time of the group, who will give the keys, who will take them. It is especially important "who will take" - the exam ends in the evening. You need to arrive half an hour before the exam: check the audience, the equipment, meet the students, answer the questions, bring the FAQ to the blackboard, if there is a projector, put handles and blank sheets on the table. It is important to understand: university staff will help you only of good will, so it is better to check everything in the office. In addition, spoiling the attitude today - you will not get an audience in the next semester. It is worth thinking about the earth - to prepare water for drinking (for yourself, students can bring with them what is written in the rules),
At the beginning of the exam, we repeat the rules, distribute tasks, and start. Boredom begins. The people decide that the examiners have nothing to do. Students do not cheat, or cheat unnoticed. Here it is important to find a lesson for observers, and there are few of them. The first is to verify that the student has written his name clearly, this is really important when checking the exam. The second is to collect exam reviews. The student comes out - and the observer asks him the question “what did you dislike most of all?”. It is in this form. You ask what was best - you will not hear anything interesting. Fidbek collect all observers in turn. One gathered a portion - went to write, the next comes to the post.
After the exam, all materials are collected, the lights are turned off, the doors are closed, the key is dealt. Begin tedious: check.
Entrance exam verification
For verification, we prepare the sheet in advance in Google docks and agree on parallelism. First, test items are checked, then logical ones. The easiest option: one person checks 50-100 test tasks, then all materials are collected in one pile and the remaining team members parallel the verification of logical tasks: each logical task is checked by one person in the city.
Logic tasks are harder to check, but more fun: students joke, write thanks, and hope that “you guys will check what I've written here.” Sometimes there are solutions that are striking in their ruthlessness, such as calculating "in the forehead" the Flavel problem for 100 people. Sometimes the preliminary principles of assessment do not work - most students understand the task completely differently as planned. In such cases, you have to quickly look at a dozen solutions and come up with new evaluation criteria.
For a test task, we have formed a “designer’s dream” document for several years: fix a column with names on the left (tear out the names from the registration database), fix the task number and maximum points for the logic task from above, divide the columns with bold borders according to the layout on the sheets. Tests in this format are checked without the participation of the brain. For logical tasks, the reviewers may create additional columns.
Exam and check should be as fast as possible. A student has two time periods in an academic year when he is free - between sessions. It is necessary to have time to conduct an internship in these windows (you can slightly hook the winter session - but not the summer one, for graduation \ diploma). Therefore, it is important to check the tasks and send invitations as soon as possible. Ideally - 2-3 days, previously agreed with the authorities \ customers - the developers will be busy. Some students will refuse to train - so you need to prepare in advance the "second tier". From practice, 1-2 students from the second echelon will receive their invitations.
From funny
When registering, the student fills in several fields, including “About Me”. Later they get into the verification document, where things like “ About me: '; DROP TABLE ENTRIES; --I hope that did not work. ”
Moral: get ready to test you, too, are highlighted.
Moral: get ready to test you, too, are highlighted.
Lectures
It's simple: theory, then exercise. Personally, I try to dilute the theory of suitable cool-story
In the course of lectures, we start from the front and end with a back — so the interns see the results from the very second lesson. The first is marketing, Git, html \ css basics.
There is always the temptation to embrace nevpihuemoe instead of concentrating on key aspects of the lecture. It helps crushing exercises to the smallest elements, or 3-4 elements with increasing complexity - planning accuracy increases. At the end of the lecture, links to materials are left, ideally articles like "how to make X using Y". Required breaks, 10-15 minutes. Mandatory for interns, because at each break half of the interns go, and the second half is subjected to the help of a lecturer.
In addition to preparing the content, some of the time is spent on infrastructure - two repositories are being prepared: Starter, End. The first one opens for interns before class (ReadOnly), the lecturer will commit to it during the lecture. The second one opens at the end of the lesson - it will look like Starter, only a little smoothed. Key repositories should be made the same for all groups - if each lecturer has his own version, it is more difficult to replace one of them, especially on the front with a hell of dependencies. And yes, something regularly happens with the lecturers: a critical bug on the sale of an important client, a business trip of an important client, a particularly important release of a particularly important client. In this regard, it is very convenient to have two lecturers in the neighboring cities: if one
You can give exercises at home, their implementation correlates with the recommendation of hiring. I don’t know, this is because strong trainees do exercises that are elementary for them, or because doing exercises makes trainees strong.
The key principle: you need to understand that the guys in the audience in a couple of months will work in the same team as the lecturer. Do not skimp on explanations now, it will save time later.
Mentorship
4 teams of 5 interns, led by a mentor engineer. A mentor is a cross between a lead, a scrum master and a project manager. The task is to make a project. Initially simple, but you can add features if necessary. Practice shows that half of the interns will fall off: it may completely stop going, it may just not pull the complexity, you need to be ready for the prioritization. Mentoring is a real new experience for the developer, allowing you to look at things from a completely different point of view. How to manage a team - everyone chooses himself; I will describe just a few of the features of our mentoring.
The first is a hard time limit. 8 hours a week for a team of 5 interns. All the sprints, all the questions, all the rituals, the whole setting of tasks - on the mentor. After this, it is much easier to understand the motivation of your lead.
Second, the dependence on lectures. To some extent helps in planning. It is useful to communicate with the lecturer: to find out what he will talk about, to ask to highlight some details in more detail.
Third, at the end the mentor leads a team of 3-4 full-stack juna. It is important as soon as possible to instill development discipline such as code review and pull requests, this allows you to keep the code at least in the minimum order.
Fourth, the mentor lives in a place where the bus factor is complemented by train, plane
Fifth, the mentor evaluates the intern every week. If something happens to the mentor, someone else can pick up the team. The intern’s invitation to interview is largely depends on the recommendation of the mentor - so the impressions of the mentors should be recorded. At one of the meetings of the transfer of experience, one of the colleagues observed notes about himself as a favorite - the experience was transmitted by his former mentor.
Final exam
Checks only those topics that were studied during the internship. It is performed in the office, with Google, but without instant messengers. Purely practical tasks: the intern gets access to the repository, kodit something, commit.
Trainees after the exam are sorted according to the sum of two parameters: points for the exam and the assessment of the mentor, after which they begin to receive invitations for an interview. Interview students colleagues who did not participate in the academy. Now we are thinking about the simplification of the system: the mentor says “I recommend \ no”, all recommended ones are sorted by exam scores.