Комментарии 101
Мы считаем, что чем выше уровень специалиста, тем более тщательным должен быть отбор.
Не претендую на истину в последней инстанции, но в моем случае получается все ровно наоборот: чем больше опыта тем меньше собеседований.
Если резюме покрывает >10 лет профессионального опыта то этого достаточно чтобы оценить кандидата.
Кроме того есть еще груз «косвенных» свидетельств комптентности в виде патентов, публикаций, дипломов, сертификатов и прочего.
В моем случае сложнее всего было получить первое и второе места работы а на последнее я попал вообще без технического интервью (программист).
может имеется ввиду, тех у кого всего этого нету в общем доступе, и метят на высокую должность?
Думаю что нет, потому что следующей строкой отсыл к техническому интервью.
Если набирают принципла или тимлида то это будет на мой взгляд лишним, а если >тимлида то и вовсе попыткой троллинга.
В секции программирования мы просим решать задачи на алгоритмы. Да, на листочках...
Если набирают принципла или тимлида то это будет на мой взгляд лишним, а если >тимлида то и вовсе попыткой троллинга.
Я так полагаю они хвастаются «как мы унижаем сеньёров»?
Надо учитывать, что у Авито большой поток желающих попасть в компанию, поэтому они могут позволить себе сделать отбор строгим и принимать решение в пользу наиболее квалифицированных на их взгляд специалистов. Такой же процесс в 4 секции у Яндекса, у которого, думаю, тоже нет проблем с откликом на вакансии
Имеют право, НО
Фишка собеседования не обязательно в том чтобы заполучить «самого лучшего». По моим наблюдениям лучший рано или поздно заканчивает в компаниях FAANG а другие компании использует исключительно в кач. прыжковой доски, от таких «выхлопа» будет не много. Важно заполучить грамотного+лояльного специалиста. Иначе будет текучка а компания будет заниматься подготовкой кадров для FAANG.
Фишка собеседования не обязательно в том чтобы заполучить «самого лучшего». По моим наблюдениям лучший рано или поздно заканчивает в компаниях FAANG а другие компании использует исключительно в кач. прыжковой доски, от таких «выхлопа» будет не много. Важно заполучить грамотного+лояльного специалиста. Иначе будет текучка а компания будет заниматься подготовкой кадров для FAANG.
Мы подходим одинаково внимательно к собеседованиям джунов-мидлов-синьоров и тимлидов с руководителями, никого не унижаем) нам важно оставить хорошее впечатление даже если кандидат нам не подходит.
То есть руководителей таскаете по программированию?
Собеседование на лида и выше:
Напишите ка мне сортировочку пожалуйста
Нуачо, разворачивание деревьев на бумажке уже все выучили :)
Нам точно надо проверить его знания, мы обязательно погоняем по архитектуре 2 часа с ребятами из архитектуры, остальное опционально, но желательно
Иногда хочется — типмлид, большие проекты, руководство командой, а по факту… фиг с деревьями, элементарного анализа провести не может: или я это знаю или в природе не существует, даже предложенный элементарный эксперимент на 30сек провести не могут. Такое, правда, и без кода выяснится, но лучше, если высшее руководство не впечатлится резюме и не наймёт такого вам в начальники.
По программированию обычно нет. Но по архитектурным вопросам да. И на общий технический кругозор тоже смотрим.
Правда тут есть исключения. На некоторых менеджерских позициях может быть секция по программированию если для команды важно чтобы их начальник писал код на равне с ними, иначе они могут его не принять.
Правда тут есть исключения. На некоторых менеджерских позициях может быть секция по программированию если для команды важно чтобы их начальник писал код на равне с ними, иначе они могут его не принять.
А что хорошего в Авито? Ну Яндекс, говорят, платят так себе, но ради строчки в резюме и опыта туда идти может.
Не думаю, что в Avito именно «унижают» на интервью.
Пару раз мне попадались интервьюеры, которые ставят целью не узнать твой опыт и знания, а самоутвердится за счет тебя. Обычно это начинается, когда ты успешно ответил на все вопросы из подготовленного списка и довольно легко решил практические задачи.
Если проходить интервью довольно быстро, отвечая на все вопросы верно, то в человеке начинает играть ревность (или как это назвать), но он начинает именно топить тебя.
Поэтому всем, кто проводит интервью: Коллеги, давайте быть добрее и не «унижать» людей на интервью. Даже если кандидат оказался сильнее вас.
Пару раз мне попадались интервьюеры, которые ставят целью не узнать твой опыт и знания, а самоутвердится за счет тебя. Обычно это начинается, когда ты успешно ответил на все вопросы из подготовленного списка и довольно легко решил практические задачи.
Если проходить интервью довольно быстро, отвечая на все вопросы верно, то в человеке начинает играть ревность (или как это назвать), но он начинает именно топить тебя.
Поэтому всем, кто проводит интервью: Коллеги, давайте быть добрее и не «унижать» людей на интервью. Даже если кандидат оказался сильнее вас.
У нас есть форма обратной связи для кандидатов, не прошедших отбор к нам. Если человек к нам не прошел-это не значит что он плохой или слабый разработчик, просто наши пути не сходятся в данный момент. Мы даем развернутую обратную связь и рады получить такую от кандидатов. Мы ставим цель-закрыть вакансию хорошим специалистом, в наших интересах оставить хорошее впечатление, благодаря этому человек сохранит желание поработать с нами, пользоваться продуктом, рекомендовать нас как работодателя и рекомендовать продукт.
Это все не правда. Рассказываю свой опыт. Год назад меня забрили у вас. Никакой формы мне не прислали, эйчар выдал обычную отписку. При этом собес, по моим ощущениям, прошел хорошо, несмотря на то, что один из собеседующих вел себя неподобающе. Работать или рекомендовать работу в магазине бу вещей желания больше не имею. Теперь работаю в Я.
Это было со мной? Прошу прощения, мог заработаться. Всегда ориентирую, что если не отвечу за неделю-не стесняйтесь меня спросить. Немного обидно сравнение с магазином бу вещей, так как мы работаем не только с этим. Также можете в личку написать кто и на какой секции себя вел не корректно, интервьюеры те же и легко будет все обсудить. Но лучше такое сообщать сразу.
С такими, которые позволят не захотеть писать код на бумажке.
Если человеку совсем не интересен продукт, не подходит командная работа, не готов делиться опытом, заинтересован исключительно в деньгах. Но нам часто удается заинтересовать и замотивировать)
Сейчас вам распишут в комментариях, как вы неправильно собеседуете, и будут правы.
В общем, это опасная практика писать на хабр статьи «как мы собеседуем».
А что, разработчик которому в большинстве интересна зарплата — уже плохой разработчик?
Чем то очень напоминает «почему вы выбрали именно нашу компанию».
В общем, это опасная практика писать на хабр статьи «как мы собеседуем».
Если человеку совсем не интересен продукт, не подходит командная работа, не готов делиться опытом, заинтересован исключительно в деньгах.
А что, разработчик которому в большинстве интересна зарплата — уже плохой разработчик?
Чем то очень напоминает «почему вы выбрали именно нашу компанию».
Мы открытая компания и у нас есть свои ценности, мы проводим много митапов, мероприятий, участвуем в конференциях и ищем людей, которым будет с нами интересно. Безусловно хорошая зп важна для спокойной работы сотрудника, но мы не хотим, чтобы человек сидел в офисе от смски до смски с зачислением зп. Нам важен интерес. Благодаря ему родятся идеи, желание развивать продукт, будет продуктивная командная работа.
Благодаря ему родятся идеи, желание развивать продукт, будет продуктивная командная работа.
Хорошая ЗП не противоречит вышеперечисленному.
Вы когда к врачу на приём идёте, то тоже выбираете врача, которому вы как человек интересен? Или все-таки вам важна его квалификация? Когда сантехника приглашаете спроектировать и собрать вам коллекторный узел вы тоже выбираете того кому будет интересна ваша квалификация? Почему именно в IT все так старательно ищут людей, у которых «глаза горят» вместо тех кто просто хорошо делает свою работу, но при этом хотят они от сотрудников именно что хорошо сделанную работу?
Вы как то не так трактуете то что StanYurk написал. Мы как раз таки ищем сантехников которые умеют спроектировать и собрать коллекторный узел. Но в дополнение к этому хотим что бы сантехник любил свою работу и делал ее хорошо, чтобы он смотрел что делают другие сантехники и вместо устаревших железных труб собирал нам коллектор из сшитого полипропилена и меди с правильным набором редукторов, фильтров, кранов и гребенок.
Как правило люди которые только «сидят в офисе от смски до смски с зачислением зп» не интересуются ничем вокруг, у них очень узкий кругозор. Поэтому любовь к смскам с ЗП, это для нас это обязательна (а кто их не любит? :) ) но не достаточно для того чтобы мы приняли положительное решение.
Как правило люди которые только «сидят в офисе от смски до смски с зачислением зп» не интересуются ничем вокруг, у них очень узкий кругозор. Поэтому любовь к смскам с ЗП, это для нас это обязательна (а кто их не любит? :) ) но не достаточно для того чтобы мы приняли положительное решение.
Вы как то не так трактуете то что StanYurk написал
Ну StanYurk прямым текстом написал, что ему не походят люди, которые
не интересен продукт, не подходит командная работа, не готов делиться опытом, заинтересован исключительно в деньгах.
Как это можно иначе трактовать?
Как правило люди которые только «сидят в офисе от смски до смски с зачислением зп» не интересуются ничем вокруг, у них очень узкий кругозор.А с каких пор желание получать ЗП за свою работу стало признаком человека который «не интересуются ничем вокруг, у них очень узкий кругозор»? С каких пор желание получать ЗП за свою работу вообще стало чем-то предосудительным?
Ни с каких, я ровно об этом и говорю. Хорошая зарплата это минимальная база, но мы хотим чтобы кандидат кроме своей зарплаты любил и свою работу. Бывают люди которым всеравно что они делают, лишь бы деньги платили. Бывают те кому важно над чем они работают не меньше чем зарплата которую они получают. А еще бывают такие которым вообще не важно сколько денег, лишь бы делать то что им нравится.
Т.е. если человек качественно выполняет свою работу, но не испытывает любви к вашему проекту он вам не подходит?
Если это никак не сказывается на его работе, то подходит. Но тут речь не про любовь к Авито, а к тому чем ты занимаешься, к программированию и созданию крутых вещей. Если человек может писать прекрасный качественный код, не токсичен к команде, постоянно приходит с интересными идеями по улучшению продукта, но при этом в душе ненавидит Авито, то мы наверное никогда про это не узнаем и будем рады видеть его в своей команде :)
У нас скрам, дейли стендапы, оупенспейс, решение проблем через коммуникации, умение и желание общаться важно для карьерного роста у нас. Здесь может быть тяжело тем, кому комфортнее получить задачу и работать над ней одному отдельно от всех в широком смысле. Мы ищем людей в компанию, в команду, а не просто винтик, сотрудники для нас очень важны, поэтому мы раскрываем все заранее и на испытательном сроке я всегда спрашиваю-все ли сходится с тем, что мы рассказали или нет.
Им просто нужны командные винтики.
Одна из ценностей Авито-все решается через коммуникации-это легко реализуется, когда сотрудник может подойти к любому и обсудить рабочие моменты. Комфортнее сделать это в едином пространстве. У нас удобный офис, на Хабре есть ссылки и обзор. Можете лично убедиться на экскурсии после митапов.
Мне кажется, это не про смирение. Я работала в разных опенспейсах, тут правда комфортно (и красиво). Если хочется, можно найти тихий уголок (или укрыться в норе).
Вот тут можно посмотреть пост про офис (и в комментариях как раз поднимали тему опенспейса).
Вот тут можно посмотреть пост про офис (и в комментариях как раз поднимали тему опенспейса).
Вы нашли фотографию рабочего места ребят из команды it-support. Они выдают людям ноубуки, мониторы, мышки и поддерживают всю it инфрастуктуру офиса :) Вот пример рабочих мест разработчиков.
А проблему шума неплохо решают стеклянные шумо-поглащающие перегородки между несколькими рядами. Если присмотреться их видно на этом фото.
А проблему шума неплохо решают стеклянные шумо-поглащающие перегородки между несколькими рядами. Если присмотреться их видно на этом фото.
У нас все рабочие места соответствуют стандартам. Не только по размерам, но и по освещенности и электробезопасности. По последним двум пунктам регулярные замеры и проверки делаются.
Ну и как человек сидящий за одним из таких столов как на фоточке, могу сказать что они не маленькие и не узкие. Хватает места и для ног под столом и на столе для рюкзака и для одного двух дополнительных мониторов.
Ну и как человек сидящий за одним из таких столов как на фоточке, могу сказать что они не маленькие и не узкие. Хватает места и для ног под столом и на столе для рюкзака и для одного двух дополнительных мониторов.
У нас скрам, дейли стендапы, оупенспейс
Не вижу смузи, к вам не пойду.
> Во время финальной секции HR вместе с руководителем расспрашивают кандидата по резюме
Не понимаю, какой смысл спрашивать по резюме в самом конце? Обычно с этого все начинают.
Не понимаю, какой смысл спрашивать по резюме в самом конце? Обычно с этого все начинают.
Мы находим резюме, обсуждаем с нанимающим менеджером, проводим скайп, очное интервью и приглашаем на финал, там мы рассказываем о себе и расспрашиваем кандидата. Мы уже имеем представление о человеке и он уже лучше понимает кто мы и что делаем.
Как это отвечает на мой вопрос?)
Сперва мы обсуждаем тех, параллельно до финального этапа я общаюсь с кандидатом и отвечаю на его вопросы (плюшки, оргструктура и тд), в конце уже знакомство с руководителем. Узнаем человека лучше по его резюме, имея уже данные по теху.
Я наверно чего-то не понимаю, но если кандидат уже прошел ваше техническое собеседование и его прохождение вас устроило — какая тогда уже разница, чем он занимался на прошлых местах из резюме?
На техническом интервью мы смотрим на hard-skills, на интервью с HR и руководителем на soft-skills. Почему эта секция в конце? Во-первых, потому что отсев по hard-skills гораздо выше. Во-вторых, потому что требования по hard-skills у нас примерно одинаковые во всей компании, а по soft-skills кандидат может не подойти в конкретную команду, или кандидату самому не понравится то чем придется заниматься. Тогда если есть открытые вакансии в других командах, мы можем предложить ему что-то еще.
А расспрос про резюме — это по-вашеу проверка soft-skills?
Это раскрывает человека, мы расспрашиваем про его прошлые места работы, ситуации, проблемы, пути их решений, моделируем или предлагаем свои реальные истории и в процессе узнаем человека
Формулировка не очень удачная. Резюме это опорная точка от которой строиться диалог. Вместо абстрактных вопросов «как бы вы поступили в ситуации Х», мы смотрим на то какой опыт был у кандидата на предыдущих местах работы. С какими ситуациями он сталкивался, как их решал. На вопросы про предыдущий опыт проще отвечать, и они лучше раскрывают кандидата.
del, не та ветка
Карго культ. Подобые собеседования нужны реально IT-мордоворотам, с большой текучкой/взрывным ростом технологий, проектов и направлений. В РФ, например, Яндекс какой-нибудь, других сходу не назову. Может еще богомерзкий мейлру. В остальных компаниях R&D сильно меньше, ориентированность на конкретный продукт и фичи в формате «нужно сделать ко вчера».
Конкретные спецы вам нужны, которые прохавали много всего на своем опыте. Пусть даже они бывают туговаты местами. А не молодняк, который просто потратил пару недель на тренировку писать задачки на бумажке.
Конкретные спецы вам нужны, которые прохавали много всего на своем опыте. Пусть даже они бывают туговаты местами. А не молодняк, который просто потратил пару недель на тренировку писать задачки на бумажке.
Задачки это только одна часть. Можно научиться решать задачки но завалится на вопросах по архитектуре. На этой секции мы даем какие-то интересные задачки на проектирование какого-то сервиса или продукта. Например фронтенд или мобильных разработчиков можем попросить спроектировать мессенджер. Бэкэндеров попросить спроектировать сервис типа твитера или высоконагруженный сервис.
Ну и по резюме и на последней секции интервью видно какой реально опыт был у кандидата.
Ну и по резюме и на последней секции интервью видно какой реально опыт был у кандидата.
Создалось стойкое ощущение, что люди прочитали Cracking the Coding Interview, но прочитали не все сноски.
В целом, если у вас достаточный поток кандидатов (честно говоря, я немного сомневаюсь в том, что в России сейчас предложение превышает спрос, но может вы платите х2 к рынку и у вас очередь), то можно конечно поиграть в эти игры с многоступенчатыми собеседованиями и программированием на листочке, но в целом, крупные компании могут себе позволить так извращаться с собеседованиями именно потому, что они — глобально лучшие по балансу риск-профит для работника.
В целом то подход рабочий, правда с достаточно большим количеством false negative, но, повторюсь, если можете себе позволить — остается только порадоваться за вас.
В целом, если у вас достаточный поток кандидатов (честно говоря, я немного сомневаюсь в том, что в России сейчас предложение превышает спрос, но может вы платите х2 к рынку и у вас очередь), то можно конечно поиграть в эти игры с многоступенчатыми собеседованиями и программированием на листочке, но в целом, крупные компании могут себе позволить так извращаться с собеседованиями именно потому, что они — глобально лучшие по балансу риск-профит для работника.
В целом то подход рабочий, правда с достаточно большим количеством false negative, но, повторюсь, если можете себе позволить — остается только порадоваться за вас.
Спасибо за статью, было интересно прочитать. А как насчет проверки soft skills? Есть какая-то практика в этом направлении?
Нам интересно понять на сколько мы подходим друг другу. После всех этапов и знакомства с командой это уже понятно обеим сторонам. Кандидата собеседуют те, с кем ему придется работать, у обеих сторон формируется мнение. Мы получаем с обеих сторон отзывы, складываем их в единое целое. Нам интересны командные игроки, которым интересно коммуницировать.
Последний этап интервью с HR и руководителем, это как раз про soft-skills. Разговор строится на основе предыдущего опыта кандидата. Спрашиваем над какими проектами и главное как работал, какая была команда, какая у него было роль в команде, что нравилось, чего хочется от нового места и т.п.
Как бы это странно не звучало, но вот это все про «нам важны люди заинтересованные в продукте, а не деньгах» это либо самообман либо просто самопиар. Уровень зарплаты позволяет покупать мнение разработчиков и вынуждает их говорить что им интересен продукт, заставлять сидеть на ненужных и бесполезных, в большинстве своём, митингов/скрамингов/ретро и прочей эффективно-менеджерской ерунде. Это похвально, я не критикую, просто строить из себя «не таких как все» как минимум наивно и не красиво
Есть мнение, что хорошая зп стимулирует сотрудника первые три месяца, дальше мотивация идет от интереса. К продукту, своим задачам, командным планам. Нам хочется работать с теми, кто разделяет наши интересы.
Есть мнение, что хорошая зп стимулирует сотрудника первые три месяца, дальше мотивация идет от интереса
Это возможно только в случае когда закрыты базовые потребности:
(привет от Маслоу) 
выплачена ипотека, кредиты, хватает на еду, одежду, бензин, на ребенка и раз в год на отпуск в жаркие страны. Вы первые 3 месяца платите достаточно чтобы закрыть ипотеку?
Есть мнение, что есть премии и квартальные бонусы такого размера, чтобы заинтересовать работников в их получении.
«Все мы люди, все мы человеки» и даже при нормальном доходе всегда есть куда потратить еще один оклад.
А вот на счет мотивации из интереса… Не знаю, на сколько остальные разделяют мою позицию, но те, кого я знаю, с ней согласны — интерес просто позволяет работать на каком-либо месте. Без него туда бы и не пришли. Но он вообще никаким образом не перекрывает остальное.
Да и вообще, так сказать из собственного (>10 лет) опыта в очень разных компаниях и не только в СНГ — хорошая ЗП и бонусы + умеренный интерес к продукту (при том что допустим мне, как SRE, в целом все равно что там крутится поверх инфраструктуры с точки зрения продукта, мне важнее «как» работает, а не «что» работает) стимулирует гораздо больше, чем средняя ЗП и песни про «мы все команда, у нас идея» даже при наличии действительно толковой идеи.
Вы знаете, гораздо приятнее любить продукт когда с зарплаты можно купить новый дисплей/телефон/что-угодно-за-1000-евро или смотаться в соседнюю страну на пару дней с семьей, или оплатить хостинг для большого эксперимента по обработке каких-нибудь данных в облаке, или потрогать новую дорогую, но интересную технологию и не особо почувствовать на бюджете, чем любить очень интересный продукт, но копить на телефон в течении квартала и экономить на аренде виртуальных серверов.
Условия труда и компенсация — это основные и самое яркие выражения отношения работодателя к работнику. А идея — это идея. Умные взрослые люди обычно отлично понимают, где чей бизнес и кому на самом деле нужна эта «идея» и кому она в первую очередь несет пользу.
«Все мы люди, все мы человеки» и даже при нормальном доходе всегда есть куда потратить еще один оклад.
А вот на счет мотивации из интереса… Не знаю, на сколько остальные разделяют мою позицию, но те, кого я знаю, с ней согласны — интерес просто позволяет работать на каком-либо месте. Без него туда бы и не пришли. Но он вообще никаким образом не перекрывает остальное.
Да и вообще, так сказать из собственного (>10 лет) опыта в очень разных компаниях и не только в СНГ — хорошая ЗП и бонусы + умеренный интерес к продукту (при том что допустим мне, как SRE, в целом все равно что там крутится поверх инфраструктуры с точки зрения продукта, мне важнее «как» работает, а не «что» работает) стимулирует гораздо больше, чем средняя ЗП и песни про «мы все команда, у нас идея» даже при наличии действительно толковой идеи.
Вы знаете, гораздо приятнее любить продукт когда с зарплаты можно купить новый дисплей/телефон/что-угодно-за-1000-евро или смотаться в соседнюю страну на пару дней с семьей, или оплатить хостинг для большого эксперимента по обработке каких-нибудь данных в облаке, или потрогать новую дорогую, но интересную технологию и не особо почувствовать на бюджете, чем любить очень интересный продукт, но копить на телефон в течении квартала и экономить на аренде виртуальных серверов.
Условия труда и компенсация — это основные и самое яркие выражения отношения работодателя к работнику. А идея — это идея. Умные взрослые люди обычно отлично понимают, где чей бизнес и кому на самом деле нужна эта «идея» и кому она в первую очередь несет пользу.
Да именно про это StanYurk и говорит. Мы не меняем горящие глаза на маленькую зарплату. Мы даем достойную зарплату на рынке, но в дополнении к ней хотим чтобы кандидат разделял наши подходы к работе, в частности Agile и Scrum. Смысл этого довольно прагматичный, если человеку будет не комфортно с нами и он будет себя заставлять сидеть на работе за хорошую зарплату, то он очень быстро перегорит и уйдет от нас. А мы как компания уже потратили много времени на его поиск и адаптацию и будем вынуждены потратить это время снова.
Позвольте мне немного подробнее объяснить что я имею ввиду.
Давайте только условимся, что IT рынок он глобальный и сравнивать надо глобально, по мировым меркам, тем более для хорошего специалиста пройти собеседование в иностранную компанию лишь чуть сложнее чем в российскую из-за языкового барьера, но это легко исправляется несколькими попытками и относительно небольшим количеством времени на улучшение разговорного английского, который к тому же для технического специалиста нужен далеко не свободный, уверенного В2 хватит.
Я ни на кого конкретно не намекаю, но международные компании, принцип отбора у которых взяли вы со всем этим кодом на листочках, платят ощутимо (на десятки процентов) выше рынка и вообще дают огромное количество плюшек в виде шикарной мед. страховки, бесплатного и отличного питания, которое готовится под руководством шефов мирового уровня в столовой и другие штуки, которые просто недоступны в других местах никак, вроде серьезных корпоративных скидок на железо.
Не смотря на то, что туда сложно попасть и то, что много желающих там работать даже вероятно на худших условиях, но они держат планку, сохраняя лицо и продолжая тратить миллионы на повышение своей конкурентноспособности как работодателя.
Поэтому в отношении них нет диссонанса, они много спрашивают — но много дают.
Теперь я вижу вашу статью и появляется вопрос — вы много спрашиваете, но много ли вы даете? Судя по всему — ничего особенного, просто стандартная «достойная зарплата», «медицинская страховка», «удобный офис» и «идея».
Если ваше собеседование по сложности сопоставимо с условным собеседованием в Google/Apple/Facebook/ДругаяКомпанияИзТоп500 (а из того что вы описываете — это так), то каковы вообще могут быть причины идти к вам, если можно просто идти туда и получить и отличные условия труда, и бонусы, и шикарную строчку в резюме?
Именно этого я не вижу ни в одной вашей статье про то, как у вас работается — ответа на вопрос «почему именно Avito должен стать местом, куда надо идти работать?». Пока почти все, что вы опубликовали звучит как «вот вам список причин, почему к нам идти не надо».
Конкретно эта статья добавила в этот список еще один пункт — потому что у них замороченное собеседование со штуками, которые мало кому нравится, при том что то же самое можно получить меньшими усилями.
Простите, но Agile и Scrum это не подходы к работе, это методологии организации рабочего процесса. Подход к работе это «не делать бесполезных вещей» или там «доводить дело до конца». Scrum и Agile не надо разделять, надо уметь по ним работать, это как уметь собирать кровать из Ikea по инструкции.
Он вероятно к вам и не придет, потому что ввязываться в такую эпопею ради вполне обычных рабочих условий вряд ли кто-то будет. Мне кажется проблема не существует, как думаете?
Человек вот тоже потратил много времени на подготовку к собеседованию, учился код на листочке писать, а в итоге ему там так уныло, что он уходит. Это обоюдные риски и если рассматривать общую картину для обоих сторон процесса то их можно просто сократить, т.к. их несут обе стороны.
Давайте только условимся, что IT рынок он глобальный и сравнивать надо глобально, по мировым меркам, тем более для хорошего специалиста пройти собеседование в иностранную компанию лишь чуть сложнее чем в российскую из-за языкового барьера, но это легко исправляется несколькими попытками и относительно небольшим количеством времени на улучшение разговорного английского, который к тому же для технического специалиста нужен далеко не свободный, уверенного В2 хватит.
Мы даем достойную зарплату на рынке
Я ни на кого конкретно не намекаю, но международные компании, принцип отбора у которых взяли вы со всем этим кодом на листочках, платят ощутимо (на десятки процентов) выше рынка и вообще дают огромное количество плюшек в виде шикарной мед. страховки, бесплатного и отличного питания, которое готовится под руководством шефов мирового уровня в столовой и другие штуки, которые просто недоступны в других местах никак, вроде серьезных корпоративных скидок на железо.
Не смотря на то, что туда сложно попасть и то, что много желающих там работать даже вероятно на худших условиях, но они держат планку, сохраняя лицо и продолжая тратить миллионы на повышение своей конкурентноспособности как работодателя.
Поэтому в отношении них нет диссонанса, они много спрашивают — но много дают.
Теперь я вижу вашу статью и появляется вопрос — вы много спрашиваете, но много ли вы даете? Судя по всему — ничего особенного, просто стандартная «достойная зарплата», «медицинская страховка», «удобный офис» и «идея».
Если ваше собеседование по сложности сопоставимо с условным собеседованием в Google/Apple/Facebook/ДругаяКомпанияИзТоп500 (а из того что вы описываете — это так), то каковы вообще могут быть причины идти к вам, если можно просто идти туда и получить и отличные условия труда, и бонусы, и шикарную строчку в резюме?
Именно этого я не вижу ни в одной вашей статье про то, как у вас работается — ответа на вопрос «почему именно Avito должен стать местом, куда надо идти работать?». Пока почти все, что вы опубликовали звучит как «вот вам список причин, почему к нам идти не надо».
Конкретно эта статья добавила в этот список еще один пункт — потому что у них замороченное собеседование со штуками, которые мало кому нравится, при том что то же самое можно получить меньшими усилями.
наши подходы к работе, в частности Agile и Scrum.
Простите, но Agile и Scrum это не подходы к работе, это методологии организации рабочего процесса. Подход к работе это «не делать бесполезных вещей» или там «доводить дело до конца». Scrum и Agile не надо разделять, надо уметь по ним работать, это как уметь собирать кровать из Ikea по инструкции.
если человеку будет не комфортно с нами и он будет себя заставлять сидеть на работе за хорошую зарплату, то он очень быстро перегорит и уйдет от нас
Он вероятно к вам и не придет, потому что ввязываться в такую эпопею ради вполне обычных рабочих условий вряд ли кто-то будет. Мне кажется проблема не существует, как думаете?
А мы как компания уже потратили много времени на его поиск и адаптацию и будем вынуждены потратить это время снова.
Человек вот тоже потратил много времени на подготовку к собеседованию, учился код на листочке писать, а в итоге ему там так уныло, что он уходит. Это обоюдные риски и если рассматривать общую картину для обоих сторон процесса то их можно просто сократить, т.к. их несут обе стороны.
Вот встречаешь очередную статью о том, как люди построили процесс подбора и найма и думаешь: наверное у этих что-то новое и интересное, раз они захотели поделиться с миром. Видимо, хоть кому-то это наконец удалось — придумать как действительно что-то понять о кандидате обернув это в типовой формальный процесс, по которому легко написать инструкцию… Начинаешь читать — а там очередной унылый код на бумажке и надувание щек, типа мы такие все из себя крутые что к нам на собеседования лучше не приходить без флакона валерьянки… Ребят, серьезно? Это ваше «ноу хау»? Ну ок.
Совсем нет, подробные интервью у многих крупных компаний. Яндекс, Мейл и тд. Просто решили расписать, ведь мы открытая компания, из комментов сможем почерпнуть новое. Мы с техпиаром давно ломаем стереотип, что Авито это два программиста на квартире у бабушки. У нас интересные и сложные задачи, мы уже многое реализовали, о чем делимся на митапах, конференциях и в блогах. Нам нужны сильные разработчики и люди с потенциалом. Бояться собеседований не стоит, это опыт для обеих сторон.
> из комментов сможем почерпнуть новое
Разорвите порочный круг: не заставляйте кандидатов писать код на бумажке, и сделаете мир чуть лучше. Или дайте кандидатам выбор: на бумажке написать или в IDE (для крупной компании не проблема ведь притащить ноут на интервью?). Или дайте задание на дом. Бумажка — это лютое зло и оскорбление здравого смысла.
Разорвите порочный круг: не заставляйте кандидатов писать код на бумажке, и сделаете мир чуть лучше. Или дайте кандидатам выбор: на бумажке написать или в IDE (для крупной компании не проблема ведь притащить ноут на интервью?). Или дайте задание на дом. Бумажка — это лютое зло и оскорбление здравого смысла.
На бумажке лучше видны исправления, ход мыслей
Ах, вы занимаетесь чтением мыслей? Я вам секрет открою: мысли человека это чертовски сложная штука, на которую накладывается куча факторов влияния от стресса непосредственно, до ожидания подвоха в формулировках заданий. Все, что вы сможете увидеть — это то, как человек волнуется оказавшись в дурацкой ситуации и как пытается совладать с ручкой, когда пальцы ищут клавиатуру. Все остальное — исключительно ваши иллюзии. Ну или вас порадует человек хорошенько натренировавшийся на предыдущих собеседованиях вне зависимости от реальных скиллов.
Алгоритмы на листочке или доске это лишь один час, есть еще скайп, архитектура и платформа, чтобы раскрыться. Алгоритмы это не камень предткновения, но равноправная секция.
i360u а как в вашей компании проводятся интервью? Как вы проверяете hard-skills кандидата? Я в своей практике ничего лучше практических задачек пока не видел и не придумал.
Я прошу человека показать свой код, выделить интересные моменты, рассказать о нюансах задачи, которая решалась. По ходу задаю дополнительные вопросы, пытаюсь вывести на взаимно интересный диалог о общих подходах и деталях реализации. Смотрю как человек ориентируется в собственном, ранее написаном коде, могу показать что-то из своего или библиотечного и попросить прокомментировать. Если есть взаимная заинтересованность но остаются белые пятна — прошу сделать тестовое задание (дома). Стараюсь задание придумать таким образом, чтобы затронуть необходимые скилы и чтобы кандидату самому было интересно. Затем — совместный разбор результата. Стараюсь построить разговор так, как будто мы коллеги, а не экзаменатор и экзаменуемый. Получается неплохо.
Да, звучит классно. А как быть если показать код нельзя?
Такое может быть только у новичка работавшего в одном месте за лютым NDA. У более-менее состоявшегося разработчика найдутся и свои проекты, и Open Source и прочие наработки. Обычно даже у новичков есть что показать.
Согласен на все 100%. Когда я пользуюсь услугами мастера по ремонту велосипеда я обязательно прошу его показать его собственный, у любого более-менее состоявшегося веломеханика найдутся велосипед с душой отремонтированный и в идеальном состоянии, какие то лично придуманные инструменты и прочие наработки. Обычно даже у мастеров стажеров есть что показать.
Да, звучит классно
Ну а у Вас можно заменить тестовое задание на демонстрацию своего проекта в github?
Вы наверное имели ввиду этап с задачками, потому что тестовые задания (то что надо делать дома) мы не практикуем на позиции разработчиков.
В любом случае, мы такой подход не практикуем и ссылки на свои проекты на github кандидаты нам присылают не так часто как хотелось бы. По моим ощущениям это 1-2 кандидата из 10-ти. Но мы подумаем над такой опцией.
В любом случае, мы такой подход не практикуем и ссылки на свои проекты на github кандидаты нам присылают не так часто как хотелось бы. По моим ощущениям это 1-2 кандидата из 10-ти. Но мы подумаем над такой опцией.
Что значит «открытая компания» и чем она отличается от обыкновенной и от закрытой?
>Мы постоянно ищем технических специалистов
Лучше бы UI дизайнеров искали
Лучше бы UI дизайнеров искали
Оно, конечно, здорово, но бывает так, что вроде и хотел устроиться и прошел все этапы собеседования и начал работать, но в итоге понял, что не твое, получается потратил кучу сил на прохождение этих интервью зря
В этом случае все тратят свое время зря, в том числе компания. Но время которое мы тратим на интервью сильно меньше чем время которое мы потратим на адаптацию человека. В случае если он уйдет мы опять должны будем потратить время на поиск и адаптацию нового разработчика. Получается в случае вашего увольнения по время испытательного срока, компания несет двойные потери в отличие от вас. Поэтому и появляются все эти этапы. Кажется что времени тратиться много, но если сравнить с возможными потерями, то не так уж и много.
Спасибо, что поделились своим опытом. По прочтении данной статьи у меня возникло 2 вопроса:
Ниже пояснение, почему у меня вообще появились эти вопросы.
Регламентация любого процесса – дело хорошее и бесспорно делает процесс масштабируемым и предсказуемым как с точки зрения интервьюеров, так и с точки зрения кандидатов. Более того, когда процесс регламентирован, то появляется возможность его тюнить на основе обратной связи. Тем не менее, мне бы не хотелось, чтобы в моей компании завелся похожий процесс. Как мне кажется, он нивелирует не только индивидуальность кандидатов, о чём было неоднократно замечено выше, но, что не менее важно, также индивидуальность команд, которые нанимают.
Насколько я понимаю суть гибких методологий, она состоит в том, что каждая команда является самоорганизующейся единицей. Она самостоятельно настраивает свои процессы, принимая во внимание поставленные перед цели и имеющиеся ресурсы. Любой регламент сверху, касающийся любого аспекта её деятельности, эту гибкость отнимает, поскольку априори не учитывает её особенности. Представим себе, что в некой компании X есть линейка продуктов: какой-нибудь сервис-«дойная корова» (поиск, почта, объявления и т.п.), написанный на Java, внутренний инкубатор стартапов, пишущийся на Node.js, и инфраструктурные сервисы (портальной авторизация, middleware, стораджа), написанные на C. На мой взгляд будет контрпродуктивным гонять кандидатов по плюс-минус одинаковому флоу при найме в каждую из обозначенных команд.
Позволю себе провести ещё одну аналогию, которая роднит близкую нам предметную область проектирования ПО и рассматриваемую тему проектирования процессов. Подход к разработке с использованием микросервисной архитектуры родился в том числе потому, что получается неоправданно дорого реализовывать разные части системы с использованием одинакового стека технологий, несмотря на то, что это безумно красиво и технологически эффективно. Предъявляемые атрибуты качества к разным компонентам отличаются, и если у меня поиск написан стеке с голым C в связке с in-house базой данных и обязан работать 24x7, то это не повод навязывать его команде разработки соц. сети для любителей котиков, которая находится на этапе проверки гипотезы и может себе позволить небольшие даунтаймы. Как руководитель конкретной команды я предпочитаю иметь свой процесс найма и отбирать людей исходя из своих потребностей. Почему моя команда «соц. сети для любителей котиков» должна полгода набирать сотрудников, из-за того, что руководитель поиска добавил в процесс найма фильтр в виде требования написать алгоритм обхода бинарного дерева без использования рекурсии? Но, постойте, в отличие от команды разработки поиска, моей через полгода из-за невыполненных KPI вообще уже может и не существовать… Данный процесс видится рациональным только в том случае, если с точки зрения внутренней политики компании при закрытии одного проекта люди могли безболезненно переходить в другой. В этом случае действительно получается, что любой бекендер должен быть настолько хорош, чтобы в любой момент он мог перейти в самый технологически сложный проект. Но тут опять страдает команда любителей котиков – средненьких ей набрать не дают, а звезды к ней не идут. Возвращаясь к аналогии с проектированим ПО, описанный процесс найма сродни такому подходу к разработке, где технологический стек унифицирован таким образом, чтобы каждый компонент в монорепозитории в любой момент можно было бы взять и начать использовать в сервисе поиска. Он должен быть написан на голом C и обезбажен на 99,999%, пройдя многоступенчатое code review и иметь 100% code test coverage. Эффективно ли это?
Лично мне импонирует процесс найма в Artsy. Он адаптивен и отталкивается от имеющегося опыта кандидата. Они пытаются свести к минимуму проявления элитаризма в нашей профессии и неожиданным образом отвечают на вопрос «What's wrong with typical hiring practices»:
- Вы пишете, что создали описанный процесс, чтобы сделать процедуру найма эффективнее. Можете раскрыть тезис, в чём измеряется эффективность? Когда непонятно «зачем», сложно оценить полученное «как». Есть ли циферные метрики, подтверждающие повышение эффективности? Например, что время найма уменьшилось на 20%, или текучка снизилась на такое-то количество?
- Какие есть возможности у команд разработки кастомизировать процесс под себя?
Ниже пояснение, почему у меня вообще появились эти вопросы.
Регламентация любого процесса – дело хорошее и бесспорно делает процесс масштабируемым и предсказуемым как с точки зрения интервьюеров, так и с точки зрения кандидатов. Более того, когда процесс регламентирован, то появляется возможность его тюнить на основе обратной связи. Тем не менее, мне бы не хотелось, чтобы в моей компании завелся похожий процесс. Как мне кажется, он нивелирует не только индивидуальность кандидатов, о чём было неоднократно замечено выше, но, что не менее важно, также индивидуальность команд, которые нанимают.
Насколько я понимаю суть гибких методологий, она состоит в том, что каждая команда является самоорганизующейся единицей. Она самостоятельно настраивает свои процессы, принимая во внимание поставленные перед цели и имеющиеся ресурсы. Любой регламент сверху, касающийся любого аспекта её деятельности, эту гибкость отнимает, поскольку априори не учитывает её особенности. Представим себе, что в некой компании X есть линейка продуктов: какой-нибудь сервис-«дойная корова» (поиск, почта, объявления и т.п.), написанный на Java, внутренний инкубатор стартапов, пишущийся на Node.js, и инфраструктурные сервисы (портальной авторизация, middleware, стораджа), написанные на C. На мой взгляд будет контрпродуктивным гонять кандидатов по плюс-минус одинаковому флоу при найме в каждую из обозначенных команд.
Позволю себе провести ещё одну аналогию, которая роднит близкую нам предметную область проектирования ПО и рассматриваемую тему проектирования процессов. Подход к разработке с использованием микросервисной архитектуры родился в том числе потому, что получается неоправданно дорого реализовывать разные части системы с использованием одинакового стека технологий, несмотря на то, что это безумно красиво и технологически эффективно. Предъявляемые атрибуты качества к разным компонентам отличаются, и если у меня поиск написан стеке с голым C в связке с in-house базой данных и обязан работать 24x7, то это не повод навязывать его команде разработки соц. сети для любителей котиков, которая находится на этапе проверки гипотезы и может себе позволить небольшие даунтаймы. Как руководитель конкретной команды я предпочитаю иметь свой процесс найма и отбирать людей исходя из своих потребностей. Почему моя команда «соц. сети для любителей котиков» должна полгода набирать сотрудников, из-за того, что руководитель поиска добавил в процесс найма фильтр в виде требования написать алгоритм обхода бинарного дерева без использования рекурсии? Но, постойте, в отличие от команды разработки поиска, моей через полгода из-за невыполненных KPI вообще уже может и не существовать… Данный процесс видится рациональным только в том случае, если с точки зрения внутренней политики компании при закрытии одного проекта люди могли безболезненно переходить в другой. В этом случае действительно получается, что любой бекендер должен быть настолько хорош, чтобы в любой момент он мог перейти в самый технологически сложный проект. Но тут опять страдает команда любителей котиков – средненьких ей набрать не дают, а звезды к ней не идут. Возвращаясь к аналогии с проектированим ПО, описанный процесс найма сродни такому подходу к разработке, где технологический стек унифицирован таким образом, чтобы каждый компонент в монорепозитории в любой момент можно было бы взять и начать использовать в сервисе поиска. Он должен быть написан на голом C и обезбажен на 99,999%, пройдя многоступенчатое code review и иметь 100% code test coverage. Эффективно ли это?
Лично мне импонирует процесс найма в Artsy. Он адаптивен и отталкивается от имеющегося опыта кандидата. Они пытаются свести к минимуму проявления элитаризма в нашей профессии и неожиданным образом отвечают на вопрос «What's wrong with typical hiring practices»:
- In-person coding challenges
- Whiteboard interviews
- Sample code
- Take-home challenges.
У нас 5 продуктовых и 5 платформенных кластеров. Описанный в статье процесс используется только в одном из них (С2С). И то это скорее фреймворк, а не строгий процесс. Команды его использующие могут менять структуру вопросов и задачи в рамках секций. Могут добавлять свои секции. В общем адаптируют фреймворк, оставляя общую структуру и идею каждого блока.
В моем кластере (Verticals) похожая но не точно такая же схема. У нас тоже есть скрининг по телефону/скайпу, делают его инженеры и мы стараемся уложиться в 30 минут на все (знакомство + наши вопросы + вопросы кандидата). Потом техническое интервью, 2 часа с похожим набором секций. И финал HR + менеджер для проверки soft-skills и прояснения оставшихся вопросов 1.5 часа.
В общем набор секций примерно одинаковый у всех, но каждый кластер адаптирует все под себя и внутри кластера команды еще могут тоже что-то менять. Так что наш процесс ближе к микросервисам, чем монолиту :)
Про метрики на которые смотрели ребята не отвечу, возможно у StanYurk есть детали.
В моем кластере (Verticals) похожая но не точно такая же схема. У нас тоже есть скрининг по телефону/скайпу, делают его инженеры и мы стараемся уложиться в 30 минут на все (знакомство + наши вопросы + вопросы кандидата). Потом техническое интервью, 2 часа с похожим набором секций. И финал HR + менеджер для проверки soft-skills и прояснения оставшихся вопросов 1.5 часа.
В общем набор секций примерно одинаковый у всех, но каждый кластер адаптирует все под себя и внутри кластера команды еще могут тоже что-то менять. Так что наш процесс ближе к микросервисам, чем монолиту :)
Про метрики на которые смотрели ребята не отвечу, возможно у StanYurk есть детали.
По вашему первому вопросу:
Цель процесса найма — делать компанию сильнее за счёт сильных новых сотрудников. Эффективность выше, когда вклад новых сотрудников в среднем выше. Мы меряем вклад качественно при помощи performance review (есть пост про это, но он устарел, постараемся обновить). И да, мы видим, что новички быстрее вливаются, их вклад заметнее, они быстрее растут.
Что касается текучки — процесс поменялся год назад, пока, к сожалению, рано говорить о динамике.
Временные затраты на процесс, конечно, драматически возросли: время собеседования увеличилось в 2,5 раза, воронка найма сузилась, в итоге мы ищем дольше и тратим больше сил. Но то, чего достигает команда, строящаяся таким образом, всё это окупает
Цель процесса найма — делать компанию сильнее за счёт сильных новых сотрудников. Эффективность выше, когда вклад новых сотрудников в среднем выше. Мы меряем вклад качественно при помощи performance review (есть пост про это, но он устарел, постараемся обновить). И да, мы видим, что новички быстрее вливаются, их вклад заметнее, они быстрее растут.
Что касается текучки — процесс поменялся год назад, пока, к сожалению, рано говорить о динамике.
Временные затраты на процесс, конечно, драматически возросли: время собеседования увеличилось в 2,5 раза, воронка найма сузилась, в итоге мы ищем дольше и тратим больше сил. Но то, чего достигает команда, строящаяся таким образом, всё это окупает
Для кого пишутся подобные статьи? Как увижу нечто эдакое, вспоминается всем известная фраза про Льва Толстого на словах, и МПХ на деле. Простите.
Звонили однажды с Авито, но сразу по телефонному разговору сказали о конечной сумме, которую в итоге смогут предложить. Оказалось меньше на 30%, но спасибо, что предупредили об этом сразу.
Писать код на листке, всё-таки, — печаль. Дали бы ссылку на гуглдок, что ли. Там в живом времени можно смотреть какие человек вносит исправления.
Писать код на листке, всё-таки, — печаль. Дали бы ссылку на гуглдок, что ли. Там в живом времени можно смотреть какие человек вносит исправления.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы переделали структуру собеседований, и что из этого вышло