company_banner

Стажировка в IT: взгляд руководителя



    Набор на летнюю стажировку в Яндекс продолжается. Он идёт по пяти направлениям: бэкенд, ML, мобильная разработка, фронтенд и аналитика. В этом блоге, в других блогах на Хабре и за его пределами можно найти немало инсайда про то, как проходит стажировка. Но многое в этом процессе остаётся загадкой для тех, кто не работает в компании. А если посмотреть с точки зрения руководителей разработки, то возникает ещё больше вопросов. Как правильно проводить стажировку, как максимизировать взаимную полезность со стажёром, как успеть узнать его за три месяца и обучить всему, что требуется для продолжения работы?

    Мы подготовили эту статью впятером. Представимся: Игнат Колесниченко из службы технологий распределённых вычислений, Миша Левин из службы машинного интеллекта Маркета, Денис Малых из службы разработки приложений, Серёжа Бережной из отдела разработки поисковых интерфейсов и Дима Черкасов из группы разработки антифрода. Каждый из нас представляет своё направление стажировки. Мы все руководители, нам нужны стажёры, и у нас есть некоторый опыт работы с ними. Давайте мы расскажем кое-что из этого опыта.

    Собеседование перед стажировкой


    Кандидатов ждёт несколько технических собеседований. Успех на собеседовании зависит в меньшей степени от soft skills (способности эффективно коммуницировать) и в большей — от hard skills (навыков в математике и программировании). Однако руководители оценивают и то и другое.
    Игнат:
    Даже если человек очень крутой, но абсолютно некоммуникабельный — он не сможет все навыки приложить. На это, конечно, обращаем внимание, но это не повод не взять кого-то на стажировку. За три месяца всё может поменяться, а кроме того, твоё первое впечатление может оказаться неверным. А если всё верно — надо будет человеку объяснить, поискать ему другие команды. Для стажёров коммуникабельность точно не является ключевым фактором. Всё-таки профессиональные навыки гораздо важнее.
    Денис:
    Мне нравятся люди, которые рассказывают байки — в хорошем смысле. Человек, который может рассказать, как они с командой героически справились с каким-нибудь факапом, интересен. Я начинаю задавать дополнительные вопросы, когда такая история всплывает. Но это редко происходит, если просто попросить «рассказать о чём-нибудь интересном в твоих проектах».

    Один кандидат однажды произнёс замечательную фразу, которую я даже записал: «Успешно избегал решения нудных задач».



    Поскольку времени на общение мало, собеседующий каждую минуту встречи старается получить полезную информацию о кандидате. Здорово, если стажёр заранее прикинул, какими деталями своего опыта (не из резюме) он мог бы поделиться. Это должен быть короткий рассказ строго по делу.
    Денис:
    Я обращаю внимание, если человек рассказывает, что попробовал много языков, подходов. Люди с более широким кругозором придумывают в боевом режиме более элегантные решения. Но это неоднозначный плюс. Можно похватать по верхам, а всерьёз ничему не научиться.

    Время на истории, описываемые Денисом, обычно остаётся только на финальном собеседовании. До тех пор нужно продемонстрировать те фундаментальные и практические знания, которые лягут в основу будущей работы. И, конечно, потребуется писать код на доске или на листе бумаги.
    Миша:
    Мы проверяем знание теории вероятности и математической статистики. Смотрим, есть ли у человека опыт работы с метриками, с алгоритмами машинного обучения, с настройкой их параметров, с переобучением и т. д. Мы ожидаем, что человек может писать код в достаточной степени для того, чтобы быть аналитиком.
    Денис:
    Те, кто приходит на собеседование, в основном знают языки: у нас в Екатеринбурге хорошая школа основных языков, хорошие институты. Но если честно, кандидат на стажировку с хорошими hard skills — редкий случай, по крайней мере в нашей эпсилон-окрестности. Вот к примеру, Swift. В нём очень сложная работа со строками, и людей, которые навскидку из головы могут с ними поработать, мало. За таких сразу цепляется глаз. Я часто даю на собеседованиях задачу, которая как раз связана с обработкой строк. И за всё время был только один человек, который сходу, на листочке, смог такой Swift-код написать. Я после этого ходил и всем рассказывал, что кто-то наконец смог решить эту задачу на Swift на листочке.

    Проверка алгоритмов на собеседовании


    Это отдельная тема, поскольку у кандидатов по-прежнему возникает вопрос — почему мы всегда оцениваем знание алгоритмов и структур данных? Даже будущие мобильные разработчики и фронтендеры проходят такую проверку.
    Миша:
    На собеседовании обязательно даём какую-нибудь алгоритмическую задачку. Кандидату надо придумать, как её реализовать на Python, желательно без ошибок. Нужно понять, как проверять свою программу и самостоятельно её исправлять.



    Опыт в алгоритмах пригодится сразу по трём причинам. Во-первых, он, очевидно, потребуется в алгоритмических задачах — которые бывают нечасто, но всё-таки бывают. Во-вторых, разработчик сможет эффективнее решать задачи, относящиеся к алгоритмам, пусть и не требующие залезать в сами алгоритмы (а таких уже довольно много). В-третьих, если вам не преподавали алгоритмы в вузе, а вы всё-таки умеете с ними работать, то это характеризует вас как любознательного человека и поднимет ваш авторитет в глазах собеседующего.
    Денис:
    Большая часть мобильной разработки — это «перекладывание JSON». Но раз в полгода бывают случаи, когда алгоритмы нужны. Я сейчас рисую красивые карты для Яндекс.Погоды. И мне за неделю пришлось реализовать алгоритм сглаживания, алгоритм Сазерленда-Ходгмана и алгоритм Мартинеса. Если бы человек не знал, что такое хэшмап или очередь по приоритетам, он бы засел с этим надолго и непонятно, справился бы или нет без посторонней помощи.

    Алгоритмы — основа разработки. Это то, что помогает разработчику быть разработчиком. Неважно, чем вы занимаетесь. Они нужны и в несложных проектах, где основная работа состоит из «перекладывания JSON». Даже если вы не пишете сами алгоритмы, но неявно используете какие-нибудь структуры данных, то лучше их понимать. Иначе у вас будут получаться приложения, которые медленно или некорректно работают.

    Есть программисты, которые в разработку пришли академически: поступили в универ, честно отучились пять лет, получили специальность. Они знают алгоритмы, поскольку их научили. И тогда само знание алгоритмов никак не характеризует кругозор человека, надо этот кругозор проверять другим способом.

    А есть самоучки, к которым я причисляю и себя. Да, формально у меня есть IT-образование, диплом инженера-программиста. Но самоучки программировать научились «вопреки». У них не было университетской программы. Обычно они с алгоритмами не знакомы — потому что никогда не сталкивались с необходимостью их изучить. И когда такой человек понимает алгоритмы, это значит, что он потратил время и в них разобрался. Закончив универ, я понял, что у меня есть белые пятна в части фундаментальных алгоритмов — дело в том, что специальность была прикладная. Я пошёл и изучил онлайн-курсы Принстонского университета, хорошо известного Роберта Седжвика. Разобрался, сделал все домашки. И когда человек на собеседовании рассказывает похожую историю, мне сразу становится интересно, появляется желание с ним поработать или хотя бы продолжить разговор.


    Игнат:
    Когда собеседуешь стажёра, в некотором смысле ожидаешь даже больше, чем от опытного разработчика. Речь идёт про умение решать алгоритмические задачи, быстро писать хоть какой-то корректный код. Кандидат на стажировку — он ведь ещё в университете. Буквально год назад ему всё про алгоритмы рассказывали в деталях. Ожидается, что он их может воспроизвести. Если человек адекватный и слушал лекции внимательно, он просто будет всё знать, доставать из кэша.

    Какие задачи решает стажёр


    Обычно программу стажировки можно наметить и обсудить на финальных собеседованиях. Стажёру только в самом начале работы могут достаться тренировочные задачи, результат которых не будет задействован в продакшене. Более того — вероятность получить такие задачи невелика. Чаще всего даются боевые проекты из бэклога, то есть признанные достойными внимания, но не приоритетные и «отделимые» — чтобы от их реализации не зависели другие компоненты. Руководители стараются распределять их так, чтобы стажёр познакомился с разными частями сервиса, работал в одном окружении с другими участниками команды.
    Игнат:
    Это крайне полезные задачи. Возможно, они не увеличат утилизацию кластера на 10%, не сэкономят миллион долларов компании, но сделают счастливыми сотни людей. Например, у нас сейчас есть стажёр, который занимается нашим клиентом для запуска операций на наших кластерах. Перед запуском операция должна загрузить некие данные на кластер. Обычно это занимает 20–40 секунд, и раньше это происходило молча: запустил её в консоли и сидишь, смотришь в чёрный экран. Стажёр пришёл и за две недели сделал фичу: теперь видно, как файлы заливаются и что происходит. Задача, с одной стороны, несложная в описании, а с другой — есть в чём покопаться, какие библиотеки посмотреть. Самое приятное — что ты это сделал, прошла неделя, это оказалось на кластерах, люди уже этим пользуются. Пишешь пост во внутреннюю сеть — тебе говорят спасибо.


    Миша:
    Стажеры готовят модели, собирают для них данные, придумывают метрики и проводят эксперименты. Постепенно мы просто начинаем давать ему больше свободы и ответственности — проверяем, справляется ли он. Если да — он переходит на следующий уровень. Мы не предполагаем, что когда стажер приходит, он все это умеет. Руководитель помогает ему разобраться, даёт ссылку на внутренний ресурс или онлайн-курс.

    Если стажёр показывает себя на высоте — ему могут дать нечто приоритетное, важное для отдела или других сервисов.
    Дима:
    Наш стажёр сейчас занимается хардкорными доработками антифрода. Это система, которая борется с самым разным абьюзом и мошенничеством на сервисах Яндекса. Сначала думали давать не очень сложные и не очень важные для продакшена вещи. Мы заранее стараемся продумать задачи стажёра, но тут увидели, что человек «жжёт», быстро и хорошо решает задачи. В итоге мы стали поручать ему запуск антифрода для новых сервисов.

    Кроме того, существует небольшой шанс получить задачу, к которой коллеги раньше не подступались из-за её объёма.
    Дима:
    Есть одна старая система, а есть новая, ещё не доделанная. Нужно провести переезд с одной на другую. В перспективе это важный проект, хотя с высокой неопределённостью: нужно много общаться, читать непонятный легаси-код. Мы на финальном собеседовании по-честному сказали стажёру, что задача сложная. Он ответил, что готов, пришёл к нам в команду, и у него всё получилось. Оказалось, что у него есть качества не только разработчика, но и менеджера. Он готов был сам ходить, узнавать, пинговать.

    Менторство над стажёром


    Стажёру для погружения в процессы нужен ментор. Это человек, который находится в курсе не только своих задач, но и задач стажёра. С ментором налажено регулярное общение, к нему всегда можно обратиться за советом. Ментором может выступать либо руководитель группы (если это небольшая группа), либо кто-то из коллег, постоянных участников команды.
    Игнат:
    Я стараюсь хотя бы через день подходить, спрашивать, как у стажёра дела. Если вижу, что закопался, то стараюсь ему помочь, спросить, в чём проблема, и вместе с ним её раскопать. Ясно, что это отнимает мои силы и делает работу стажёра не столь эффективной интегрально — я же тоже своё время трачу. Зато это позволяет ему ни в чём не закопаться, получить результат. И всё равно это быстрее, чем если бы я это делал сам. Самому мне нужно на задачу условные 5 часов. Стажёр её сделает за 5 дней. И да, я потрачу 2 часа в течение этих 5 дней на то, чтобы пообщаться со стажёром и помочь. Но хотя бы 3 часа я сэкономлю, и стажёру будет приятно, что ему подсказали, помогли. В целом, надо просто плотно общаться, смотреть, что человек делает, не терять контакт.


    Серёжа:
    Стажёр постоянно находится на связи со своим ментором и общается с ним по несколько раз в день. Ментор ревьюит код, занимается парным программированием со стажёром, помогает, когда возникают какие-то проблемные места. Именно таким способом, сочетанием помощи ментора и реальных боевых задач, мы обучаем фронтендеров.
    Дима:
    Чтобы стажёр не оказывался брошенным, мы ещё до найма обсуждаем, кто его будет менторить. Это ещё и большая прокачка для самого ментора: подготовка к роли тимлида, проверка на способность удержать в голове и свою задачу, и задачу стажёра. Есть регулярные встречи, на которые иногда хожу и я сам, чтобы быть в курсе. Но совсем регулярно со стажёром общается именно ментор. Он поначалу тратит очень много времени, но это окупается.

    Однако наличие ментора не означает, что все возникающие вопросы решаются через него.
    Миша:
    У нас принято, что столкнувшиеся с проблемой люди спрашивают совета у соседей, коллег и быстро находят помощь. Чем быстрее человек растёт, тем чаще ему нужно пойти к коллегам узнать что-то. Полезно даже просто узнавать о задачах других людей, чтобы придумать новые задачи. Когда стажёр сам в состоянии договориться, понять, что важно другой стороне, и прийти к результату в команде, он гораздо быстрее вырастет, чем тот, за которого все это должен делать руководитель.
    Серёжа:
    Есть документация, но бо́льшая часть информации растворена в воздухе. Если ты впитываешь её на старте карьеры, это дополнительное преимущество, а мы можем сфокусировать человека на том, что нужно изучить.

    Идеальный стажёр — это тот, кто стажируется несколько месяцев, становится младшим разработчиком, потом просто разработчиком, потом руководителем группы и т. д. Для этого нужен архетип ученика, который не стесняется спросить, если ему что-то непонятно, но при этом способен на самостоятельную работу. Если ему сказали, что про это можно прочитать там-то, он пойдёт, прочитает и действительно вернётся с новыми знаниями. Он может ошибаться, но он не должен ошибаться больше одного, максимум двух раз в одном и том же месте. Идеальный стажёр должен развиваться, впитывать всё как губка, учиться и расти. Тот, кто сидит, пытается во всем разобраться сам, долго ковыряется, не задает никаких вопросов, вряд ли приживётся.

    Окончание стажировки


    Перед началом работы мы подписываем с каждым стажёром срочный договор. Разумеется, стажировка оплачивается, оформляется по ТК РФ, и у стажёра появляются те же преимущества, что и у любого другого сотрудника Яндекса. Спустя три месяца программа завершается — многих стажёров мы затем переводим в штат (на бессрочный договор).



    С одной стороны, руководителю важно, чтобы разработчик выполнил свой стажёрский минимум. Именно к этому ведёт стажёра, начиная с собеседования. Однако это только начало истории. Стажёр для нас всегда является потенциальным кандидатом в штат. Программа-минимум для руководителя — ещё в самом начале разглядеть такого человека, которого после трёх месяцев будет не стыдно порекомендовать в другие отделы. Программа-максимум — сохранить его в той же команде, взяв в штат. При этом мы учитываем, что студенту второго или третьего курса — даже если он стал стажёром — с наступлением учебного года потребуется продолжить обучение в вузе.
    Серёжа:
    В первую очередь стажёры для нас — кадровый потенциал. Мы пытаемся вырастить людей внутри Яндекса, чтобы они идеально подходили к нашим задачам. Мы даем им всё, начиная с культуры общения и взаимодействия в командах до энциклопедических знаний про все наши системы.
    Игнат:
    Беря стажёра, мы сразу примеряем его к тому, чтобы он попал к нам в команду. И как правило, единственное препятствие — отсутствие вакансии. Стажёрами стараемся брать достаточно молодых ребят. Если у человека пять лет опыта разработки, он приходит в Яндекс и по уровню он стажёр, то увы, для нас это означает, что он — хоть и будучи молодцом, раз устраивается в Яндекс с пятью годами опыта, — до старшего разработчика вырасти не сможет. Обычно дело в скорости: медленный рост в прошлом будет означать медленный рост и у нас. Да, иногда понимание, что человек не тянет, приходит только по итогам трёх месяцев. Но это достаточно редко. Больше чем в половине случаев мы готовы брать людей в штат. На моей памяти не было такого, что человек успешно постажировался, но не смог пройти собеседования на штатную позицию.
    Миша:
    Всем успешным стажёрам мы предлагаем остаться в компании. После стажировки мы, как правило, берём на фултайм больше половины. С летней стажировкой сложнее, потому что часто к нам приходят студенты, например, третьего курса и им тяжело совмещать работу с учёбой.
    Дима:
    Предположим, стажёр отлично справляется с задачами и имеет массу перспектив вырасти в хорошего разработчика — пусть даже у него сейчас недостаточно опыта. И предположим, вакансии на бессрочный договор нет. Тогда всё просто: мне нужно идти к своему руководителю и говорить ему — вот очень крутой человек, его надо всеми силами оставлять, давайте предложим ему что-нибудь, найдём, куда его пристроить.

    Истории о стажёрах

    Денис:
    Девушка, которая к нам устроилась на стажировку в 2017 году, была родом из Перми. Это километров 400 от Екатеринбурга на запад. И она каждую неделю приезжала к нам из Перми на поезде в Школу мобильной разработки. Днём приезжала, вечером училась и поздним вечером уезжала обратно. Оценив такое рвение, мы её позвали работать, и это себя оправдало.
    Игнат:
    Несколько лет назад мы участвовали в программе обмена стажёрами. Поработать с иностранными ребятами было интересно. Но стажёры оттуда не сильнее, чем, например, из ШАДа или с ФКНа. Казалось бы, EPFL находится в топ-20 вузов Европы. У меня в тот момент — как ещё у не очень опытного собеседующего — было такое ожидание: невероятно, мы собеседуем людей из EPFL, они будут супер-крутые. Но люди, которые получили базовое образование про кодинг у нас — в том числе в ключевых региональных вузах, — оказываются вполне на уровне.

    Или другая история. Сейчас у меня в штате парень, молодой совсем, около 20 лет. Работает в Питере, приезжал на стажировку. Он очень крутой. Ты, как обычно, даёшь человеку задачи, он их решает, а через месяц приходит и говорит: я порешал, смотрю, и, кажется, у вас архитектура плохо построена. Давай переделаем. Код станет проще, понятней. Я его, конечно, отговорил: объём работ большой, профита для пользователей нет, но идея звучит абсолютно разумно. Человек разобрался в сложном многопоточном процессе и предложил улучшения — может, и несвоевременные, рефакторинг ради рефакторинга. Но как только захочется этот код усложнить, можно будет этот рефакторинг всё-таки сделать. По факту прошло несколько месяцев, и мы занялись этой задачей. Я с удовольствием взял его в штат. Мы все не гении. Можно прийти, разобраться в чём-то и указать нам на наши проблемы. Это ценится.
    Миша:
    У нас бывают такие идеальные стажёры. Несмотря на отсутствие опыта, они видят задачу не только на техническом, но и на глобальном уровне. Предлагают принципиальные улучшения. У них есть понимание того, как перевести задачи из реального мира в технический, не потеряв смысла. Они задумываются, в чём итоговая цель, стоит ли сейчас закапываться в детали или можно полностью изменить подход к задаче или даже постановку задачи. Значит, у них есть задел на то, чтобы оказаться на несколько уровней выше. Чтобы пройти этот путь, им просто нужно прокачать какие-то скиллы и внутренние инструменты. Плюс запустить несколько успешных проектов.

    • +25
    • 8,6k
    • 5
    Яндекс
    407,00
    Как мы делаем Яндекс
    Поделиться публикацией

    Комментарии 5

      +2
      Я сейчас рисую красивые карты для Яндекс.Погоды. И мне за неделю пришлось реализовать алгоритм сглаживания, алгоритм Сазерленда-Ходгмана и алгоритм Мартинеса. Если бы человек не знал, что такое хэшмап или очередь по приоритетам, он бы засел с этим надолго и непонятно, справился бы или нет без посторонней помощи.

      1) blog.kislenko.net/show.php?id=2057
      2) github.com/w8r/martinez
      3) paperjs.org/examples/path-simplification
      4) synset.com/ai/ru/data/Queue.html
      Не совсем с этим согласен, знать алгоритмы и структуры круто, самая важный скилл по мне это умение правильно выбрать структуру данных, но помнить реализацию(тем более те которые не юзаешь 24/7), необязательно как по мне. Если ты пишешь в условиях без интернета и полной изоляции то окей, но мне любое обсуждение интересных задач, с выше стоящим с коллегой, даже в условии помощи это всегда хорошо, всегда лучше чтобы решение видели несколько человек, а не один.
        +1
        Умение нагуглить алгоритмы и структуры данных, когда у тебя уже имеются их названия — это, в принципе, не самый крутой скилл. Опытный программист, конечно, сможет вбить правильный запрос, чтобы наткнуться на вышеперечисленное, но у джуна/стажера как правило бывают еще проблемы с формулировкой своей задачи для поисковика, и в такой ситуации гораздо выгоднее, если у него есть знания о том, что скорее подойдет. Притом знание реализации, возможно, не нужно, но про это и не сказали же. А с учетом того, сколько Яндекс и Контур тратят усилий на обучение студентов в Екб, с них и спрос другой, пусть вообще квантовые алгоритмы из головы достают!
          0

          Пост был не об этом, я к тому, что алгоритмы не показатель ума, а лишь показатель того что человек знает алгоритмы. Так тяжело очень сказать, смотря как задачи строят, я уверен что автор поста тоже не знал эти алгоритмы, а просто провел research.

            0
            алгоритмы не показатель ума, а лишь показатель того что человек знает алгоритмы

            Мне кажется, это достаточно странная риторика. Вам часто доводится встречать глупых людей, которые знают алгоритмы? Или под «показателем ума» вы имеете в виду нечто специфичное, что не связано с алгоритмами?
            Также интересно, откуда вы знаете, какие алгоритмы автор знал, а какие не знал? Что вообще значит «знать алгоритмы»? Вот например меня сейчас запри в комнате и заставь написать волновой алгоритм, я вряд ли это сделаю без ошибок. Но про его сложность ответить смогу, когда применить — тоже в курсе. Я знаю волновой алгоритм или нет?
              0
              Знаешь конечно, я как раз об этом.

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое