Стажировки очевидно бывают разные. В моей компании стажируют джунов. Чтобы был понятен контекст: компания в ~300 человек, разрабатываем на Java\C#\10 видов JS, разработчиков стажируем только в 2 городах в Литве. Веб-сайты, банки, электростанции, зоопарки — проекты самые разные. Компания растет, нужны люди. Один из вариантов найма: стажировка.
Обычный стажер-разработчик — студент 2-4 курса, IT, математика; стажируется параллельно учебе в Вильнюсе или Каунасе. Начинает стажировку 40 человек, заканчивает 30-35, 10 нанимается джунами.
10 человек — это не просто красивое число. Для нанятого джуна нужен хотя бы один сеньор\лид, имеющий свободное время и проект, куда стажера можно безболезненно ввести и загрузить, где он получит экспу и принесет пользу (и пройдет клиентскую проверку безопасности). Плюс, нет резона вешать джуна на сеньора, который не горит желанием быть наставником. Плюс, джависты не горят желанием нанимать .NET стажеров.
10 джунов рождаются полгода, командой из 13 человек.За месяц пока не получается, но прогресс налицо. Начинается все с планирования: лиды опрашиваются на предмет «сколько джунов твоя команда потянет через полгода» (ха-ха, так они и ответили), подбираются и тренируются лекторы и менторы, разрабатывается программа, подготавливается вступительный экзамен.
После вступительного экзамена в каждом городе выбираются 20 кандидатов, из них формируются 4 команды, каждая из которых под руководством ментора 3 месяца пилит учебный проект. Параллельно все студенты слушают набор лекций, раз в неделю: фронт, бек, лучшие практики, тестирование. Затем еще один экзамен (выпускной), череда интервью — и новые сотрудники вливаются в коллектив.
В принципе, ничего сложного, но возможностей косякнуть — уйма.
Проблемы начинаются уже при выборе менторов\лекторов. Нельзя просто прийти к лиду и сказать: мы у тебя забираем 6 человек, они будут тратить порядка дня в неделю на стажеров. Нельзя прийти к разработчику и сказать: ты будешь вести лекции — нужны добровольцы. Нужно подумать о командировках и отпусках (читай, никаких стажировок летом). Что радует, нет проблем с мотивацией: деньги, новый опыт, тренировка тим-лидства — этого хватает. Когда выбраны 2 лектора (фронт+бек) и 4 ментора в каждом городе — начинается притирка, называемая «подготовка вступительного экзамена».
Вы же знаете, как проводить интервью? Вступительный экзамен ненамного сложнее. Проблемы начинаются при подготовке вопросов. Например, в Каунасе любят ООП, я бы предпочел выкинуть его из экзамена (и убедил в этом Вильнюс). EntityFramework vs Dapper, SQL vs JS, hardcore vs trivia — 4 Святых Войны отгремели, сейчас я морально готовлюсь к пятой. Что радует — войны локальные, и люди реально стараются подбирать аргументы. Что печалит — аргументация занимает время, которое деньги. Для сохранения времени выработался стандарт подготовки тестовых заданий.
Сначала каждый пишет 5-10 заданий, по 1-2 на каждую тему. Затем каждая команда локально собирается и обсуждает все задания. По каждому ставится резолюция: годно, сгодится после доработки (список действий), шлак (список_причин). Если задача одобрена обоими городами: она попадает вклуб финальный список. Если задач не хватает — рассматриваются задачи на доработку. Если и их не хватает — пишутся дополнительные задания, или фиксится шлак. Двух итераций хватает на заполнение тестовой части.
С логической частью все еще проще: каждый выбирает 3 задачи которые хотел бы увидеть в экзамене, задачи с наибольшим числом голосов заносятся в финальный список. В прошедший год было 4 задачи на три места, быстро провели дополнительное голосование. Почему быстро? Потому что принципиальной разницы между лучшими заданиями нет.
После экзамена проводится ревью: какие задания решались больше, какие меньше, какие темы оказались самыми сложными, ищутся корреляции «решение задачи — приглашение на стажировку». Подобный анализ позволят нащупать оптимальную сложность для заданий и убедить коллег отказаться от некоторых задач (пускай лишь в следующем году). Собственно, именно так задачи на теорию ООП частично заменились на «реализацию ООП в C#».
После подготовки финального списка задач начинается наведения глянца. Текст форматируется, задачи решаются коллегами на предмет поиска неточностей, задачи проверяются в IDE, ищутся совпадения с предыдущими годами. В последнем семестре мы глянец не наводили — и 5 тестовых заданий из 35 оказались некорректными.
Параллельно с подготовкой экзамена идет реклама стажировки. Фейсбук, газеты, собственный сайт — всего около 10 каналов и 30 активностей. За это отвечают HR и маркетинг.
Отдельный момент — регистрация. Кто-то регистрируется дважды, кто-то это делает в последний момент. Некоторые приходят вообще без регистрации. Число студентов важно: оно определяет количество распечатываемых заданий. Эмпирическая формула: на экзамене будут 80% от зарегистрированных участников.
За день-два до экзамена шлется напоминание, FAQ, правила экзамена. Напоминание важно: отдельные товарищи регистрируются за несколько месяцев до экзамена, и вполне могут забыть про него.
Университет, одна-две поточки, стопка заданий, 4 человека от компании. Это в каждом городе. С университетом надо договориться заранее, обязательно указать ожидаемое количество студентов, время прибытия принимающей группы, время отбытия группы, кто выдаст ключи, кто их заберет. Особенно важно «кто заберет» — экзамен завершается вечером. Прибыть нужно за полчаса до экзамена: проверить аудитории, аппаратуру, встретить студентов, поотвечать на вопросы, вывести FAQ на доску, если есть проектор, выложить на стол ручки и чистые листы. Важно понимать: сотрудники университета вам будут помогать лишь по доброй воле, так что лучше все проверить в офисе. Кроме того, испортив отношение сегодня — не получишь аудиторию в следующем семестре. Стоит подумать о земном — подготовить воду попить (для себя, студенты могут принести с собой, о чем написано в правилах), выяснить где поблизости туалет.
В начале экзамена повторяем правила, раздаем задания, стартуем. Начинается скука. Народ решает, экзаменаторам делать особо нечего. Студенты не читерят, либо читерят незаметно. Тут важно найти занятие наблюдателям, и таковых немного. Первое — проверка того, что студент написал свое имя разборчиво, это реально важно при проверке экзамена. Второе — сбор отзывов об экзамене. Студент выходит — и наблюдатель задает ему вопрос «что вам НЕ понравилось больше всего?». Именно в такой форме. Спросишь что было лучше всего — ничего интересного не услышишь. Фидбек собирают все наблюдатели по очереди. Один собрал порцию — пошел записывать, следующий заступает на пост.
После экзамена все материалы собираются, свет выключается, двери закрываются, ключ сдается. Начинается нудное: проверка.
Для проверки мы заранее готовим лист в гугло-доках и согласуем параллелизм. Сначала проверяются тестовые задания, затем логические. Самый простой вариант: один человек проверяет 50-100 тестовых заданий, затем все материалы собираются в одну стопку и оставшиеся члены команды параллелят проверку логических задач: каждая логическая задача проверяется одним человеком в городе.
Логические задания проверять сложнее, но веселее: студенты шутят, пишут благодарности и надеются что «вы, ребята, проверите что я тут понаписал». Иногда встречаются решения, поражающие своей беспощадностью, типа вычисления «в лоб» задачи Флавеля на 100 человек. Иногда предварительные принципы оценивания не работают — большинство студентов понимает задачу совершенно не так, как планировалось. В таких случаях приходится быстро просматривать десяток решений и придумывать новые критерии оценки.
Для тестового задания мы за несколько лет сформировали документ «мечту дизайнера»: слева фиксируем столбец с именами (выдираем имена из базы регистраций), сверху фиксируем номер задания и максимальные баллы для логического задания, жирными границами разделяем столбцы согласно расположению на листах. Тесты в таком формате проверяются вообще без участия мозга. Для логических заданий проверяющие могут создавать дополнительные колонки.
Экзамен и проверка должны быть максимально быстрыми. У студента есть два временных отрезка в учебном году, когда он свободен — между сессиями. Нужно успеть провести стажировку в эти окна (можно слегка зацепить зимнюю сессию — но не летнюю, ибо выпуск\диплом). Поэтому важно проверить задания и выслать приглашения как можно быстрее. В идеале — 2-3 дня, заранее согласованных с начальством\клиентами — разработчики будут заняты. Часть студентов откажется стажироваться — так что нужно заранее подготовить «второй эшелон». Из практики, 1-2 студента из второго эшелона получат свои приглашения.
Все просто: теория, потом упражнения. Лично я стараюсь разбавлять теорию подходящими кул-сторис хабры. Очень важно выделить как можно больше времени на упражнения. Стажеры часто говорят «у меня все ОК» даже если что-то не работает — и потом не понимают материала. Приходится проверять все и у всех, на что уходит время. Самые частые косяки хранятся в корпоративной вики, пригождаются в следующем году. Инициализация\конфигурация — отдельное зло, у 1-2 стажеров на лекции точно что-нибудь не заработает.
В процессе лекций мы начинаем с фронта и заканчиваем беком — так стажеры видят результаты с самого второго занятия. Первое — маркетинг, Git, основы html\css.
Всегда есть соблазн объять невпихуемое вместо концентрации на ключевых аспектах лекции. Помогает дробление упражнения на максимально мелкие элементы, или 3-4 элемента с нарастающей сложностью — точность планирования возрастает. В конце лекции оставляются ссылки на материалы, в идеале статьи типа «как сделать X используя Y». Обязательны перерывы, минут по 10-15. Обязательны для стажеров, ибо в каждый перерыв половина стажеров уходит, а вторая половина подвергается помощи лектора.
Помимо подготовки контента часть времени уходит на инфраструктуру — готовятся два репозитория: Starter, End. Первый открывается для стажеров до занятия (ReadOnly), в него лектор будет коммитить по ходу лекции. Второй открывается в конце занятия — он будет похож на Starter, только чуть приглажен. Ключевые репозитории стоит делать одинаковыми для всех групп — если у каждого лектора своя версия, заменить одного из них сложнее, особенно на фронте с адом зависимостей. И да, с лекторами регулярно что-то случается: критичный баг на проде у важного клиента, командировка у важного клиента, особо важный релиз у особо важного клиента. В этом плане иметь двух лекторов в соседних городах очень удобно: если одинпопал под автобус заболел, второй подменит.
Можно давать упражнения на дом, их выполнение коррелирует с рекомендацией найма. Уж не знаю, это из-за того что сильные стажеры делают элементарные для них упражнения, или из-за того, что выполнение упражнений делает стажеров сильными.
Ключевой принцип: надо понимать, что ребята в аудитории через пару месяцев будут работать в одной с лектором команде. Не стоит скупиться на объяснения сейчас, это сэкономит время потом.
4 команды по 5 стажеров, под руководством инженера-ментора. Ментор — это нечто среднее между лидом, скрам мастером и менеджером проекта. Задача — сделать проект. Изначально простой, но можно довесить фич при необходимости. Практика показывает, что половина стажеров отвалится: может совсем перестать ходить, может просто не потянуть сложности, нужно быть готовым к расставлению приоритетов. Менторство — это реально новый опыт для разработчика, позволяющий взглянуть на вещи с абсолютно иной точки зрения. Как управлять командой — каждый выбирает сам, я опишу лишь несколько особенностей именно нашего менторства.
Первое, жесткое ограничение по времени. 8 часов в неделю на команду из 5 стажеров. Все спринты, все вопросы, все ритуалы, вся постановка задач — на менторе. После такого понимать мотивацию своего лида гораздо проще.
Второе, зависимость от лекций. В некоторой степени помогает в планировании. Полезно общаться с лектором: узнать о чем он будет говорить, просить осветить подробнее некоторые моменты.
Третье, под конец ментор руководит командой из 3-4 фулл-стек джунов. Важно как можно быстрее привить дисциплину разработки вроде код-ревью и пулл-реквестов, это позволяет держать код хотя бы в минимальном порядке.
Четвертое, ментор живет в месте где фактор автобуса дополняется факторами поезда, самолетаи НЛО. Сегодня у тебя 5 человек в команде, а завтра ВНЕЗАПНО три. Помимо тривиальных болезней случаются подготовки к диплому, смены интересов, осознание съедаемого стажировкой времени. На моей памяти самым эпичным было письмо вроде "Я зарегался и прошел экзамен, но не знал, что вы учите Web-разработке. Вы делаете классные вещи, но я Data Scientist, так что давайте-ка дальше без меня."
Пятое, ментор оценивает стажера каждую неделю. Если с ментором что-то случится — команду сможет подхватить кто-то другой. Приглашение стажера на интервью во многом зависит от рекомендации ментора — так что впечатления менторов должны быть записаны. На одной из встреч передачи опыта один из коллег наблюдал заметки о себе любимом — опыт передавал его бывший ментор.
Проверяет только те темы, которые изучались во время стажировки. Выполняется в офисе, с гуглом, но без мессенджеров. Чисто практические задания: стажер получает доступ к репозиторию, кодит что-то, коммитит.
Стажеры после экзамена сортируются по сумме двух параметров: баллы за экзамен и оценка ментора, после чего начинают получать приглашения на интервью. Интервьюируют студентов коллеги не принимавшие участия в академии. Сейчас мы задумываемся над упрощением системы: ментор говорит «рекомендую\нет», все рекомендованные сортируются по баллам экзамена.
Отдых. Анализ лекций, ретро, анализ данных, обновление документации, подготовка следующего семестра — и тимбилдинги с нанятыми разработчиками.
Обычный стажер-разработчик — студент 2-4 курса, IT, математика; стажируется параллельно учебе в Вильнюсе или Каунасе. Начинает стажировку 40 человек, заканчивает 30-35, 10 нанимается джунами.
10 человек — это не просто красивое число. Для нанятого джуна нужен хотя бы один сеньор\лид, имеющий свободное время и проект, куда стажера можно безболезненно ввести и загрузить, где он получит экспу и принесет пользу (и пройдет клиентскую проверку безопасности). Плюс, нет резона вешать джуна на сеньора, который не горит желанием быть наставником. Плюс, джависты не горят желанием нанимать .NET стажеров.
Первый взгляд?
10 джунов рождаются полгода, командой из 13 человек.
После вступительного экзамена в каждом городе выбираются 20 кандидатов, из них формируются 4 команды, каждая из которых под руководством ментора 3 месяца пилит учебный проект. Параллельно все студенты слушают набор лекций, раз в неделю: фронт, бек, лучшие практики, тестирование. Затем еще один экзамен (выпускной), череда интервью — и новые сотрудники вливаются в коллектив.
В принципе, ничего сложного, но возможностей косякнуть — уйма.
Набираем команду
Проблемы начинаются уже при выборе менторов\лекторов. Нельзя просто прийти к лиду и сказать: мы у тебя забираем 6 человек, они будут тратить порядка дня в неделю на стажеров. Нельзя прийти к разработчику и сказать: ты будешь вести лекции — нужны добровольцы. Нужно подумать о командировках и отпусках (читай, никаких стажировок летом). Что радует, нет проблем с мотивацией: деньги, новый опыт, тренировка тим-лидства — этого хватает. Когда выбраны 2 лектора (фронт+бек) и 4 ментора в каждом городе — начинается притирка, называемая «подготовка вступительного экзамена».
Готовим вступительный экзамен
Вы же знаете, как проводить интервью? Вступительный экзамен ненамного сложнее. Проблемы начинаются при подготовке вопросов. Например, в Каунасе любят ООП, я бы предпочел выкинуть его из экзамена (и убедил в этом Вильнюс). EntityFramework vs Dapper, SQL vs JS, hardcore vs trivia — 4 Святых Войны отгремели, сейчас я морально готовлюсь к пятой. Что радует — войны локальные, и люди реально стараются подбирать аргументы. Что печалит — аргументация занимает время, которое деньги. Для сохранения времени выработался стандарт подготовки тестовых заданий.
Сначала каждый пишет 5-10 заданий, по 1-2 на каждую тему. Затем каждая команда локально собирается и обсуждает все задания. По каждому ставится резолюция: годно, сгодится после доработки (список действий), шлак (список_причин). Если задача одобрена обоими городами: она попадает в
С логической частью все еще проще: каждый выбирает 3 задачи которые хотел бы увидеть в экзамене, задачи с наибольшим числом голосов заносятся в финальный список. В прошедший год было 4 задачи на три места, быстро провели дополнительное голосование. Почему быстро? Потому что принципиальной разницы между лучшими заданиями нет.
После экзамена проводится ревью: какие задания решались больше, какие меньше, какие темы оказались самыми сложными, ищутся корреляции «решение задачи — приглашение на стажировку». Подобный анализ позволят нащупать оптимальную сложность для заданий и убедить коллег отказаться от некоторых задач (пускай лишь в следующем году). Собственно, именно так задачи на теорию ООП частично заменились на «реализацию ООП в C#».
После подготовки финального списка задач начинается наведения глянца. Текст форматируется, задачи решаются коллегами на предмет поиска неточностей, задачи проверяются в IDE, ищутся совпадения с предыдущими годами. В последнем семестре мы глянец не наводили — и 5 тестовых заданий из 35 оказались некорректными.
Из интересного: как вы думаете, какие глифы выбрать для ответов на тестовые задания, 1-2-3-4 или a-b-c-d?
1-2-3-4. При проверке экономит время, ибо клавиши расположены чуть удобнее.
Медиа
Параллельно с подготовкой экзамена идет реклама стажировки. Фейсбук, газеты, собственный сайт — всего около 10 каналов и 30 активностей. За это отвечают HR и маркетинг.
Отдельный момент — регистрация. Кто-то регистрируется дважды, кто-то это делает в последний момент. Некоторые приходят вообще без регистрации. Число студентов важно: оно определяет количество распечатываемых заданий. Эмпирическая формула: на экзамене будут 80% от зарегистрированных участников.
За день-два до экзамена шлется напоминание, FAQ, правила экзамена. Напоминание важно: отдельные товарищи регистрируются за несколько месяцев до экзамена, и вполне могут забыть про него.
Вступительный экзамен
Университет, одна-две поточки, стопка заданий, 4 человека от компании. Это в каждом городе. С университетом надо договориться заранее, обязательно указать ожидаемое количество студентов, время прибытия принимающей группы, время отбытия группы, кто выдаст ключи, кто их заберет. Особенно важно «кто заберет» — экзамен завершается вечером. Прибыть нужно за полчаса до экзамена: проверить аудитории, аппаратуру, встретить студентов, поотвечать на вопросы, вывести FAQ на доску, если есть проектор, выложить на стол ручки и чистые листы. Важно понимать: сотрудники университета вам будут помогать лишь по доброй воле, так что лучше все проверить в офисе. Кроме того, испортив отношение сегодня — не получишь аудиторию в следующем семестре. Стоит подумать о земном — подготовить воду попить (для себя, студенты могут принести с собой, о чем написано в правилах), выяснить где поблизости туалет.
В начале экзамена повторяем правила, раздаем задания, стартуем. Начинается скука. Народ решает, экзаменаторам делать особо нечего. Студенты не читерят, либо читерят незаметно. Тут важно найти занятие наблюдателям, и таковых немного. Первое — проверка того, что студент написал свое имя разборчиво, это реально важно при проверке экзамена. Второе — сбор отзывов об экзамене. Студент выходит — и наблюдатель задает ему вопрос «что вам НЕ понравилось больше всего?». Именно в такой форме. Спросишь что было лучше всего — ничего интересного не услышишь. Фидбек собирают все наблюдатели по очереди. Один собрал порцию — пошел записывать, следующий заступает на пост.
После экзамена все материалы собираются, свет выключается, двери закрываются, ключ сдается. Начинается нудное: проверка.
Проверка вступительного экзамена
Для проверки мы заранее готовим лист в гугло-доках и согласуем параллелизм. Сначала проверяются тестовые задания, затем логические. Самый простой вариант: один человек проверяет 50-100 тестовых заданий, затем все материалы собираются в одну стопку и оставшиеся члены команды параллелят проверку логических задач: каждая логическая задача проверяется одним человеком в городе.
Логические задания проверять сложнее, но веселее: студенты шутят, пишут благодарности и надеются что «вы, ребята, проверите что я тут понаписал». Иногда встречаются решения, поражающие своей беспощадностью, типа вычисления «в лоб» задачи Флавеля на 100 человек. Иногда предварительные принципы оценивания не работают — большинство студентов понимает задачу совершенно не так, как планировалось. В таких случаях приходится быстро просматривать десяток решений и придумывать новые критерии оценки.
Для тестового задания мы за несколько лет сформировали документ «мечту дизайнера»: слева фиксируем столбец с именами (выдираем имена из базы регистраций), сверху фиксируем номер задания и максимальные баллы для логического задания, жирными границами разделяем столбцы согласно расположению на листах. Тесты в таком формате проверяются вообще без участия мозга. Для логических заданий проверяющие могут создавать дополнительные колонки.
Экзамен и проверка должны быть максимально быстрыми. У студента есть два временных отрезка в учебном году, когда он свободен — между сессиями. Нужно успеть провести стажировку в эти окна (можно слегка зацепить зимнюю сессию — но не летнюю, ибо выпуск\диплом). Поэтому важно проверить задания и выслать приглашения как можно быстрее. В идеале — 2-3 дня, заранее согласованных с начальством\клиентами — разработчики будут заняты. Часть студентов откажется стажироваться — так что нужно заранее подготовить «второй эшелон». Из практики, 1-2 студента из второго эшелона получат свои приглашения.
Из забавного
При регистрации студент заполняет несколько полей, в том числе «О себе». Позже они попадают в проверочный документ, где высвечиваются вещи вроде "About me: ';DROP TABLE ENTRIES; --I hope that did not work."
Мораль: будьте готовы, что вас тоже потестируют.
Мораль: будьте готовы, что вас тоже потестируют.
Лекции
Все просто: теория, потом упражнения. Лично я стараюсь разбавлять теорию подходящими кул-стори
В процессе лекций мы начинаем с фронта и заканчиваем беком — так стажеры видят результаты с самого второго занятия. Первое — маркетинг, Git, основы html\css.
Всегда есть соблазн объять невпихуемое вместо концентрации на ключевых аспектах лекции. Помогает дробление упражнения на максимально мелкие элементы, или 3-4 элемента с нарастающей сложностью — точность планирования возрастает. В конце лекции оставляются ссылки на материалы, в идеале статьи типа «как сделать X используя Y». Обязательны перерывы, минут по 10-15. Обязательны для стажеров, ибо в каждый перерыв половина стажеров уходит, а вторая половина подвергается помощи лектора.
Помимо подготовки контента часть времени уходит на инфраструктуру — готовятся два репозитория: Starter, End. Первый открывается для стажеров до занятия (ReadOnly), в него лектор будет коммитить по ходу лекции. Второй открывается в конце занятия — он будет похож на Starter, только чуть приглажен. Ключевые репозитории стоит делать одинаковыми для всех групп — если у каждого лектора своя версия, заменить одного из них сложнее, особенно на фронте с адом зависимостей. И да, с лекторами регулярно что-то случается: критичный баг на проде у важного клиента, командировка у важного клиента, особо важный релиз у особо важного клиента. В этом плане иметь двух лекторов в соседних городах очень удобно: если один
Можно давать упражнения на дом, их выполнение коррелирует с рекомендацией найма. Уж не знаю, это из-за того что сильные стажеры делают элементарные для них упражнения, или из-за того, что выполнение упражнений делает стажеров сильными.
Ключевой принцип: надо понимать, что ребята в аудитории через пару месяцев будут работать в одной с лектором команде. Не стоит скупиться на объяснения сейчас, это сэкономит время потом.
Менторство
4 команды по 5 стажеров, под руководством инженера-ментора. Ментор — это нечто среднее между лидом, скрам мастером и менеджером проекта. Задача — сделать проект. Изначально простой, но можно довесить фич при необходимости. Практика показывает, что половина стажеров отвалится: может совсем перестать ходить, может просто не потянуть сложности, нужно быть готовым к расставлению приоритетов. Менторство — это реально новый опыт для разработчика, позволяющий взглянуть на вещи с абсолютно иной точки зрения. Как управлять командой — каждый выбирает сам, я опишу лишь несколько особенностей именно нашего менторства.
Первое, жесткое ограничение по времени. 8 часов в неделю на команду из 5 стажеров. Все спринты, все вопросы, все ритуалы, вся постановка задач — на менторе. После такого понимать мотивацию своего лида гораздо проще.
Второе, зависимость от лекций. В некоторой степени помогает в планировании. Полезно общаться с лектором: узнать о чем он будет говорить, просить осветить подробнее некоторые моменты.
Третье, под конец ментор руководит командой из 3-4 фулл-стек джунов. Важно как можно быстрее привить дисциплину разработки вроде код-ревью и пулл-реквестов, это позволяет держать код хотя бы в минимальном порядке.
Четвертое, ментор живет в месте где фактор автобуса дополняется факторами поезда, самолета
Пятое, ментор оценивает стажера каждую неделю. Если с ментором что-то случится — команду сможет подхватить кто-то другой. Приглашение стажера на интервью во многом зависит от рекомендации ментора — так что впечатления менторов должны быть записаны. На одной из встреч передачи опыта один из коллег наблюдал заметки о себе любимом — опыт передавал его бывший ментор.
Выпускной экзамен
Проверяет только те темы, которые изучались во время стажировки. Выполняется в офисе, с гуглом, но без мессенджеров. Чисто практические задания: стажер получает доступ к репозиторию, кодит что-то, коммитит.
Стажеры после экзамена сортируются по сумме двух параметров: баллы за экзамен и оценка ментора, после чего начинают получать приглашения на интервью. Интервьюируют студентов коллеги не принимавшие участия в академии. Сейчас мы задумываемся над упрощением системы: ментор говорит «рекомендую\нет», все рекомендованные сортируются по баллам экзамена.
