Хакнули систему: как мы изменили подбор и адаптацию разработчиков

    На прошлой неделе наши коллеги — Евгений Шишкин, менеджер разработки, и Лидия Самкова, руководитель отдела по работе с IT–персоналом, выступали на HR API. Делимся конспектом их доклада о процессах подбора и адаптации разработчиков в Контуре.


    За последние три года разработчиков в Контуре стало в два раза больше. К концу 2018 года их число перевалит за 1000. У компании появляются новые продукты, а значит, растет и количество команд — сейчас их больше 50. На фоне активного роста наши процессы подбора и адаптации перестали работать.


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



    Кадр из фильма «Гарри Поттер и философский камень»



    Как было раньше?


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


    На собеседовании, которое длилось 1,5–2 часа, пытались выяснить, насколько кандидат соответствует техническим требованиям и ожиданиям по софт-скилам. Если кандидат не подходил, планировалось еще одно такое же собеседование со следующими командами в рейтинге. И так по кругу, пока мы не находили подходящую команду.


    После этого проходило командное собеседование–знакомство и финальное собеседование с руководителем управления. Адаптацию новичок проходил в команде, куда его приняли.


    Проблемы такого подбора


    • Cерьезный дискомфорт для кандидатов, которым нередко приходилось пройти через 5–8 собеседований. В одном собеседовании участвовало от 6 до 10 человек.
    • Процесс подбора затягивался на месяцы, мы теряли интересных людей.
    • Составление рейтинга команд было непрозрачным. Команды не могли повлиять на место в рейтинге, некоторые ждали кандидатов годами.

    Для кандидатов такая схема тоже выглядела уныло. Получается, у нас было несколько десятков команд с открытыми вакансиями, но выбора у кандидата не было. Новичок составлял представление обо всей компании на основе опыта работы в одной команде, которую мы ему предложили. И если ожидания и реальность не совпадали, то мотивация падала, и он мог уйти (35% всех уходов приходилось на тех, кто не проработал и года).
     
    У старой схемы не было единого подхода к адаптации. Каждая команда тратила время на обучение новичка общеконтуровским практикам, инструментам и решениям. Адаптация везде проходила по-своему, а где-то ее не было вовсе. Это тоже причина серьезных потерь.


    Что мы изменили?


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


    Гильдия проводит технические собеседования, где кандидат проходит 3 обязательных секции: показывает свои практические навыки в написании кода, знание алгоритмов и структур данных, паттернов проектирования. Еще есть дополнительная секция для опытных разработчиков, где мы проверяем технологический кругозор кандидата.


    Если с технической стороны все хорошо, проводим финальное собеседование, и в случае взаимной симпатии и успешных договоренностей принимаем человека на работу. А дальше новичок попадает на 3 месяца в буткамп, где происходят:


    • адаптация,
    • общее погружение в контекст компании и процессов разработки,
    • обучение в рамках крэш-курса,
    • стажировка в нескольких командах.

    И только после этого уже сформировавшийся контуровец выбирает команду, где он хочет работать.


    Выбор команды стал осознанным предпочтением кандидата. При этом мы даем возможность командам влиять на процесс выбора: рассказать о себе, проекте, задачах, процессах и технологиях.


    Буткамп


    В качестве прообраза взяли решение с одноименным названием «буткамп» от Фэйсбука.




    Сейчас структура буткампа выглядит так:


    • Общее погружение и знакомство с компанией (1–3 день),
    • Обучение: креш–курс и знакомство с командами (4–10 день),
    • Стажировки и выбор команды (3–12 неделя).

    Первые три дня буткампа обязательны для всех, они здорово помогают сформировать общий контекст. Дальше есть некоторая гибкость, кто-то проходит через обучение на крэш–курсе и через стажировки, а кто-то попадает сразу в команды.


    Одна из самых важных частей первых дней — это рассказ, на что следует обращать внимание при выборе команды, и об инструментах, которые помогают сориентироваться в нашем многообразии команд. Основной инструмент — классификатор команд.



    Буткамперы видят все команды, в которых есть открытые вакансии. Могут фильтровать список команд по технологиям, платформам, городам и востребованным ролям.


    Креш–курс


    Креш–курс позволяет на выходе выровнять общий технический уровень сотрудников, выработать у них представление о том, как принято в компании писать код, какие практики и технологии мы используем.


    Буткамперы знакомятся с нашей инфраструктурой. Новички на самом старте получают прививку, мотивирующую их в дальнейшем использовать лучшие практики и общие инфраструктурные решения.


    Курс разбит на блоки — очные занятия с лекциями, практикой и домашними заданиями. Пока курс рассчитан преимущественно на бэкенд разработчиков. Некоторые блоки адаптированы и под фронтендеров, скоро для них появится еще три блока.


    На крэш–курс мы приглашаем не только буткамперов, но и всех желающих из команд разработки. Занятия обычно проходят в парах, и это возможность поработать вместе новичкам и опытным сотрудникам. Для буткамперов это еще и дополнительная возможность поговорить о разных командах и получить «нефильтрованную» информацию.


    Знакомство с командами


    После первых трех дней буткамперы составляют шорт–лист интересующих их команд, где описывают причины своего выбора. Уточнить информацию о команде можно у менторов — сотрудников с широким контекстом по проектам и командам. Менторы следят, чтобы выбор новичка не расходился с его мотивацией.


    Теперь пришло время знакомиться с командами :) Буткамперы самостоятельно назначают встречи, выясняют все важные для себя моменты, и с понравившимися командами договариваются о стажировках.


    Шорт-листами с мотивацией мы делимся со всеми командами, у которых открыты вакансии. Команды получают доступ к информации, включая артефакты с собеседований. Отталкиваясь от этой информации, команды могут выходить на связь с ребятами и договариваться о встречах и стажировках.


    К концу второй недели все определяются как минимум с первой стажировкой и выходят на нее. И это уже третий, самый продолжительный, блок в буткампе.


    Стажировки


    В среднем одна стажировка длится 3–4 недели, мы рекомендуем пройти 2–3 таких стажировки. Команды у нас действительно очень разные и по процессам, и по атмосфере, и по предметной области. Далеко не всегда возможно с первого раза попасть в цель, поэтому несколько стажировок — это важно.


    После стажировок ребята выбирают команду, где они хотели бы продолжить работу на постоянной основе. Естественно, при этом учитывается и желание самих команд продолжить такое сотрудничество.


    Мы фиксируем, сколько раз команда попадала в шорт-листы буткамперов, сколько стажировок прошло и сколько из них закончилось выбором в их сторону. Этой статистикой мы делимся с командами. Она помогает бороться со страхом конкуренции за стажеров с топовыми командами. Есть популярные проекты, но финальное распределение буткамперов происходит равномерно.


    Что получили в итоге?


    Начиная с августа 2017 года у нас прошло 10 наборов буткампа, в конце мая стартовал 11 набор.


    Буткамп помог:


    • Расширить воронку подбора на входе. Теперь нам не нужно оценивать все риски по кандидатам на старте.
    • Получить опытных и сильных кандидатов. Профи идут к нам охотнее, ведь на самом старте мы даем им возможность сделать осознанный выбор проекта и команды.
    • Активнее вовлекать в формат распределенной разработки. Теперь можно просто взять и поработать со стажером удаленно.
    • Организовать централизованную, качественную адаптацию новичков.
    • Получить гармоничные пары сотрудник–команда. Сотрудник выбирает команду с теми задачами, которые будут его максимально развивать, а команда получает разработчика, замотивированного на решение задач именно этой команды.
    • Получить людей компании, а не сотрудников отдельной команды. Это также очень хорошо сказывается на вовлеченности сотрудников и повышение внутренней кадровой мобильности.

    Кстати, через буткамп проходят не только программисты. Сейчас он полноценно работает и для тестировщиков, мы постепенно подключаем к этому процессу аналитиков, на очереди у нас проектировщики и дизайнеры.


    Как проходит подбор и адаптация разработчиков в ваших компаниях? Могли бы буткампы помочь и вам? Поделитесь в комментариях своим опытом собеседований в разных компаниях.

    Контур

    127,00

    Делаем веб-сервисы для бизнеса

    Поделиться публикацией
    Комментарии 49
      +3
      Опыт, ну ок. Постоянные неадекватные хрщицы которые пытаються словно пьяный мальчик аутист вставить цилиндр в неподходящее отверстие, непонятные, абсолютно неадекватные собеседования метода- «а ответте в какие циклы луны лучше поливать помидоры». После первого этапа соития, начинается второй этап впринципе этапы могут варироваться, но суть как правило одна, про то, что вы ждете, кем там себя видите, через лет эдак 50, в нашей конторе. Потом пытаются навязать выполнение тестовое задания, конечно оно не оплачиваемое (хотя компания у нас вроде как крупная и плюшки крутые, но нет, нет), любые аргументы никого не интересуют, как правило, это точка рандеву с роботодателем. Иногда пытаются вытянуть бред типа — «а разверните красночерное на салфетке» или «нарисуйте пони класс от класса лощади, но щоб оно там хитро как нибудь», но реже. Потом бывают всякие трешовые предложение вида: поработать за еду или еще как не вполне понятно как. Собеседований из 5-6 попиваний чая и 3-4 кругов обмена мироощущения после активного восприятия шаблонов у меня еще не было, но думаю узнав систему, я ущел бы уже с первого, я пришел работать, а не собеседоваться месяцами.
        –2
        плюсую комментатору выше
          +1
          После таких собеседований я как-то попал на тех, кто действительно «сломал систему» — полчаса-час пообщались сразу с руководителями и техническими специалистами, вопросы были по бывшим проектам — даже не по коду, а по решениям. Рассказываешь что-то о проекте — они «вижу такую проблему, как обошли? как решили?» — рассказываешь, без всякого кода на салфетках. Или «вот такая задача, как сделать?» — прикидываешь откуда начать, рассказываешь (если и опускаясь ниже уровня, то до блок-схем на словах и общей идеи — здесь сортировка, там словарь — без всяких деталей типа КЧ-деревьев и написания пузырька на ассемблере). Всего одно собеседование, без всяких 5 этапов со стресс-проверками и теста морального облика. Я уж думал такого не бывает.
          А здесь по первоначальному описанию какой-то адский ад, нужно очень хотеть идти туда работать, чтобы выдержать несколько однообразных собеседований.
            +2

            Я однажды сильно ошибся с таким подходом. Человек очень убедительно рассказывал про опыт, рисовал схемы и картинки. Но после трудоустройства оказалось что очень слабо дружит с инструментами разработки да и код пишет абы как. Все-таки тестовые задания для разработчиков должны быть. Но очень простые и на месте. Чтобы отсеять болтунов.

              +1
              Когда сам проводил — давал тестовые, но простые, практически на пальцах. Разный подход — кто (как Яндекс или Контур) может себе позволить отсеять неудачников — тот даёт многочасовые собеседования, кто может позволить проверить испытательным сроком — тот просто общается (иногда что-то зная о проектах из резюме, иногда нет), большинство — где-то посередине.
                0
                Даёте пару примеров кода и просите рассказать что он делает, найти ошибки и рассказать как можно улучшить/оптимизировать… Эти 5-10 минут разговора отлично отсекают болтунов и в то же время не создают стресс для кандидата, как, например написание кода на салфетке/доске…
                  0
                  и в то же время не создают стресс для кандидата

                  Стресс? Программисту написать код — это стресс? А вам точно нужен такой программист?

                    0
                    Такой = привыкший писать код не на салфетке, а в IDE?
                      0

                      "привыкший" != "способный при необходимости"


                      Никто ж не требует написать код, который с салфетки без ошибок скомпилируется. Пишите псевдокодом. Или берите ноут с любимой IDE.
                      Если вы хороший разработчик, не вижу никаких проблем. Я же могу.

                        +1
                        Я же могу.
                        Так себе аргумент. А все, кто не вы — все не разработчики, получается. Вы же можете быть ncix'ом, почему они не могут?
                          0

                          Поверьте, я далеко не самый крутой разработчик на свете. Так, были времена, что-то мог… А для вас в чем проблема накорябать на салфетке псевдокодом какой-нибудь простейший синглтон?

                            0
                            Да я строку текста от руки буду дольше минуты писать. Торопиться, нервничать и сбиваться.
                              0

                              А чего нервничать-то? Вы работодателю нужны больше чем он вам, если конечно это не Яндекс или Гугл.


                              Кстати аргументированно отстоять позицию что писать на салфетках — это для серьезных разработчиков дурной тон, и убедить в этом оппонента — тоже классный способ получить работу :)

                                0
                                Потому что зачем идти на вакансию, на которую не очень-то и надо?
                          0
                          берите ноут с любимой IDE
                          Как это избавит от стресса в написании кода на салфетке?
                            0

                            Ну напишите на своем ноуте. Если при наличии ноута вас просят корябать на салфетке — я бы усомнился в адекватности этих товарищей.

                        0
                        Нет, написать код для программиста не стресс, но для этого должны быть созданы условия: удобное рабочее место, компьютер с IDE настроенные под данного человека, доступ в Интернет для быстрого разрешения затыков. Написание на скорость кода «на салфетке» без подсветки синтаксиса, возможности скомпилировать и проверить как это работает — это стресс (к тому же это же часть интервью, а значит кандидат и так находится в состоянии стресса, так как хочет показать себя с лучшей стороны и получить эту работу)…
                        К примеру, я считаю себя неплохим разработчиком (10 лет опыта и участие в олимпиадах и хакатонах), но мне писать код на салфетке некомфортно и скорее всего написанное тупо не скомпилируется…

                        Нет, если в вашей компании до сих пор используют перфокарты, а потом стоят в очереди, чтобы скомпилировать и проверить, то написание кода на салфетке — хорошая идея… Если же вы современная компания, то не издевайтесь над людьми…
                      0
                      Для отсева болтунов есть испытательный срок.
                        0

                        Серьезно? Может вообще собеседования не проводить — сразу на ИС брать?


                        Предлагаете возложить расходы на бюджет организации вместо того чтобы попросить соискателя потратить 10 минут и написать десяток строчек кода?

                          0
                          А не лучше ли потратить 30 минут тем, кто проводит техническое интервью и подобрать пару примеров кода, чтобы попросить кандидата рассказать что этот код делает, попросить найти ошибки и оптимизировать… Если ещё минут 15 потратить на вопросы вроде «нарисуйте блок-схему/алгоритм решения задачи» или «расскажите как бы вы решили эту задачу», то до испытательного срока дойдут как минимум неплохие программисты.
                            0

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


                            А ваш стресс — это ваши проблемы, извините. В серьезной работе будет много более серьезных стрессов. Набившую оскомину "стрессоустойчивость" никто не отменял. Sad but true.


                            PS: Я не думаю что тут есть универсальная мерка правды. Я бы не взял разработчика, боящегося лишний раз почувствовать стресс. У нас в работе его хватает.
                            Но если вы не хотите стресса — ищите работу без стресса, думаю такие варианты есть. Конечно же такие вещи надо проговорить с работодателем на берегу.

                              0
                              В работе разработчика — 60-70% — это умение читать, понимать чужой код и оптимизировать его (если это конечно не старт проекта с нуля). А из оставшихся 30% — половина — это умение чужой код переиспользовать и модифицировать. И только оставшиеся 15% — это те нестандартные задачи, где нужно много думать и делать что-то уникальное.
                              Про компетенцию в написании кода можно судить по тому, как кандидат предложит оптимизировать представленный фрагмент кода, а также при ответе на вопрос «как вы реализуете задачу» — конечно вы не увидите тут стандартов оформления или SOLID принципов (хотя и несоблюдение стандартов и нарушение SOLID может быть специально сделанными ошибками в показанном фрагменте и задача кандидата указать их).

                              Стрессоустойчивость — это хорошо, но когда это переходит в «создавать себе проблемы и потом героически их решать», то это признак плохого работодателя. Наличие стресса в работе сотрудников — это на 80% недостатки планирования или ресурсов (тут нужно менеджеров менять, а не искать стрессоустойчивых сотрудников).

                              Как разработчик, я согласен работать со стрессами в формате «давайте поднажмём чтобы выпустить релиз вовремя» или «у клента критическая ошибка — нужно срочно исправить», но если это «а напишите код на бумажке потому что я так хочу» или «что значит не сможете сделать за 3 дня! Я уже клиентам пообещал», то такой работы я не хочу… И да, за последние 8 лет я проработал в 3х солидных компаниях в разных частях мира и у меня были только стрессы первой категории (т.е. обычная рабочая рутина и авраалы, а не закидоны руководства и самодурство).
                                0

                                По статистике, 82,5% людей верят любым цифрам статистики.


                                Я не понимаю откуда у вас такие проценты и как их в принципе можно получить, т.к. это может быть средней температурой по больнице, но абсолютно не совпасть с содержанием конкретной работы в конкретной компании в определенный момент времени.


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

                                  0
                                  Цифры не из статистики, а из собственного опыта и наблюдений за коллегами (4 компании, больше 10 проектов, 10 лет) — так что на абсолютную истину не претендую.
                                  Про «виноваты менеджеры» — они виноваты не во всём. Есть 2 беды менеджемента — ошибки в планировании и жадность (вернее экономия на мелочах ведущая к потере чего то важного).
                                  Недостатки планирования чаще всего выглядят в излишней самоуверенности менеджера (без понимания технических деталей) и желания выслужиться перед вышестоящим руководством. Отсюда появляется необходимость «стрессоустойчивых» сотрудников. Т.е. когда менеджер не советуясь с командой обещает руководству о сроках, а потом давит на свою команду чтобы это обещание сдержать. Если бы такой менеджер изначально пришёл к команде, попросил оценить задачу и обосновать оценку, добавил 20-30% времени на риски и потом уже подтвердил руководству сроки, то все были бы счастливы: руководство получило бы реальные сроки, которые не пришлось бы переносить, работники получили бы возможность работать без стресса, а менеджер — возможность показать с себя с лучшей стороны, т.к. все риски скорее всего не выстрелят и задачу закончат раньше.

                                  Вторая проблема жадность. Пример из моего предыдущего опыта: в одной из команд менеджеры решили отказаться от тестировщиков и вместо них ввели тестирование разработчиками. На первый взгляд это сэкономило немало денег (можно показать красивые графики руководству и выслужиться), но в результате получилось что разработчики делают не свою работу (а значит делают её менее качественно), сроки релизов сильно просели из-за невозможности тестировать и разрабатывать одновременно, а стоимость тестирования возрасла т.к. его делают «дорогие» разработчики, а не «относительно дешёвые» тестировщики.
                            0
                            А почему у Вас логин такой интересный?
                              0

                              Позвольте полюбопытствовать, чем интересный?

                                0
                                На смесь Norton Commandera с Unix походит.)
                        0
                        Ваше сообщение бы распечатать и под стекло на стол в HR отделы ИТ компаний (да и не только ИТ). Так и должно быть, когда спрашивают то, с чем реально работают, изучают предыдущий опыт и оценивают, насколько он будет полезен для компании…
                          0
                          Забавный случай вспомнился. Парень собеседовался на явера. Как вы и пишете — на все собеседование час, присутствовали, кроме него, три человека: руководитель, технарь по яве, я.
                          По итогам, выслали ему оффер. Отказался. Узнал потом через общих знакомых — собеседование показалось ему каким-то несерьезным.

                          Тут правда, есть оговорка: ява для компании направление побочное, основное — SAP ERP, соответственно программисты в основном — ABAP.
                        +5
                        Инструкция о том как HR имитировать бурную деятельность.
                        Cерьезный дискомфорт для кандидатов, которым нередко приходилось пройти через 5–8 собеседований. В одном собеседовании участвовало от 6 до 10 человек.

                        Процесс подбора затягивался на месяцы, мы теряли интересных людей.

                        Отлично вообще.
                          +2
                          то есть теперь Вы не задаёте задачу про пирожки?
                            0
                            Ваш изначальный подход — это издевательство над кандидатами. (Даже если вы крутая компания, это не даёт вам право проводить 6-8 интервью с одним кандидатом и тратить 2-3 его полных рабочих для, чтобы в результате не взять его в команду).

                            Идеальный процесс с точки зрения разработчика выглядит так:
                            — Телефонное интервью, чтобы отсеять совсем не подходящих кандидатов) (15-30 минут, опционально)
                            — Интервью в компании — (2 часа максимум, из них 15 минут — разговор с HR, софт скилы, рассказ о компании и кандидате, 1 час — техническое интервью, 45 минут — дизайн, умение читать код, паттерны). На интервью 3-5 человек — HR и представители команд (они же и отвечают за техническую часть). Не заставляйте кандитата писать код, лучше попросите спроектировать систему, рассказать на словах как бы реализовал алгоритм или показать примеры кода и попросить найти ошибки/оптимизировать/рассказать что он делает.
                            — Если кандидат проходит, то берут на испытательный срок 1-3 месяца, где уже и происходит адаптация в команде/выбор команды. (с выплатой полной оговоренной зарплаты) Для джуниоров вместо испытательного срока может быть стажировка/обучение (бесплатно или с минимальной оплатой, но не больше 1-2 месяцев)
                              0

                              Примерно так и проходит этот процесс сейчас. Только 1-3 месяца кандидат работает по очереди в нескольких командах, которые выбирает сам.

                                0

                                Правильнее назвать буткампера не кандидат, а новый сотрудник. У него все права сотрудника на испытательном сроке.

                              0

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

                                +2
                                Давайте сравним, с ваших же слов. Было:
                                Cерьезный дискомфорт для кандидатов, которым нередко приходилось пройти через 5–8 собеседований. В одном собеседовании участвовало от 6 до 10 человек.

                                Стало:
                                Гильдия проводит технические собеседования, где кандидат проходит 3 обязательных секции:
                                [...]
                                Еще есть дополнительная секция для опытных разработчиков
                                [...]
                                проводим финальное собеседование
                                [...]
                                А дальше новичок попадает на 3 месяца в буткамп
                                [...]
                                И только после этого уже сформировавшийся контуровец выбирает команду, где он хочет работать.

                                Это же насколько надо хотеть работать в вашей компании?
                                  0
                                  Технические собеседования, насколько я понимаю, имеется ввиду, что гильдия проводит собеседования разных разработчиков.
                                  Финальное собеседование — это скорее беседа, хотя когда я устраивался меня попросили решить логические задачки (что по-моему, довольно бесполезно).
                                  В целом, процесс найма в Контур у меня был таким:
                                  1. Беседа с HR (10-15 минут)
                                  2. Тестовое задание (Задача по Android и задача на алгоритмы), ~3-4 часа
                                  3. Техническое интервью, ~1 час
                                  4. Знакомство с командой и, как я выше упомянул, логические задачки
                                  Если исключить эти самые задачки, то на мой взгляд всё будет отлично.
                                  По поводу буткампа — у меня от него только положительные впечатления, но я изначально не стажировался ни в одной команде, а шёл сразу в конкретную. Ребята, которые проходили буткамп со мной тоже вроде им довольны — кто-то прошёл стажировку только в одной команде и сразу пошёл к ним, кто-то прошёл 2-3 и выбрал ту, что больше всего понравилась.
                                  P.S. я не заинтересованное лицо, т.к. в Контуре уже не работаю.
                                  +1
                                  Буткамп помог:

                                  Хоть один пункт напишите который помог чем-то соискателям, а не компании.
                                    0

                                    Стоит начать с того, что буткамп — это не испытание кандидата, а адаптация нового сотрудника. Буткамперы получают зарплату, о которой договорились. В Буткампе они могут пощупать задачи разных команд, познакомиться с будущими коллегами из этих команд, узнать общие техники и традиции компании. За 3 месяца человек может выбрать тот проект, который ему интересен, учесть личное отношение и атмосферу каждой команды.
                                    Про собеседования: гильдия проводит 1 собеседование по 3 секциям. Плюс 1 финальное собеседование. Всего 2, вместо 5-8. Для опытных разработчиков, которые претендуют на особые условия, есть еще одно особое собеседование. Итого, у опытных — 3 собеседования.
                                    Не все новые сотрудники проходят буткамп, есть те, которые идут сразу ради какого-то проекта.
                                    Из плюсов:


                                    • меньше собеседований,
                                    • возможность выбрать подходящую команду и интересные задачи,
                                    • плавная адаптация к новой работе (про то, зачем нужна адаптация и что это такое, думаю не нужно писать).
                                    • креш-курс, где можно прокачать навыки.
                                    +1
                                    А сколько интерьвю в результате проходит кандидат и сколько времени это занимает в новом процессе?
                                    Если больше 1-2 интервью и 3 часов, то вы ничего не изменили в итоге… Если за 2 часа вы не можете понять подходит вам человек или нет, то вам нужно менять HR и тех, кто проводит техническое интервью. Как вариант вводить систему оценок с проходным баллом и возможностью интервьюверов давать дополнительные баллы за общее положительное или отрицательное впечатление, которое кандидат произвёл.
                                      0
                                      В среднем проходит 2-3 собеседования, около 4-6 часов в общей сложности. Собеседования проходят в разные дни, как удобнее кандидату.
                                      Честно говоря, даже меня на должность копирайтера тестили столько же времени, еще и тестовые были всегда. И не только в Контур, но и на предыдущие места работы. Лично мне не кажется это слишком долгим процессом. Если я выбираю работу, я хочу быть уверена, что подхожу компании, а компания подходит мне.
                                        +1
                                        Это много! Представьте что кандидат работает и хочет сменить работу (а у большинства хороших кандидатов именно так), он разослал резюме в 3-4 конторы и каждая из них проводит такие издевательские собеседования… 4*6 = 24 часа + подготовка, время на дорогу и т.д. получается что минимум 1 рабочая неделя уходит… (а ведь всё это происходит в рабочее время, а значит кандидат либо должен использовать отпуск, либо ещё как-то выкручиваться). Я уже писал выше, что если вы не можете понять за 2 часа подходит вам человек или нет, то значит вы не то спрашиваете или не на то смотрите… К тому же внимательное изучение резюме и профиля в LinkedIn поможет избежать ненужных вопросов, а разговор о предыдущих проектах покажет реальный опыт кандидата. Ещё одна важная вещь: спрашивайте то, что вы реально используете в своей работе. Если, к примеру, вы пишите API, то спрашивайте по API, а не про то как реализовать сортировку пузырьком в двухсвязанном списке…
                                    0
                                    Следующим этапом будет улучшение сервиса саппорта :) с написанием статьи — «как мы сделали по человечьи». Пишу как клиент :) Вернитесь в реальность!
                                      0
                                      По первой части это, конечно, кошмар. С таким подходом можно нанять только очень мотивированных студентов. Любой уважающий себя профи исчезнет с горизонта после 2 интервью.

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

                                      И спасибо, что поделились опытом. Думаю многим работодателям есть куда расти, и такой подход был бы очень неплох.
                                        +1
                                        2Автор, Извините за hard
                                        ИМХо у Вас такая большая текучка в первый год вовсе не потому что буткамп/не буткамп.
                                        Другая специфика отбора это просто другая воронка попадающих к Вам на работу.
                                        А почему люди бегут это просто:
                                        Недавно был анонимный запрос на хабре который показал правду — потолок з/п среднестатистический у Вас 105. При том что за него надо пахать как раб на галерах.
                                        При том что в Москве с улицы берут на 150. Конечно Екат не Москва, но и здесь ГИКи не глупые и пахать как ВВП будут от 130/150. Тем более что предложений для профи полно — тот же Яндекс и другие федеральные/европейские ИТ конторы — с десяток уж или больше их расплодилось.
                                        И пока Ваше руководство мечтает построить на Широкой речке Силиконовую долину по сути при таких з/п Вы просто старт для студентов.
                                          0

                                          Буткамп это конечно здорово, но во сколько это обходится компании? Вы уверены что эти расходы окупаются? Очень интересно, оценивали ли вы это с экономической точки зрения и как?

                                            0
                                            Я попросила ответить на этот вопрос Лиду Самкову, руководителя IT HR. Вот что она пишет:
                                            — Эти расходы окупаются, так как сокращаются другие и на выходе получается больше профита и для компании, и для новичка. К нам стало выходить больше разработчиков, а уходят меньше. Раньше каждая команда тратила свое время на ввод нового сотрудника, на обучение его общеконтуровским практикам, инструментам и решениям, этот процесс не был централизован. По факту, новичок начинал приносить отдачу спустя 3 месяца. А в течение первого года, в случае несовпадения ожиданий и реальности, мог уйти. И все вложенные усилия команды, как будто были зря.
                                            Сейчас обучение общеконтуровским практикам проходит на старте и централизовано, команды уже практически не тратят на это время, на стажировку приходит подготовленный человек. Плюс мы научились  давать новичкам реальные и завершаемые задачи. т.е. даже если буткампер выберет другую команду, он за несколько недель успел принести некий профит той, в которой стажировался. И сейчас, по окончании буткампа, команда получает человека максимально замотивированного на решение ее задач. Т.е. риск ухода в течение скорого времени сильно снижается. Новичок принимал решение не на основе рассказов о команде и задачах, которые случайно можно передать и воспринять через призму. А на основе своих реальных ощущений, он поработал в команде, он потрогал руками задачи, он увидел своими глазами реальную картинку.
                                              0
                                              А работают они так же хорошо или ваш KPI исключительно по времени работы и количеству пришедших/ушедших?
                                                0
                                                Да, конечно. У нас была цель улучшить процесс, а не ухудшить его, снизив качество :) Уровень наших требований с появлением Буткампа не изменился и у новичков есть испытательный срок, в течение которого они приглядываются к нам, а мы к ним. Тут ничего не изменилось.

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

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