6 октября в рамках конференции RubyRussia был проведен круглый стол «Хайринг, хантинг, обучение и развитие рубистов. HR-уголок». Более 30 участников собралось поговорить о наболевшем: собеседования, найм, адаптацию и развитие сотрудников. В круглом столе участвовали эйчары, тимлиды, технические директора — все, кто причастен к hr-процессам в компании.
В этой статье мы хотим поделиться с вами основными поинтами и самыми горячими дискуссиями с этого мероприятия.
Начнем с тех вопросов, в которых мнения участников сошлись.
Изменилось значение на рынке труда некоторых критериев отбора, которые много лет были важными. Например, еще лет 5 назад много внимания обращали на:
Когда-то «летунами» считали тех, кто работал меньше трех лет на одном месте. Сейчас этот срок сократился до года и даже меньше. Высшее техническое/математическое образование стало скорее дополнительным плюсом, чем конкурентным преимуществом. Значительно снизился порог перехода в IT из других отраслей: если раньше после 30 лет перейти «из сейлов в программисты» было почти невозможно, то сейчас это довольно частый кейс.
Шок-контент: единодушно был найден главный критерий того, попадет человек в компанию или нет! Это не владение конкретным языком/фреймворком, не высшее образование и не стаж работы по профессии, а «общая адекватность» и желание развиваться в отрасли. «Общая адекватность» — термин максимально неопределенный, но каждый из присутствовавших точно понимал, о чем идет речь.
Так как в каждой команде «общая адекватность» определяется индивидуально,
очень важно, чтобы эйчар и нанимающий лид были сыгранной командой. Участникам удалось сформулировать «секрет» успеха в эффективного найма:
Все начинается с совместного определения требований к этой позиции, какие качества будут обязательными, а какие отходят на второй план. Очень хорошо, когда эйчар сидит в том же месте, где и разработчики, постоянно контактирует с ними, понимает их задачи, боли, особенности взаимодействия внутри команды. У такого эйчара есть все шансы почувствовать, какой человек нужен, каких людей надо побольше, каких не надо. Важно осмысленное присутствие эйчара на технических собеседованиях. Наблюдение за тем, кого отбирает техдир, за теми, кто ему нравится, какие вопросы он задает и какие ответы «принимаются в зачет» значительно облегчает эйчару этап первичного отбора, а для нанимающих лидов сокращает время на собеседования с совсем уж неподходящими ребятами. Еще один полезный способ определиться с содержанием понятия «общая адекватность», если ваша компания пока не готова наворачивать внутри себя матрицы компетенций, — это «анализ» уже существующих членов команды: «Вот Вася, он классный, потому что он ведет себя вот так, вот так и вот так. А вот был у нас Федя, он делал вот так и вот так, поэтому мы очень обрадовались, когда он ушел. Давайте искать таких, как Вася и не пускать к нам таких, как Федя».
Поделились и примерами нежелательного (и удивительного для работодателя) поведения кандидата. То, что раздражает всех нанимающих специалистов:
Удивительно, что вполне понятные нормы поведения на практике оказываются понятными не для всех. Давайте на всякий случай озвучим их еще раз: для работодателя хорошим тоном считается указывать вилку зарплаты в тексте вакансии, для кандидата считается нормальным уточнить вилку, если она не была указана или разбег был слишком большим, но делать это надо в середине/конце сессии Q&A c компанией.
С софтскилами разобрались. Но в конце концов, мы нанимаем программистов. Как проверить техническую квалификацию кандидата? Все были единодушны только в том, что нельзя нанимать разработчика, не посмотрев, как он пишет код. Совершенно неуникальным оказался случай, когда на собеседовании кандидат хорошо объясняет, как в теории это необходимо написать, но когда дело доходит до практики — не справляется.
Как правильно «посмотреть код у кандидата» — вопрос, не имеющий однозначного решения. Некоторые представители компаний отказались от тестового для джунов, как от бесполезной траты времени. Некоторые, наоборот, считают, что главное в тестовом — это чтобы соискатель его поделал, а потом можно сесть и обсудить с ним ход его мыслей и рассуждений. У кого-то принято давать в качестве тестового задания посмотреть чей-нибудь пул реквест, кто-то наоборот не готов показывать код всем соискателям, а только финалистам. Соискатели со своей стороны тоже не всегда готовы делать «боевые» задачи (пусть небольшие), потому что подозревают работодателей в нечистоплотности и желании «бесплатно» получить фичу за счет кандидата.
Оптимальным способом проверить код признали live-кодинг прямо на собеседовании. При этом важно сохранить «общую адекватность» и пишущим, и проверяющим. Пресловутое «напишите на салфетке алгоритм сортировки пузырьком» раздражает большинство кандидатов и не всегда коррелирует с реальными навыками коммерческого программирования. Адекватные работодатели всегда делают поправку на стрессовость ситуации лайв-кодинга и не придираются к мелочам, а смотрят на ход размышлений.
Все участники стола согласились, что очень круто, когда после обратной связи о недостаточном уровне знаний и сообщении об отказе, кандидат делает выводы и возвращается через некоторое время уже прокачанным в ту же компанию.
Испытательный срок — время, используемое для проверки обоюдной совместимости для работодателя и кандидата. Во время испытательного срока, как кандидат, так и компания лучше раскрываются друг другу. Что-то, что не разгляделось на собеседовании, может обнаружиться на этом этапе.
Все признают, что адаптация — это очень важный процесс в компании. Кто-то, делая выводы из своего предыдущего опыта, как соискателя, старается не давать первым дням новичка превратиться в ад. У кого-то в компании заведены разговоры по душам раз в месяц. Это позволяет узнать, как человеку живется в компании, что он узнал за это время, как развивается. Надо уделять новому сотруднику достаточно времени, чтобы он понимал, какой его проект, как к нему подступиться, с кем ему предстоит работать. делать так, чтобы сотруднику было максимально комфортно в первые дни — важная задача непосредственного руководителя.
Самый жаркий спор разгорелся на тему гуманно ли вводить неоплачиваемую или низкооплачиваемую стажировку в компании. До рукоприкладства не дошло, зато договорились, что стажировка поможет удовлетворить потребности обеих сторон, как соискателей, так и работодателей. К эйчарам каждый день приходят письма кандидатов с маленьким опытом или совсем без него с просьбами взять на работу, чтобы поучиться и практически «за еду». Стажировка поможет посмотреть энтузиазм кандидата и его способности, а работодателю поможет привлечь соискателей, присмотреться к ним и остаться с теми, кого они готовы растить, и всё это за сравнительно небольшие затраты на ФОТ.
Вообще о развитии разработчиков говорили много. Боль у всех одна: «пирамида профессионалов» на входе в компанию. Очень легко нанять 10 джунов, но гораздо сложнее (да и часто не нужно) нанять 10 миддлов, а тем более 10 синьоров. Особенно, когда в отрасли нет единого и строгого понимания, как правильно навешивать эти лейблы на людей. Несмотря на это, большинство участников довольно четко может разделить всё множество разработчиков на 2 подмножества: «кодеры» и «инженеры». Первые — это такие работяги от IT, которые могут быстро, качественно и много решать определенный круг типичных задач. Вторые — те, кто могут мыслить более масштабно и более абстрактно, продумывать архитектуры, строить системы. К сожалению, не все могут перейти из кодеров в инженеры. И одна из горячих тем обсуждения была о том, как отличить неопытного инженера от опытного кодера, кого из них и как надо выращивать в компании.
Чаще всего работодатели принимают решение растить профессионалов внутри себя (и как показывает практика и статистика — это лучший путь). Но серебряной пули, конечно же, нет. Частый, но не всегда однозначный состав команды — 1 синьор, под которым 2-5 джуниоров «на вырост». Минус такой конфигурации в том, что единственным человеком, который несет ответственность и за команду, и за проект — остается этот синьор. И он либо развивает продукт, либо развивает людей. В любом случае, для компании это получается затратная история. Поиск золотой середины между этими полюсами — основная задача управления человеческими ресурсами компании. И, как показало обсуждение, это вопрос не всегда только про то, кого чему учить, но и про «человека на своем месте», про правильную организацию процесса разработки и распределения подходящих задач подходящему человеку.
К сожалению, время круглого стола закончилось раньше, чем закончились вопросы и идеи для обсуждения. Тема ушла в кулуары и в эту статью.
Большое спасибо всем, кто принял участие в этом формате. Если у кого-то есть желание продолжить публичное обсуждение темы хайринга и развития рубистов, не дожидаясь RubyRussia 2019, пишите на js@evrone.com, замутим круглостольный митап.
В этой статье мы хотим поделиться с вами основными поинтами и самыми горячими дискуссиями с этого мероприятия.
Как компании выбирают кандидатов
Начнем с тех вопросов, в которых мнения участников сошлись.
Изменилось значение на рынке труда некоторых критериев отбора, которые много лет были важными. Например, еще лет 5 назад много внимания обращали на:
- профильное образование программиста;
- продолжительность работы на одном месте;
- предыдущие специальности (если они были).
Когда-то «летунами» считали тех, кто работал меньше трех лет на одном месте. Сейчас этот срок сократился до года и даже меньше. Высшее техническое/математическое образование стало скорее дополнительным плюсом, чем конкурентным преимуществом. Значительно снизился порог перехода в IT из других отраслей: если раньше после 30 лет перейти «из сейлов в программисты» было почти невозможно, то сейчас это довольно частый кейс.
Шок-контент: единодушно был найден главный критерий того, попадет человек в компанию или нет! Это не владение конкретным языком/фреймворком, не высшее образование и не стаж работы по профессии, а «общая адекватность» и желание развиваться в отрасли. «Общая адекватность» — термин максимально неопределенный, но каждый из присутствовавших точно понимал, о чем идет речь.
Так как в каждой команде «общая адекватность» определяется индивидуально,
очень важно, чтобы эйчар и нанимающий лид были сыгранной командой. Участникам удалось сформулировать «секрет» успеха в эффективного найма:
Все начинается с совместного определения требований к этой позиции, какие качества будут обязательными, а какие отходят на второй план. Очень хорошо, когда эйчар сидит в том же месте, где и разработчики, постоянно контактирует с ними, понимает их задачи, боли, особенности взаимодействия внутри команды. У такого эйчара есть все шансы почувствовать, какой человек нужен, каких людей надо побольше, каких не надо. Важно осмысленное присутствие эйчара на технических собеседованиях. Наблюдение за тем, кого отбирает техдир, за теми, кто ему нравится, какие вопросы он задает и какие ответы «принимаются в зачет» значительно облегчает эйчару этап первичного отбора, а для нанимающих лидов сокращает время на собеседования с совсем уж неподходящими ребятами. Еще один полезный способ определиться с содержанием понятия «общая адекватность», если ваша компания пока не готова наворачивать внутри себя матрицы компетенций, — это «анализ» уже существующих членов команды: «Вот Вася, он классный, потому что он ведет себя вот так, вот так и вот так. А вот был у нас Федя, он делал вот так и вот так, поэтому мы очень обрадовались, когда он ушел. Давайте искать таких, как Вася и не пускать к нам таких, как Федя».
Поделились и примерами нежелательного (и удивительного для работодателя) поведения кандидата. То, что раздражает всех нанимающих специалистов:
- общая агрессивность,
- ненужные споры,
- вопросы в духе «А теперь вопросы задаю я»
- вопрос о зарплате в качестве самого первого встречного вопроса о компании
Удивительно, что вполне понятные нормы поведения на практике оказываются понятными не для всех. Давайте на всякий случай озвучим их еще раз: для работодателя хорошим тоном считается указывать вилку зарплаты в тексте вакансии, для кандидата считается нормальным уточнить вилку, если она не была указана или разбег был слишком большим, но делать это надо в середине/конце сессии Q&A c компанией.
С софтскилами разобрались. Но в конце концов, мы нанимаем программистов. Как проверить техническую квалификацию кандидата? Все были единодушны только в том, что нельзя нанимать разработчика, не посмотрев, как он пишет код. Совершенно неуникальным оказался случай, когда на собеседовании кандидат хорошо объясняет, как в теории это необходимо написать, но когда дело доходит до практики — не справляется.
Как правильно «посмотреть код у кандидата» — вопрос, не имеющий однозначного решения. Некоторые представители компаний отказались от тестового для джунов, как от бесполезной траты времени. Некоторые, наоборот, считают, что главное в тестовом — это чтобы соискатель его поделал, а потом можно сесть и обсудить с ним ход его мыслей и рассуждений. У кого-то принято давать в качестве тестового задания посмотреть чей-нибудь пул реквест, кто-то наоборот не готов показывать код всем соискателям, а только финалистам. Соискатели со своей стороны тоже не всегда готовы делать «боевые» задачи (пусть небольшие), потому что подозревают работодателей в нечистоплотности и желании «бесплатно» получить фичу за счет кандидата.
Оптимальным способом проверить код признали live-кодинг прямо на собеседовании. При этом важно сохранить «общую адекватность» и пишущим, и проверяющим. Пресловутое «напишите на салфетке алгоритм сортировки пузырьком» раздражает большинство кандидатов и не всегда коррелирует с реальными навыками коммерческого программирования. Адекватные работодатели всегда делают поправку на стрессовость ситуации лайв-кодинга и не придираются к мелочам, а смотрят на ход размышлений.
Все участники стола согласились, что очень круто, когда после обратной связи о недостаточном уровне знаний и сообщении об отказе, кандидат делает выводы и возвращается через некоторое время уже прокачанным в ту же компанию.
Адаптация и развитие
Испытательный срок — время, используемое для проверки обоюдной совместимости для работодателя и кандидата. Во время испытательного срока, как кандидат, так и компания лучше раскрываются друг другу. Что-то, что не разгляделось на собеседовании, может обнаружиться на этом этапе.
Все признают, что адаптация — это очень важный процесс в компании. Кто-то, делая выводы из своего предыдущего опыта, как соискателя, старается не давать первым дням новичка превратиться в ад. У кого-то в компании заведены разговоры по душам раз в месяц. Это позволяет узнать, как человеку живется в компании, что он узнал за это время, как развивается. Надо уделять новому сотруднику достаточно времени, чтобы он понимал, какой его проект, как к нему подступиться, с кем ему предстоит работать. делать так, чтобы сотруднику было максимально комфортно в первые дни — важная задача непосредственного руководителя.
Самый жаркий спор разгорелся на тему гуманно ли вводить неоплачиваемую или низкооплачиваемую стажировку в компании. До рукоприкладства не дошло, зато договорились, что стажировка поможет удовлетворить потребности обеих сторон, как соискателей, так и работодателей. К эйчарам каждый день приходят письма кандидатов с маленьким опытом или совсем без него с просьбами взять на работу, чтобы поучиться и практически «за еду». Стажировка поможет посмотреть энтузиазм кандидата и его способности, а работодателю поможет привлечь соискателей, присмотреться к ним и остаться с теми, кого они готовы растить, и всё это за сравнительно небольшие затраты на ФОТ.
Вообще о развитии разработчиков говорили много. Боль у всех одна: «пирамида профессионалов» на входе в компанию. Очень легко нанять 10 джунов, но гораздо сложнее (да и часто не нужно) нанять 10 миддлов, а тем более 10 синьоров. Особенно, когда в отрасли нет единого и строгого понимания, как правильно навешивать эти лейблы на людей. Несмотря на это, большинство участников довольно четко может разделить всё множество разработчиков на 2 подмножества: «кодеры» и «инженеры». Первые — это такие работяги от IT, которые могут быстро, качественно и много решать определенный круг типичных задач. Вторые — те, кто могут мыслить более масштабно и более абстрактно, продумывать архитектуры, строить системы. К сожалению, не все могут перейти из кодеров в инженеры. И одна из горячих тем обсуждения была о том, как отличить неопытного инженера от опытного кодера, кого из них и как надо выращивать в компании.
Чаще всего работодатели принимают решение растить профессионалов внутри себя (и как показывает практика и статистика — это лучший путь). Но серебряной пули, конечно же, нет. Частый, но не всегда однозначный состав команды — 1 синьор, под которым 2-5 джуниоров «на вырост». Минус такой конфигурации в том, что единственным человеком, который несет ответственность и за команду, и за проект — остается этот синьор. И он либо развивает продукт, либо развивает людей. В любом случае, для компании это получается затратная история. Поиск золотой середины между этими полюсами — основная задача управления человеческими ресурсами компании. И, как показало обсуждение, это вопрос не всегда только про то, кого чему учить, но и про «человека на своем месте», про правильную организацию процесса разработки и распределения подходящих задач подходящему человеку.
К сожалению, время круглого стола закончилось раньше, чем закончились вопросы и идеи для обсуждения. Тема ушла в кулуары и в эту статью.
Большое спасибо всем, кто принял участие в этом формате. Если у кого-то есть желание продолжить публичное обсуждение темы хайринга и развития рубистов, не дожидаясь RubyRussia 2019, пишите на js@evrone.com, замутим круглостольный митап.
