У нас 5 продуктовых и 5 платформенных кластеров. Описанный в статье процесс используется только в одном из них (С2С). И то это скорее фреймворк, а не строгий процесс. Команды его использующие могут менять структуру вопросов и задачи в рамках секций. Могут добавлять свои секции. В общем адаптируют фреймворк, оставляя общую структуру и идею каждого блока.
В моем кластере (Verticals) похожая но не точно такая же схема. У нас тоже есть скрининг по телефону/скайпу, делают его инженеры и мы стараемся уложиться в 30 минут на все (знакомство + наши вопросы + вопросы кандидата). Потом техническое интервью, 2 часа с похожим набором секций. И финал HR + менеджер для проверки soft-skills и прояснения оставшихся вопросов 1.5 часа.
В общем набор секций примерно одинаковый у всех, но каждый кластер адаптирует все под себя и внутри кластера команды еще могут тоже что-то менять. Так что наш процесс ближе к микросервисам, чем монолиту :)
Про метрики на которые смотрели ребята не отвечу, возможно у StanYurk есть детали.
Я не проверял с линейкой, мне удобно сидеть этого достаточно. Если вам это важно, попросите после интервью показать ваше рабочее место и проверьте удобство. Я знаю кандидатов которые так делали и вроде все довольны остались.
В этом случае все тратят свое время зря, в том числе компания. Но время которое мы тратим на интервью сильно меньше чем время которое мы потратим на адаптацию человека. В случае если он уйдет мы опять должны будем потратить время на поиск и адаптацию нового разработчика. Получается в случае вашего увольнения по время испытательного срока, компания несет двойные потери в отличие от вас. Поэтому и появляются все эти этапы. Кажется что времени тратиться много, но если сравнить с возможными потерями, то не так уж и много.
Вы наверное имели ввиду этап с задачками, потому что тестовые задания (то что надо делать дома) мы не практикуем на позиции разработчиков.
В любом случае, мы такой подход не практикуем и ссылки на свои проекты на github кандидаты нам присылают не так часто как хотелось бы. По моим ощущениям это 1-2 кандидата из 10-ти. Но мы подумаем над такой опцией.
У нас все рабочие места соответствуют стандартам. Не только по размерам, но и по освещенности и электробезопасности. По последним двум пунктам регулярные замеры и проверки делаются.
Ну и как человек сидящий за одним из таких столов как на фоточке, могу сказать что они не маленькие и не узкие. Хватает места и для ног под столом и на столе для рюкзака и для одного двух дополнительных мониторов.
Задачки это только одна часть. Можно научиться решать задачки но завалится на вопросах по архитектуре. На этой секции мы даем какие-то интересные задачки на проектирование какого-то сервиса или продукта. Например фронтенд или мобильных разработчиков можем попросить спроектировать мессенджер. Бэкэндеров попросить спроектировать сервис типа твитера или высоконагруженный сервис.
Ну и по резюме и на последней секции интервью видно какой реально опыт был у кандидата.
По программированию обычно нет. Но по архитектурным вопросам да. И на общий технический кругозор тоже смотрим.
Правда тут есть исключения. На некоторых менеджерских позициях может быть секция по программированию если для команды важно чтобы их начальник писал код на равне с ними, иначе они могут его не принять.
Если это никак не сказывается на его работе, то подходит. Но тут речь не про любовь к Авито, а к тому чем ты занимаешься, к программированию и созданию крутых вещей. Если человек может писать прекрасный качественный код, не токсичен к команде, постоянно приходит с интересными идеями по улучшению продукта, но при этом в душе ненавидит Авито, то мы наверное никогда про это не узнаем и будем рады видеть его в своей команде :)
Формулировка не очень удачная. Резюме это опорная точка от которой строиться диалог. Вместо абстрактных вопросов «как бы вы поступили в ситуации Х», мы смотрим на то какой опыт был у кандидата на предыдущих местах работы. С какими ситуациями он сталкивался, как их решал. На вопросы про предыдущий опыт проще отвечать, и они лучше раскрывают кандидата.
Вы нашли фотографию рабочего места ребят из команды it-support. Они выдают людям ноубуки, мониторы, мышки и поддерживают всю it инфрастуктуру офиса :) Вот пример рабочих мест разработчиков.
А проблему шума неплохо решают стеклянные шумо-поглащающие перегородки между несколькими рядами. Если присмотреться их видно на этом фото.
Ни с каких, я ровно об этом и говорю. Хорошая зарплата это минимальная база, но мы хотим чтобы кандидат кроме своей зарплаты любил и свою работу. Бывают люди которым всеравно что они делают, лишь бы деньги платили. Бывают те кому важно над чем они работают не меньше чем зарплата которую они получают. А еще бывают такие которым вообще не важно сколько денег, лишь бы делать то что им нравится.
i360u а как в вашей компании проводятся интервью? Как вы проверяете hard-skills кандидата? Я в своей практике ничего лучше практических задачек пока не видел и не придумал.
Да именно про это StanYurk и говорит. Мы не меняем горящие глаза на маленькую зарплату. Мы даем достойную зарплату на рынке, но в дополнении к ней хотим чтобы кандидат разделял наши подходы к работе, в частности Agile и Scrum. Смысл этого довольно прагматичный, если человеку будет не комфортно с нами и он будет себя заставлять сидеть на работе за хорошую зарплату, то он очень быстро перегорит и уйдет от нас. А мы как компания уже потратили много времени на его поиск и адаптацию и будем вынуждены потратить это время снова.
Последний этап интервью с HR и руководителем, это как раз про soft-skills. Разговор строится на основе предыдущего опыта кандидата. Спрашиваем над какими проектами и главное как работал, какая была команда, какая у него было роль в команде, что нравилось, чего хочется от нового места и т.п.
На техническом интервью мы смотрим на hard-skills, на интервью с HR и руководителем на soft-skills. Почему эта секция в конце? Во-первых, потому что отсев по hard-skills гораздо выше. Во-вторых, потому что требования по hard-skills у нас примерно одинаковые во всей компании, а по soft-skills кандидат может не подойти в конкретную команду, или кандидату самому не понравится то чем придется заниматься. Тогда если есть открытые вакансии в других командах, мы можем предложить ему что-то еще.
Вы как то не так трактуете то что StanYurk написал. Мы как раз таки ищем сантехников которые умеют спроектировать и собрать коллекторный узел. Но в дополнение к этому хотим что бы сантехник любил свою работу и делал ее хорошо, чтобы он смотрел что делают другие сантехники и вместо устаревших железных труб собирал нам коллектор из сшитого полипропилена и меди с правильным набором редукторов, фильтров, кранов и гребенок.
Как правило люди которые только «сидят в офисе от смски до смски с зачислением зп» не интересуются ничем вокруг, у них очень узкий кругозор. Поэтому любовь к смскам с ЗП, это для нас это обязательна (а кто их не любит? :) ) но не достаточно для того чтобы мы приняли положительное решение.
То что вы описываете больше похоже на путь разработчика, чем руководителя. Принципы управления программистами меняются не так быстро и сейчас все еще актуальны книжки написанные в 70-е годы. Например тот же Брукс и его Мифический человеко-месяц.
Ну и тимлид это не обязательно лучший разработчик в команде. Если есть желание быть тимлидом, то не надо в него расти качая знания в новых технологиях. Там нужны совсем другие навыки.
В моем кластере (Verticals) похожая но не точно такая же схема. У нас тоже есть скрининг по телефону/скайпу, делают его инженеры и мы стараемся уложиться в 30 минут на все (знакомство + наши вопросы + вопросы кандидата). Потом техническое интервью, 2 часа с похожим набором секций. И финал HR + менеджер для проверки soft-skills и прояснения оставшихся вопросов 1.5 часа.
В общем набор секций примерно одинаковый у всех, но каждый кластер адаптирует все под себя и внутри кластера команды еще могут тоже что-то менять. Так что наш процесс ближе к микросервисам, чем монолиту :)
Про метрики на которые смотрели ребята не отвечу, возможно у StanYurk есть детали.
В любом случае, мы такой подход не практикуем и ссылки на свои проекты на github кандидаты нам присылают не так часто как хотелось бы. По моим ощущениям это 1-2 кандидата из 10-ти. Но мы подумаем над такой опцией.
Ну и как человек сидящий за одним из таких столов как на фоточке, могу сказать что они не маленькие и не узкие. Хватает места и для ног под столом и на столе для рюкзака и для одного двух дополнительных мониторов.
Ну и по резюме и на последней секции интервью видно какой реально опыт был у кандидата.
Правда тут есть исключения. На некоторых менеджерских позициях может быть секция по программированию если для команды важно чтобы их начальник писал код на равне с ними, иначе они могут его не принять.
А проблему шума неплохо решают стеклянные шумо-поглащающие перегородки между несколькими рядами. Если присмотреться их видно на этом фото.
Как правило люди которые только «сидят в офисе от смски до смски с зачислением зп» не интересуются ничем вокруг, у них очень узкий кругозор. Поэтому любовь к смскам с ЗП, это для нас это обязательна (а кто их не любит? :) ) но не достаточно для того чтобы мы приняли положительное решение.
Ну и тимлид это не обязательно лучший разработчик в команде. Если есть желание быть тимлидом, то не надо в него расти качая знания в новых технологиях. Там нужны совсем другие навыки.