Комментарии 43
можно скрыть от команды, например, если вы хотите сравнить кандидата с человеком из команды для корректировки уровня компенсации
Выглядит так, будто вы ошибочно называете менеджера "тимлидом". Обычно ведь тимлид - технический чувак, который вполне может не знать цифры зп своей команды и уж точно не тот чел, кто решает, сколько денег кому отдать. Это роль менеджера. И да, конечно возможна ситуация, когда в некой команде менеджер и тимлид - один человек, но мне кажется, это всё-таки скорее исключение, ибо список скиллов почти не пересекается же.
Выглядит так, будто вы ошибочно считаете, что "тимлид" — это какая-то очень конкретная специальность, и в каждой компании это слово должно означать одно и то же.
Но даже если бы это было так, было бы ошибочно полагать, что правильный вариант — именно ваш. Если в вашей компании на тимлиде лежит ответственность за результат команды, и при этом у него нет стандартных рычагов влияния на команду (например, знание и возможность влияния на ЗП), то у вас проблемы. Если же в вашей компании на тимлида такая ответственность не возлагается, то какой же он "лидер команды"?
Не знаю, как там в идеальном мире, но насколько я могу видеть у нас модным словом тимлид называют тех, кого "в советские времена" называли начальник отдела.
который вполне может не знать цифры зп своей команды и уж точно не тот чел, кто решает, сколько денег кому отдать
Тимлид, который не знает цифры зп своей команды — какой-то сферический конь в вакууме.
И в массе команд тимлид может повлиять на количество денег тому или иному челу из своей команды. Немного, но может. Это нормально и правильно — для тимлида это инструмент кнута и пряника.
Кандидат растерялась, и нам показалось, что она слишком скромная, стеснительная и боится трудностей.
А вы собирались снимать фильмы «для взрослых 21++»?
Или вокруг масса людей с одним желанием «Хлебом не корми, дай с трудностями повоевать»
с такими-то критериями…
Мы провели еще несколько собеседований и только потом поняли, что это был самый крутой вариант за последние две недели, но кандидата мы уже упустили.
И эти люди мне
Это основной интерфейс между кандидатом и работодателем, лакмусовая бумажка способностей, если хотите.
Ага… угадайте что мы хотим, а мы вам фиг пришлем внятное развернутое аргументированное пояснение почему «вы не правы», если вообще пришлем какой-то отклик. Это уже обсуждалось и не раз. Эта штука работает только в одну сторону.
это не «дело рекрутера», а командный проект.
«У семи нянек дитя без глазу» знакомо? А потом следующий тимлид что будет делать с нанятым человеком, увольнять и набирать по новой? подход «А можно всех посмотреть...»
Грустно от этих «Игр
Ага… угадайте что мы хотим, а мы вам фиг пришлем внятное развернутое аргументированное пояснение почему «вы не правы», если вообще пришлем какой-то отклик. Это уже обсуждалось и не раз. Эта штука работает только в одну сторону.
У меня такое тоже было в практике, но один раз всего. Сделал тестовое задание и ни ответа и ни привета. Раздражает, конечно. Но такой случай, скорее, более справедлив для крутых специалистов, для которых каждая минута стоит больших денег. До уровня миддла даже в кайф повыполнять всякие тесты ;)
Но, как заметил Саша в своей статье, мы находимся в высококонкурентном секторе рынка и соискатели скорее всего просто проигнорируют компанию с таким требованием. И пойдут туда где такого требования нет, зато есть уже готовый оффер.
Топовые специалисты получают предложения в промышленных масштабах. А еще у них, чуть меньше, чем всегда есть что то интересное в гитхабе. Зачем тут какие то тестовые задания? Я всегда скипал тех, кто не смог по гитхабу понять ок или не ок. Да и мне самому куда интереснее вместо тестового посмотреть, что у кандидата в гитхабе. Для меня это информативнее.
Топовые специалисты
Миддлы и джуны работу не ищут? И вообще никому на рынке не нужны? У всех, особенно у выше перечисленных категорий, поголовно, есть открытые проекты на гитхаб? Да ещё и хайэнд уровня? Мы о разных вещах, по-моему, говорим...
Ну как же о разных. Вы же сказали, что не согласны с тем, что тестовое задание должно быть опциональным. Пример выше, лишь один из кейсов, который демонстрирует "вредность" обязательности выполнения тестового. Джуниоры и мидлы тоже не редко держат какой то интересный код в своем гитхабе. Например у Джунов можно встретить выполненные тестовые задания в другие места. Соответственно, тестовое задание актуально, когда кандидат не может представить код, который мог бы продемонстрировать скилл.
А когда поддерживать свой гитхаб, когда у тебя огромные проекты и полная занятость, а все проекты приватные?
По моим наблюдениям, хорошие программисты не редко пилят прототипы для проверки различных концепций или просто для саморазвития, которые в конечном итоге оказываются в гитхабе, по тому что так удобно. Если программист ничего не пилит вне работы, то наверное ему не слишком нравиться программирование. Имхо.
А если "пилят" вне работы прототипы или свои проекты и как-то обходятся без гитхаба или прочей публичности? Смысл прототип или свой проект выкладывать в гит ? Или такого программиста надо "лечить" ? Или если для "телочек с дакфейсами" есть инстаграм, то гит это что-то вроде "инстраграма" для программеров ? Тогда уж надо сделать что-то типа onlyfans программеров :)))
Ну а для таких бедолаг как раз тестовое задание. Но мне кажется быстрее что то залить в гитхаб, чем тратиться на тестовые. Впрочем каждому свое :)
Ну а для таких бедолаг как раз тестовое задание.
Безусловно, к тестовому заданию прилагаются, например, "The quality of a system is the degree to which the system satisfies the stated and implied needs of its various stakeholders, and thus provides value" и согласно промышленным стандартам вроде "The defined quality characteristics can be used as a checklist for ensuring a comprehensive treatment of quality requirements, thus providing a basis for estimating the consequent effort and activities that will be needed during systems development. The characteristics in the quality in use model and product quality model are intended to be used as a set when specifying or evaluating computer system or software product quality. "
Следовательно можно результат тестового передать N-разным третьим лицам\аудиторам, создателю тестового задания и все они выдадут одинаковую оценку ?
Если разработчик делает для себя проект в гите и после показывает его на собеседованиях, он должен его поддерживать согласно "последней моде" и удовлетворять множеству гипотетических ревьеверов одновременно с хз какими ожиданиями и квалификацией ?
В реальном мире это выглядит весьма оптимистично.
Мне кажется, следование моде и тп совершенно не обязательно. Гораздо интереснее увидеть, что человек умеет в паттерны проектирования, грамотно пользуется структурами данных и тп. Если с этими вещами всё хорошо, то вряд ли будут проблемы с изучением какого то новомодного фреймворка.
И Вы готовы составить checklist этого "грамотно", "не обязательно " и "всё хорошо", естественно с объективными метриками и методологиями измерения этих "грамотно-не обязательно-хорошо" для развернутого списка "паттерны проектирования-структурами данных -и тп." и после предложить к публичному обсуждению ?
Предполагаю, это будет интересный и познавательный эксперимент :)
А в идеале за подбор в команду отвечает непосредственно тимлид
В идеале за подбор в команду отвечает команда, ибо это всей команде работать с новым человеком.
Этой статьей я хотел продемонстрировать, что подбор — это не «дело рекрутера», а командный проект.
Я бы переформулировал по-другому:
Если вы приходите в ИТ-компанию, на должность руководителя разработки (в какой-то компании это может быть и тимлди), и если вы при этом хотите отвечать за проект в целом — то вам должно быть важно все. Вплоть до того, в каком офисе сидит команда — потому что все это влияет на людей, и на разработку соответственно.
И, что не менее важно, из этого следует другой вывод: если с вас требуют результата за проект в целом, то у вас должны быть и рычаги влияния на все процессы в компании.
что наём — это всегда командный проект
Очевидно, что нет. Все-таки зона ответственности профессионала в грамотном выполнении своих прямых обязанностей, а не в поиске адекватных коллег. Да, с хорошими и грамотными коллегами работать приятнее. Но… это косвенный бонус.
На мой взгляд зона ответственности такого проекта найма несколько выше команды и лежит в области мотивации линейного руководителя, овнера, а возможно даже владельца небольшой компании.
В любом случае качественный отбор требует отдельной заинтересованности повлиять на структуру и качество команды, скорее это участь акционеров/опционеров.
Кандидаты попадают к нам несколькими способами: Отклик на hh, Поиск на hh, Добавление из файлов/других ресурсов. Довольно больша́я часть откликов (красная полоска на скриншоте ниже) обычно не релевантны.
По воронке видно, что только процентов 20 из откликнувшихся доходят до технических специалистов.
Причина простая — часто откликаются кандидаты с релевантным опытом:
- не iOS разработчик
- не разработчики вообще (войти в IT)
- iOS-разработчики, с недостатком опыта для текущей позиции
- Фрилансеры (мы ищем все же на постоянку в штат)
- и т.д.
Финальное решение складывается из довольно большого числа факторов:
— общий технический уровень кандидата и потенциал развития;
— софт скиллы и то, на сколько подходит к текущему коллективу;
— продуктовое мышление (в продуктовых командах у нас конкретно это важно, так как разработчики не просто исполнители ТЗ, а инженеры, нацеленные на донесение ценности до пользователя);
— желаемое направление развития (иногда, к примеру, мы заинтересованы в том, чтобы из кандидата растить тимлида);
— зарплатные ожидания и т.д.
Допустим у вас 4 кандидата на подходе, вы прособесили первого и он в целом хорошо. Но у вас еще есть 3 кандидата, которые, возможно лучше по каким то параметрам, а возможно нет.
В итоге, в случае если человек не подошел, то все просто — ему отказывают, причем иногда сразу же на собесе. Если есть шанс, что он будет конкурировать с остальными — приходится морозить.
Совсем не потерять кандидатов нам помогает Talantix — в нём можно настроить, сколько кандидат может находиться на этапе.
В любом случае, я с Вами согласен, что необходимо регулярно уведомлять кандидата о статусе. Если осталось прособесить еще троих — так и скажите: «У нас довольно много хороших кандидатов — планируем их прособеседовать за ближайшую неделю». По итогу к вам вернемся с ответом. Прозрачность в отношениях очень хорошо говорит о вашей компании.
заинтересованы в том, чтобы из кандидата растить тимлидаВ чьей зоне ответственности этот интерес?
- тимлидство в этой компании;
- технический стек;
- предметную область бизнеса
Поэтому нанять тимлида с «улицы» — это весьма непростая задача, и кадровый резерв тимлидов — весьма крутая затея
2) Самому тимлиду, на самом деле тоже интересно:
- Разгрузка за счет делегирования;
- В целом передавать опыт и рефлексировать — довольно интересная задачка
Как-то мы нанимали тестировщика и на финальном собеседовании долго спрашивали девушку-кандидата про agile-методологии в разработке, хотя это было не принципиально для должности.
Интересно — зачем это делалось? Просто чем-то занять время собеседования? А поспрашивать по скиллам кандидата — не вариант?
Вообще задавать вопрос «Что бы что?» — крайне полезная затея. Причем, даже когда все хорошо идет
мы неправильно очертили набор навыков на эту позицию
То, что Вы вообще очерчиваете такой набор навыков — это уже весьма ограниченный подход. А уж для тестировщика — и подавно. Это отличный подход, чтобы упускать хороших кандидатов, скилы которых не полностью соответствуют вашим текущим требованиям.
То, что Вы вообще очерчиваете такой набор навыков — это уже весьма ограниченный подход
Какой «такой»? Не понял Вас, если честно. Я выше не приводил характеристики, по которым принимаем решение. Привел лишь кейс, который нам помог как раз задуматься и понять, что действительно важно для каждой роли.
Как это устроено: У нас есть набор навыков / характеристик, которые в разной степени необходимы на должность. К примеру, для QA специалиста нам критически важны самостоятельность, умение находить баланс и желание развиваться. При этом умение писать автотесты на swift — это необязательный навык.
Собеседование, соответственно, строится на том, чтобы оценить кандидата по критериям, которые нам важны.
Какой «такой»?
Вообще сам факт, что у вас есть такой набор навыков для кандидата — это сильно ограничивает в кандидатах. К примеру, навык «agile» сразу отсекает всех, кто по нему не работал. Является ли это ограничение разумным? Есть определенные сомнения. И так по остальным навыкам. По сути, собеседующему важно понять, что кандидат знает хорошо или неплохо, с чем сталкивался на предыдущих местах. Потом оценить, сколько времени нужно на дообучение. Сравнить с теми, кто до этого приходил. И тогда уже можно делать оффер или переходить к следующим кандидатам.
К примеру, для QA специалиста нам критически важны самостоятельность, умение находить баланс и желание развиваться.
Cамостоятельность — это напрямую зависит от опыта, вообще не показатель, можно натренировать. Если человек сам пришел на собес — то самостоятельность у него в какой-то мере точно присутствует.
умение находить баланс
странный навык для QA. Или Вы что-то конкретное имели ввиду?
желание развиваться
есть практически у всех айтишников до 30 лет. Если человек пришел к Вам на собес — то желание у него в какой-то мере присутствует.
Что-то мне подсказывает, не те скилы Вы требуете от кандидатов ).
Вообще сам факт, что у вас есть такой набор навыков для кандидата — это сильно ограничивает в кандидатах. К примеру, навык «agile» сразу отсекает всех, кто по нему не работал
Согласен с Вами, что такие вещи, как опыт/понимание agile скорее не являются блокирующими — этому всему можно научить. Тем не менее, некоторые вещи для нас критичны.
Выписать на и ранжировать характеристики, которые важны для конкретной позиции — это отличное упражнение, которое как раз делает собеседование максимально продуктивным
Если человек сам пришел на собес — то самостоятельность у него в какой-то мере точно присутствует.
Конкретно для нас у QA необходим немного больший уровень самостоятельности :)
Это связано с тем, что в команде в мобилке 2 iOS, 2 Android и 1 QA. Всвязи с чем QA приходится принимать решения и уже прятаться за спину старшего товарища не получится.
В других компаниях, в которых QA собраны в отдельные команды, уровень самостоятельности QA-инженеров может быть ниже
желание развиваться есть практически у всех айтишников до 30 лет.
В желании развиваться есть грань между мечтой и планами.
Что-то мне подсказывает, не те скилы Вы требуете от кандидатов ).
Я не претендую на то, что наша схема собеседования или критерии выбора являются единственными правильными. В зависимости от продукта, устройства компании, схемы взаимодействия, текущего коллектива, бюджета ФОТ и много другого требования, критерии, да и сама схема найма могут меняться.
Возможно то, что не работает у нас, будет хорошо работать в Вашей компании и наоборот, и это нормально :)
Всвязи с чем QA приходится принимать решения и уже прятаться за спину старшего товарища не получится.
Мне кажется, я начал Вас понимать, что Вы имели ввиду под «самостоятельность». Полагаю, что Вы столкнулись с тем, что некоторые QA не вывозят без посторонней помощи. Но это никак не связано с самостоятельностью, а исключительно с опытом работы, знаниями тулзов и методологий и корректным онбордингом новичка. Скорей всего QA кинули на амбразуру, а знаний и опыта у него не хватает.
В желании развиваться есть грань между мечтой и планами.
Скажем так — до 30 лет у айтишников способность обучаться находится на весьма высоком уровне. И тут, по моему мнению, Вы немного подменяете понятие «мотивация» желанием развиваться. Мотивация — штука нежная и нужно ее грамотно поддерживать, в том числе и деньгами. Бывает, что некоторые очень быстро учатся и набираются опыта, так как сильно мотивированы(им очень интересно). Но тут тоже есть риск, что он быстро перерастет должность и уйдет на бОльшие деньги.
Возможно то, что не работает у нас, будет хорошо работать в Вашей компании и наоборот, и это нормально :)
Тут сложно с Вами не согласиться :). Но есть базовые практики собесов, которые работают везде и для всех. Или не работают — таких тоже немало, например вопросы типа «Кем Вы себя видите в нашей компании через 5 лет?». Или — «Почему люк круглый?».
Скажем так — до 30 лет у айтишников способность обучаться находится на весьма высоком уровне.
Мне 31, можно ставить крест на развитии? :)
Скорей всего QA кинули на амбразуру, а знаний и опыта у него не хватает.
На амбразуру никого не кидаем) В одной из охэхэнных историй рассказывали как у нас онбординг проходит. Как раз, как все любят — мягко и поддерживающе
Но есть базовые практики собесов, которые работают везде и для всех. Или не работают — таких тоже немало, например вопросы типа «Кем Вы себя видите в нашей компании через 5 лет?». Или — «Почему люк круглый?».
Про люк не спрашиваем. Кстати первый раз слышу такой вопрос
А в вопросе «Кем Вы себя видите в нашей компании через 5 лет?» есть рациональное зерно, просто его кадровики опошлили. Его надо задавать так: «В какую сторону Вы планируете развиваться? Что Вас драйвит и мотивирует?»
Зачем тимлиду участвовать в подборе? Потому что ошибки найма упадут на него