Comments 49
Опыт, ну ок. Постоянные неадекватные хрщицы которые пытаються словно пьяный мальчик аутист вставить цилиндр в неподходящее отверстие, непонятные, абсолютно неадекватные собеседования метода- «а ответте в какие циклы луны лучше поливать помидоры». После первого этапа соития, начинается второй этап впринципе этапы могут варироваться, но суть как правило одна, про то, что вы ждете, кем там себя видите, через лет эдак 50, в нашей конторе. Потом пытаются навязать выполнение тестовое задания, конечно оно не оплачиваемое (хотя компания у нас вроде как крупная и плюшки крутые, но нет, нет), любые аргументы никого не интересуют, как правило, это точка рандеву с роботодателем. Иногда пытаются вытянуть бред типа — «а разверните красночерное на салфетке» или «нарисуйте пони класс от класса лощади, но щоб оно там хитро как нибудь», но реже. Потом бывают всякие трешовые предложение вида: поработать за еду или еще как не вполне понятно как. Собеседований из 5-6 попиваний чая и 3-4 кругов обмена мироощущения после активного восприятия шаблонов у меня еще не было, но думаю узнав систему, я ущел бы уже с первого, я пришел работать, а не собеседоваться месяцами.
UFO just landed and posted this here
После таких собеседований я как-то попал на тех, кто действительно «сломал систему» — полчаса-час пообщались сразу с руководителями и техническими специалистами, вопросы были по бывшим проектам — даже не по коду, а по решениям. Рассказываешь что-то о проекте — они «вижу такую проблему, как обошли? как решили?» — рассказываешь, без всякого кода на салфетках. Или «вот такая задача, как сделать?» — прикидываешь откуда начать, рассказываешь (если и опускаясь ниже уровня, то до блок-схем на словах и общей идеи — здесь сортировка, там словарь — без всяких деталей типа КЧ-деревьев и написания пузырька на ассемблере). Всего одно собеседование, без всяких 5 этапов со стресс-проверками и теста морального облика. Я уж думал такого не бывает.
А здесь по первоначальному описанию какой-то адский ад, нужно очень хотеть идти туда работать, чтобы выдержать несколько однообразных собеседований.
А здесь по первоначальному описанию какой-то адский ад, нужно очень хотеть идти туда работать, чтобы выдержать несколько однообразных собеседований.
Я однажды сильно ошибся с таким подходом. Человек очень убедительно рассказывал про опыт, рисовал схемы и картинки. Но после трудоустройства оказалось что очень слабо дружит с инструментами разработки да и код пишет абы как. Все-таки тестовые задания для разработчиков должны быть. Но очень простые и на месте. Чтобы отсеять болтунов.
Когда сам проводил — давал тестовые, но простые, практически на пальцах. Разный подход — кто (как Яндекс или Контур) может себе позволить отсеять неудачников — тот даёт многочасовые собеседования, кто может позволить проверить испытательным сроком — тот просто общается (иногда что-то зная о проектах из резюме, иногда нет), большинство — где-то посередине.
Даёте пару примеров кода и просите рассказать что он делает, найти ошибки и рассказать как можно улучшить/оптимизировать… Эти 5-10 минут разговора отлично отсекают болтунов и в то же время не создают стресс для кандидата, как, например написание кода на салфетке/доске…
и в то же время не создают стресс для кандидата
Стресс? Программисту написать код — это стресс? А вам точно нужен такой программист?
Такой = привыкший писать код не на салфетке, а в IDE?
"привыкший" != "способный при необходимости"
Никто ж не требует написать код, который с салфетки без ошибок скомпилируется. Пишите псевдокодом. Или берите ноут с любимой IDE.
Если вы хороший разработчик, не вижу никаких проблем. Я же могу.
Я же могу.Так себе аргумент. А все, кто не вы — все не разработчики, получается. Вы же можете быть ncix'ом, почему они не могут?
Поверьте, я далеко не самый крутой разработчик на свете. Так, были времена, что-то мог… А для вас в чем проблема накорябать на салфетке псевдокодом какой-нибудь простейший синглтон?
Да я строку текста от руки буду дольше минуты писать. Торопиться, нервничать и сбиваться.
берите ноут с любимой IDEКак это избавит от стресса в написании кода на салфетке?
Нет, написать код для программиста не стресс, но для этого должны быть созданы условия: удобное рабочее место, компьютер с IDE настроенные под данного человека, доступ в Интернет для быстрого разрешения затыков. Написание на скорость кода «на салфетке» без подсветки синтаксиса, возможности скомпилировать и проверить как это работает — это стресс (к тому же это же часть интервью, а значит кандидат и так находится в состоянии стресса, так как хочет показать себя с лучшей стороны и получить эту работу)…
К примеру, я считаю себя неплохим разработчиком (10 лет опыта и участие в олимпиадах и хакатонах), но мне писать код на салфетке некомфортно и скорее всего написанное тупо не скомпилируется…
Нет, если в вашей компании до сих пор используют перфокарты, а потом стоят в очереди, чтобы скомпилировать и проверить, то написание кода на салфетке — хорошая идея… Если же вы современная компания, то не издевайтесь над людьми…
К примеру, я считаю себя неплохим разработчиком (10 лет опыта и участие в олимпиадах и хакатонах), но мне писать код на салфетке некомфортно и скорее всего написанное тупо не скомпилируется…
Нет, если в вашей компании до сих пор используют перфокарты, а потом стоят в очереди, чтобы скомпилировать и проверить, то написание кода на салфетке — хорошая идея… Если же вы современная компания, то не издевайтесь над людьми…
Для отсева болтунов есть испытательный срок.
Серьезно? Может вообще собеседования не проводить — сразу на ИС брать?
Предлагаете возложить расходы на бюджет организации вместо того чтобы попросить соискателя потратить 10 минут и написать десяток строчек кода?
А не лучше ли потратить 30 минут тем, кто проводит техническое интервью и подобрать пару примеров кода, чтобы попросить кандидата рассказать что этот код делает, попросить найти ошибки и оптимизировать… Если ещё минут 15 потратить на вопросы вроде «нарисуйте блок-схему/алгоритм решения задачи» или «расскажите как бы вы решили эту задачу», то до испытательного срока дойдут как минимум неплохие программисты.
Ревью чужого кода — это только одна из компетенций разработчика. То что он может написать сам с нуля — другая компетенция. И вы ее не узнаете, пока не увидите код.
А ваш стресс — это ваши проблемы, извините. В серьезной работе будет много более серьезных стрессов. Набившую оскомину "стрессоустойчивость" никто не отменял. Sad but true.
PS: Я не думаю что тут есть универсальная мерка правды. Я бы не взял разработчика, боящегося лишний раз почувствовать стресс. У нас в работе его хватает.
Но если вы не хотите стресса — ищите работу без стресса, думаю такие варианты есть. Конечно же такие вещи надо проговорить с работодателем на берегу.
В работе разработчика — 60-70% — это умение читать, понимать чужой код и оптимизировать его (если это конечно не старт проекта с нуля). А из оставшихся 30% — половина — это умение чужой код переиспользовать и модифицировать. И только оставшиеся 15% — это те нестандартные задачи, где нужно много думать и делать что-то уникальное.
Про компетенцию в написании кода можно судить по тому, как кандидат предложит оптимизировать представленный фрагмент кода, а также при ответе на вопрос «как вы реализуете задачу» — конечно вы не увидите тут стандартов оформления или SOLID принципов (хотя и несоблюдение стандартов и нарушение SOLID может быть специально сделанными ошибками в показанном фрагменте и задача кандидата указать их).
Стрессоустойчивость — это хорошо, но когда это переходит в «создавать себе проблемы и потом героически их решать», то это признак плохого работодателя. Наличие стресса в работе сотрудников — это на 80% недостатки планирования или ресурсов (тут нужно менеджеров менять, а не искать стрессоустойчивых сотрудников).
Как разработчик, я согласен работать со стрессами в формате «давайте поднажмём чтобы выпустить релиз вовремя» или «у клента критическая ошибка — нужно срочно исправить», но если это «а напишите код на бумажке потому что я так хочу» или «что значит не сможете сделать за 3 дня! Я уже клиентам пообещал», то такой работы я не хочу… И да, за последние 8 лет я проработал в 3х солидных компаниях в разных частях мира и у меня были только стрессы первой категории (т.е. обычная рабочая рутина и авраалы, а не закидоны руководства и самодурство).
Про компетенцию в написании кода можно судить по тому, как кандидат предложит оптимизировать представленный фрагмент кода, а также при ответе на вопрос «как вы реализуете задачу» — конечно вы не увидите тут стандартов оформления или SOLID принципов (хотя и несоблюдение стандартов и нарушение SOLID может быть специально сделанными ошибками в показанном фрагменте и задача кандидата указать их).
Стрессоустойчивость — это хорошо, но когда это переходит в «создавать себе проблемы и потом героически их решать», то это признак плохого работодателя. Наличие стресса в работе сотрудников — это на 80% недостатки планирования или ресурсов (тут нужно менеджеров менять, а не искать стрессоустойчивых сотрудников).
Как разработчик, я согласен работать со стрессами в формате «давайте поднажмём чтобы выпустить релиз вовремя» или «у клента критическая ошибка — нужно срочно исправить», но если это «а напишите код на бумажке потому что я так хочу» или «что значит не сможете сделать за 3 дня! Я уже клиентам пообещал», то такой работы я не хочу… И да, за последние 8 лет я проработал в 3х солидных компаниях в разных частях мира и у меня были только стрессы первой категории (т.е. обычная рабочая рутина и авраалы, а не закидоны руководства и самодурство).
По статистике, 82,5% людей верят любым цифрам статистики.
Я не понимаю откуда у вас такие проценты и как их в принципе можно получить, т.к. это может быть средней температурой по больнице, но абсолютно не совпасть с содержанием конкретной работы в конкретной компании в определенный момент времени.
Истории о том, что во всем виноваты менеджеры — много много лет, и история абсолютно правдивая. Даже если компания набрала слабых разработчиков — опять же это ошибка менеджеров. Но я повторюсь, все дело в вашем выборе — выбирайте работу по душе. Есть много желающих рисовать на салфетках, поверьте :)
Цифры не из статистики, а из собственного опыта и наблюдений за коллегами (4 компании, больше 10 проектов, 10 лет) — так что на абсолютную истину не претендую.
Про «виноваты менеджеры» — они виноваты не во всём. Есть 2 беды менеджемента — ошибки в планировании и жадность (вернее экономия на мелочах ведущая к потере чего то важного).
Недостатки планирования чаще всего выглядят в излишней самоуверенности менеджера (без понимания технических деталей) и желания выслужиться перед вышестоящим руководством. Отсюда появляется необходимость «стрессоустойчивых» сотрудников. Т.е. когда менеджер не советуясь с командой обещает руководству о сроках, а потом давит на свою команду чтобы это обещание сдержать. Если бы такой менеджер изначально пришёл к команде, попросил оценить задачу и обосновать оценку, добавил 20-30% времени на риски и потом уже подтвердил руководству сроки, то все были бы счастливы: руководство получило бы реальные сроки, которые не пришлось бы переносить, работники получили бы возможность работать без стресса, а менеджер — возможность показать с себя с лучшей стороны, т.к. все риски скорее всего не выстрелят и задачу закончат раньше.
Вторая проблема жадность. Пример из моего предыдущего опыта: в одной из команд менеджеры решили отказаться от тестировщиков и вместо них ввели тестирование разработчиками. На первый взгляд это сэкономило немало денег (можно показать красивые графики руководству и выслужиться), но в результате получилось что разработчики делают не свою работу (а значит делают её менее качественно), сроки релизов сильно просели из-за невозможности тестировать и разрабатывать одновременно, а стоимость тестирования возрасла т.к. его делают «дорогие» разработчики, а не «относительно дешёвые» тестировщики.
Про «виноваты менеджеры» — они виноваты не во всём. Есть 2 беды менеджемента — ошибки в планировании и жадность (вернее экономия на мелочах ведущая к потере чего то важного).
Недостатки планирования чаще всего выглядят в излишней самоуверенности менеджера (без понимания технических деталей) и желания выслужиться перед вышестоящим руководством. Отсюда появляется необходимость «стрессоустойчивых» сотрудников. Т.е. когда менеджер не советуясь с командой обещает руководству о сроках, а потом давит на свою команду чтобы это обещание сдержать. Если бы такой менеджер изначально пришёл к команде, попросил оценить задачу и обосновать оценку, добавил 20-30% времени на риски и потом уже подтвердил руководству сроки, то все были бы счастливы: руководство получило бы реальные сроки, которые не пришлось бы переносить, работники получили бы возможность работать без стресса, а менеджер — возможность показать с себя с лучшей стороны, т.к. все риски скорее всего не выстрелят и задачу закончат раньше.
Вторая проблема жадность. Пример из моего предыдущего опыта: в одной из команд менеджеры решили отказаться от тестировщиков и вместо них ввели тестирование разработчиками. На первый взгляд это сэкономило немало денег (можно показать красивые графики руководству и выслужиться), но в результате получилось что разработчики делают не свою работу (а значит делают её менее качественно), сроки релизов сильно просели из-за невозможности тестировать и разрабатывать одновременно, а стоимость тестирования возрасла т.к. его делают «дорогие» разработчики, а не «относительно дешёвые» тестировщики.
UFO just landed and posted this here
Ваше сообщение бы распечатать и под стекло на стол в HR отделы ИТ компаний (да и не только ИТ). Так и должно быть, когда спрашивают то, с чем реально работают, изучают предыдущий опыт и оценивают, насколько он будет полезен для компании…
Забавный случай вспомнился. Парень собеседовался на явера. Как вы и пишете — на все собеседование час, присутствовали, кроме него, три человека: руководитель, технарь по яве, я.
По итогам, выслали ему оффер. Отказался. Узнал потом через общих знакомых — собеседование показалось ему каким-то несерьезным.
Тут правда, есть оговорка: ява для компании направление побочное, основное — SAP ERP, соответственно программисты в основном — ABAP.
По итогам, выслали ему оффер. Отказался. Узнал потом через общих знакомых — собеседование показалось ему каким-то несерьезным.
Тут правда, есть оговорка: ява для компании направление побочное, основное — SAP ERP, соответственно программисты в основном — ABAP.
Инструкция о том как HR имитировать бурную деятельность.
Отлично вообще.
Cерьезный дискомфорт для кандидатов, которым нередко приходилось пройти через 5–8 собеседований. В одном собеседовании участвовало от 6 до 10 человек.
Процесс подбора затягивался на месяцы, мы теряли интересных людей.
Отлично вообще.
то есть теперь Вы не задаёте задачу про пирожки?
Ваш изначальный подход — это издевательство над кандидатами. (Даже если вы крутая компания, это не даёт вам право проводить 6-8 интервью с одним кандидатом и тратить 2-3 его полных рабочих для, чтобы в результате не взять его в команду).
Идеальный процесс с точки зрения разработчика выглядит так:
— Телефонное интервью, чтобы отсеять совсем не подходящих кандидатов) (15-30 минут, опционально)
— Интервью в компании — (2 часа максимум, из них 15 минут — разговор с HR, софт скилы, рассказ о компании и кандидате, 1 час — техническое интервью, 45 минут — дизайн, умение читать код, паттерны). На интервью 3-5 человек — HR и представители команд (они же и отвечают за техническую часть). Не заставляйте кандитата писать код, лучше попросите спроектировать систему, рассказать на словах как бы реализовал алгоритм или показать примеры кода и попросить найти ошибки/оптимизировать/рассказать что он делает.
— Если кандидат проходит, то берут на испытательный срок 1-3 месяца, где уже и происходит адаптация в команде/выбор команды. (с выплатой полной оговоренной зарплаты) Для джуниоров вместо испытательного срока может быть стажировка/обучение (бесплатно или с минимальной оплатой, но не больше 1-2 месяцев)
Идеальный процесс с точки зрения разработчика выглядит так:
— Телефонное интервью, чтобы отсеять совсем не подходящих кандидатов) (15-30 минут, опционально)
— Интервью в компании — (2 часа максимум, из них 15 минут — разговор с HR, софт скилы, рассказ о компании и кандидате, 1 час — техническое интервью, 45 минут — дизайн, умение читать код, паттерны). На интервью 3-5 человек — HR и представители команд (они же и отвечают за техническую часть). Не заставляйте кандитата писать код, лучше попросите спроектировать систему, рассказать на словах как бы реализовал алгоритм или показать примеры кода и попросить найти ошибки/оптимизировать/рассказать что он делает.
— Если кандидат проходит, то берут на испытательный срок 1-3 месяца, где уже и происходит адаптация в команде/выбор команды. (с выплатой полной оговоренной зарплаты) Для джуниоров вместо испытательного срока может быть стажировка/обучение (бесплатно или с минимальной оплатой, но не больше 1-2 месяцев)
Все комментаторы правы. Старая система была далека от идеала. Обо всех ее минусах, страданиях компании, а главное, кандидатов, мы написали в первой части статьи. Мы перестроили систему. Об этом написано во второй части текста. Сейчас мы решили старые проблемы с подбором, научились на своих ошибках, изменили процессы. И теперь подбор проходит, что называется, по-любви.
Давайте сравним, с ваших же слов. Было:
Стало:
Это же насколько надо хотеть работать в вашей компании?
Cерьезный дискомфорт для кандидатов, которым нередко приходилось пройти через 5–8 собеседований. В одном собеседовании участвовало от 6 до 10 человек.
Стало:
Гильдия проводит технические собеседования, где кандидат проходит 3 обязательных секции:
[...]
Еще есть дополнительная секция для опытных разработчиков
[...]
проводим финальное собеседование
[...]
А дальше новичок попадает на 3 месяца в буткамп
[...]
И только после этого уже сформировавшийся контуровец выбирает команду, где он хочет работать.
Это же насколько надо хотеть работать в вашей компании?
Технические собеседования, насколько я понимаю, имеется ввиду, что гильдия проводит собеседования разных разработчиков.
Финальное собеседование — это скорее беседа, хотя когда я устраивался меня попросили решить логические задачки (что по-моему, довольно бесполезно).
В целом, процесс найма в Контур у меня был таким:
1. Беседа с HR (10-15 минут)
2. Тестовое задание (Задача по Android и задача на алгоритмы), ~3-4 часа
3. Техническое интервью, ~1 час
4. Знакомство с командой и, как я выше упомянул, логические задачки
Если исключить эти самые задачки, то на мой взгляд всё будет отлично.
По поводу буткампа — у меня от него только положительные впечатления, но я изначально не стажировался ни в одной команде, а шёл сразу в конкретную. Ребята, которые проходили буткамп со мной тоже вроде им довольны — кто-то прошёл стажировку только в одной команде и сразу пошёл к ним, кто-то прошёл 2-3 и выбрал ту, что больше всего понравилась.
P.S. я не заинтересованное лицо, т.к. в Контуре уже не работаю.
Финальное собеседование — это скорее беседа, хотя когда я устраивался меня попросили решить логические задачки (что по-моему, довольно бесполезно).
В целом, процесс найма в Контур у меня был таким:
1. Беседа с HR (10-15 минут)
2. Тестовое задание (Задача по Android и задача на алгоритмы), ~3-4 часа
3. Техническое интервью, ~1 час
4. Знакомство с командой и, как я выше упомянул, логические задачки
Если исключить эти самые задачки, то на мой взгляд всё будет отлично.
По поводу буткампа — у меня от него только положительные впечатления, но я изначально не стажировался ни в одной команде, а шёл сразу в конкретную. Ребята, которые проходили буткамп со мной тоже вроде им довольны — кто-то прошёл стажировку только в одной команде и сразу пошёл к ним, кто-то прошёл 2-3 и выбрал ту, что больше всего понравилась.
P.S. я не заинтересованное лицо, т.к. в Контуре уже не работаю.
Буткамп помог:
Хоть один пункт напишите который помог чем-то соискателям, а не компании.
Стоит начать с того, что буткамп — это не испытание кандидата, а адаптация нового сотрудника. Буткамперы получают зарплату, о которой договорились. В Буткампе они могут пощупать задачи разных команд, познакомиться с будущими коллегами из этих команд, узнать общие техники и традиции компании. За 3 месяца человек может выбрать тот проект, который ему интересен, учесть личное отношение и атмосферу каждой команды.
Про собеседования: гильдия проводит 1 собеседование по 3 секциям. Плюс 1 финальное собеседование. Всего 2, вместо 5-8. Для опытных разработчиков, которые претендуют на особые условия, есть еще одно особое собеседование. Итого, у опытных — 3 собеседования.
Не все новые сотрудники проходят буткамп, есть те, которые идут сразу ради какого-то проекта.
Из плюсов:
- меньше собеседований,
- возможность выбрать подходящую команду и интересные задачи,
- плавная адаптация к новой работе (про то, зачем нужна адаптация и что это такое, думаю не нужно писать).
- креш-курс, где можно прокачать навыки.
А сколько интерьвю в результате проходит кандидат и сколько времени это занимает в новом процессе?
Если больше 1-2 интервью и 3 часов, то вы ничего не изменили в итоге… Если за 2 часа вы не можете понять подходит вам человек или нет, то вам нужно менять HR и тех, кто проводит техническое интервью. Как вариант вводить систему оценок с проходным баллом и возможностью интервьюверов давать дополнительные баллы за общее положительное или отрицательное впечатление, которое кандидат произвёл.
Если больше 1-2 интервью и 3 часов, то вы ничего не изменили в итоге… Если за 2 часа вы не можете понять подходит вам человек или нет, то вам нужно менять HR и тех, кто проводит техническое интервью. Как вариант вводить систему оценок с проходным баллом и возможностью интервьюверов давать дополнительные баллы за общее положительное или отрицательное впечатление, которое кандидат произвёл.
В среднем проходит 2-3 собеседования, около 4-6 часов в общей сложности. Собеседования проходят в разные дни, как удобнее кандидату.
Честно говоря, даже меня на должность копирайтера тестили столько же времени, еще и тестовые были всегда. И не только в Контур, но и на предыдущие места работы. Лично мне не кажется это слишком долгим процессом. Если я выбираю работу, я хочу быть уверена, что подхожу компании, а компания подходит мне.
Честно говоря, даже меня на должность копирайтера тестили столько же времени, еще и тестовые были всегда. И не только в Контур, но и на предыдущие места работы. Лично мне не кажется это слишком долгим процессом. Если я выбираю работу, я хочу быть уверена, что подхожу компании, а компания подходит мне.
Это много! Представьте что кандидат работает и хочет сменить работу (а у большинства хороших кандидатов именно так), он разослал резюме в 3-4 конторы и каждая из них проводит такие издевательские собеседования… 4*6 = 24 часа + подготовка, время на дорогу и т.д. получается что минимум 1 рабочая неделя уходит… (а ведь всё это происходит в рабочее время, а значит кандидат либо должен использовать отпуск, либо ещё как-то выкручиваться). Я уже писал выше, что если вы не можете понять за 2 часа подходит вам человек или нет, то значит вы не то спрашиваете или не на то смотрите… К тому же внимательное изучение резюме и профиля в LinkedIn поможет избежать ненужных вопросов, а разговор о предыдущих проектах покажет реальный опыт кандидата. Ещё одна важная вещь: спрашивайте то, что вы реально используете в своей работе. Если, к примеру, вы пишите API, то спрашивайте по API, а не про то как реализовать сортировку пузырьком в двухсвязанном списке…
Следующим этапом будет улучшение сервиса саппорта :) с написанием статьи — «как мы сделали по человечьи». Пишу как клиент :) Вернитесь в реальность!
По первой части это, конечно, кошмар. С таким подходом можно нанять только очень мотивированных студентов. Любой уважающий себя профи исчезнет с горизонта после 2 интервью.
А вот вторая часть выглядит отлично. Как по мне, это неплохой подход, который дает возможность и адаптироваться, и выбрать направление работы более-менее по душе. Причем без изнасилования мозга разработчика.
И спасибо, что поделились опытом. Думаю многим работодателям есть куда расти, и такой подход был бы очень неплох.
А вот вторая часть выглядит отлично. Как по мне, это неплохой подход, который дает возможность и адаптироваться, и выбрать направление работы более-менее по душе. Причем без изнасилования мозга разработчика.
И спасибо, что поделились опытом. Думаю многим работодателям есть куда расти, и такой подход был бы очень неплох.
2Автор, Извините за hard
ИМХо у Вас такая большая текучка в первый год вовсе не потому что буткамп/не буткамп.
Другая специфика отбора это просто другая воронка попадающих к Вам на работу.
А почему люди бегут это просто:
Недавно был анонимный запрос на хабре который показал правду — потолок з/п среднестатистический у Вас 105. При том что за него надо пахать как раб на галерах.
При том что в Москве с улицы берут на 150. Конечно Екат не Москва, но и здесь ГИКи не глупые и пахать как ВВП будут от 130/150. Тем более что предложений для профи полно — тот же Яндекс и другие федеральные/европейские ИТ конторы — с десяток уж или больше их расплодилось.
И пока Ваше руководство мечтает построить на Широкой речке Силиконовую долину по сути при таких з/п Вы просто старт для студентов.
ИМХо у Вас такая большая текучка в первый год вовсе не потому что буткамп/не буткамп.
Другая специфика отбора это просто другая воронка попадающих к Вам на работу.
А почему люди бегут это просто:
Недавно был анонимный запрос на хабре который показал правду — потолок з/п среднестатистический у Вас 105. При том что за него надо пахать как раб на галерах.
При том что в Москве с улицы берут на 150. Конечно Екат не Москва, но и здесь ГИКи не глупые и пахать как ВВП будут от 130/150. Тем более что предложений для профи полно — тот же Яндекс и другие федеральные/европейские ИТ конторы — с десяток уж или больше их расплодилось.
И пока Ваше руководство мечтает построить на Широкой речке Силиконовую долину по сути при таких з/п Вы просто старт для студентов.
Буткамп это конечно здорово, но во сколько это обходится компании? Вы уверены что эти расходы окупаются? Очень интересно, оценивали ли вы это с экономической точки зрения и как?
Я попросила ответить на этот вопрос Лиду Самкову, руководителя IT HR. Вот что она пишет:
— Эти расходы окупаются, так как сокращаются другие и на выходе получается больше профита и для компании, и для новичка. К нам стало выходить больше разработчиков, а уходят меньше. Раньше каждая команда тратила свое время на ввод нового сотрудника, на обучение его общеконтуровским практикам, инструментам и решениям, этот процесс не был централизован. По факту, новичок начинал приносить отдачу спустя 3 месяца. А в течение первого года, в случае несовпадения ожиданий и реальности, мог уйти. И все вложенные усилия команды, как будто были зря.
Сейчас обучение общеконтуровским практикам проходит на старте и централизовано, команды уже практически не тратят на это время, на стажировку приходит подготовленный человек. Плюс мы научились давать новичкам реальные и завершаемые задачи. т.е. даже если буткампер выберет другую команду, он за несколько недель успел принести некий профит той, в которой стажировался. И сейчас, по окончании буткампа, команда получает человека максимально замотивированного на решение ее задач. Т.е. риск ухода в течение скорого времени сильно снижается. Новичок принимал решение не на основе рассказов о команде и задачах, которые случайно можно передать и воспринять через призму. А на основе своих реальных ощущений, он поработал в команде, он потрогал руками задачи, он увидел своими глазами реальную картинку.
— Эти расходы окупаются, так как сокращаются другие и на выходе получается больше профита и для компании, и для новичка. К нам стало выходить больше разработчиков, а уходят меньше. Раньше каждая команда тратила свое время на ввод нового сотрудника, на обучение его общеконтуровским практикам, инструментам и решениям, этот процесс не был централизован. По факту, новичок начинал приносить отдачу спустя 3 месяца. А в течение первого года, в случае несовпадения ожиданий и реальности, мог уйти. И все вложенные усилия команды, как будто были зря.
Сейчас обучение общеконтуровским практикам проходит на старте и централизовано, команды уже практически не тратят на это время, на стажировку приходит подготовленный человек. Плюс мы научились давать новичкам реальные и завершаемые задачи. т.е. даже если буткампер выберет другую команду, он за несколько недель успел принести некий профит той, в которой стажировался. И сейчас, по окончании буткампа, команда получает человека максимально замотивированного на решение ее задач. Т.е. риск ухода в течение скорого времени сильно снижается. Новичок принимал решение не на основе рассказов о команде и задачах, которые случайно можно передать и воспринять через призму. А на основе своих реальных ощущений, он поработал в команде, он потрогал руками задачи, он увидел своими глазами реальную картинку.
Sign up to leave a comment.
Хакнули систему: как мы изменили подбор и адаптацию разработчиков