Как стать автором
Обновить

Комментарии 53

я не раз встречал гипотезу, что самые квалифицированные кандидаты не соглашаются делать тестовые задания бесплатно. Лично у меня нет данных, чтобы подтвердить или опровергнуть эту гипотезу

А надо было сделать какую-нибудь зависимость ответов:


  • Да, согласен (джуниор)
  • Да, согласен (мидл)
    И т.д.
    Чтобы увидеть, кто больше соглашается, а кто нет.
    Опрос очень интересный. И по моему субъективному мнению просто и ясно подтверждает логичные, общепринятые и приемлемые вещи. Наверное, сложности начинаются как раз там, где начинаются крайности (пять итераций собеседований и проч.).
Я думаю, это не сильно добавило бы ясности, так как самоощущение человека не всегда точно. Да и четких единных общепринятых стандартов квалификации сейчас нет.
Тут больше практика могла бы помочь.
Например, если компания нанимает только специалистов высокой квалификаци и предлагает выбор — тестовое задание или 2 собеседования и собрала статистику, сколько человек выбрало тот или иной вариант.
Да наверное и не только самоощущения. Мы в прошлом посте обсуждали, и выяснили, что скажем я никогда не делаю тестовых — но при этом мне их и не дают практически (и я не даю в свою очередь тоже, когда нанимаю). Но есть люди, которые такие задания делали, они были интересны, и все такое. То есть тут налицо сочетание каких-то качеств — мне же их не дают не потому, что я такой, а потому что компания так решила.

Хотя самоощущения конечно влияют. Скажем, вот этот ответ:
34% опрошенных готовы делать тестовые задания только когда очень хотят быть нанятыми именно в эту компанию.

Я для себя давно понял, что компаний мечты для меня не бывает. Ну то есть, вообще никогда. Есть проекты мечты в отдельных компаниях. Впрочем, это тоже не совсем самоощущение, некая доля объективности тут точно имеется.
Я имел ввиду самоощущение квалификации. Занимаясь похожими задачами люди часто думать, что они профи. А потом встреча с незнакомой задачей ставит в тупик, как типичного джуна.
Тут ещё другой феномен выявляется — первые 5-10 заданий ты выполняешь без вопросов… а потом это начинает сильно надоедать — тратить минимум 3 часа своего личного времени впустую (особенно Junior'у, у которого и так шансы, что его наймут в районе 1%).

Лично мне из 30+ вакансий только один раз (!) попалось тз, требующее для своего выполнения менее 1 часа…
Я всем рекомендую выкладывать все сделанные тестовые в открытый реп, тогда можно избежать тестового впоследствии.
Я работаю it рекрутером и закрываю 100+ вакансий в год. Могу смело утверждать, что разработчики высокой квалификации в меньшей степени готовы к выполнению не оплачиваемых задач для проверки навыков. И это приводит к тому, что компания ждет не того самого, кто сможет выполнять их текущие задачи, а того кто все таки захочет выполнить ТЗ.
И этот процесс растягивается на пол года(, только процессы никто менять не хочет, потому что им так удобно. Они не хотят тратить свое время, почему разработчик должен его тратить? тем более когда вариантов для трудоустройства без ТЗ тоже достаточно.

О, как. Интересные наблюдения.
Признаться, с точки зрения инертности компаний никогда не задумывался об этом. Хотя ведь неповоротливость крупных компаний – очевидный факт.

Искал работу, и сталкиваюсь с таким, вроде вакансия хорошая по условиям, оплате, компании. Но ТЗ, так как бы я его сделал, чтобы показать свои все навыки на 2 дня. Потому что в ТЗ указаны все вариации пускай будет тестирования. 6 страниц 6 окружений разных, и везде вложены баги, вместо того, чтобы найти 3-5-10 скрытых сложных и какое то мб количество которых они сами не ожидали, тебе надо две сотни задокументировать, провести все тесты которые хочет работодатель. Хотел работу у них, сел делать, понял что забаговано все, я буду два дня бесплатно оформлять документацию, проводить тестирование и репортить и красиво все это подавать. В итоге передумал к ним. А сделать не скурпулезно не могу, это будет обо мне говорить как о невнимательном работнике, которого не стоит нанимать.

Тестовое нужно делать хорошо или не делать вообще :)
В дискусииях на тему тестовых заданий я не раз встречал гипотезу, что самые квалифицированные кандидаты не соглашаются делать тестовые задания бесплатно.
Не бывает тестовых заданий у специалиста. Есть оплачиваемые и неоплачиваемые.
Бывают работодатели, которые не уверены в том, что каждый соискатель — специалист.
И мошенники, которые этим пользуются, заваливая соискателей неоплачиваемыми заданиями.

А, вы же не навязываете свое мнение. На нативное продвижение тестовых заданий
как нормы при приеме на работу. Оплачиваемое задание — это и есть работа.
Зачем это разделять — вопрос очень интересный.
( 2 и 3 цитаты не ваши, тут не спорю. Они просто на мой взгляд верные.)
результаты исследования
результаты опроса
У вас только результаты опроса и личные мысли, уверенность в объективности исследования не субъективная случайно?
Интерпретации всегда субъективны. Свое мнение я постарался отразить не слишком навязчиво. Тестовые задания стоит давать в только при заключении договора и желательно, чтобы это были реальные рабочие задачи, за выполнение которых будет оплата. Трудовое законодательство смотрит на тестовые задания таким образом.
Во время собеседования можно давать порешать небольшие и не слишком абстрактные задачки, чтобы сделать беседу более живой и интересной. Я иногда это делаю, чтобы посмотреть насколько кандидат знает основные функции базовых библиотек языков программирования.
А смысл поясняющих абзацев можно уточнить, пожалуйста?
Ну, я просто увидел первый график: 44% выбрали ответ «Собеседование» как лучший вариант оценки ЗУН. И ниже подпись:
Почти 44% опроценных считают собеседования лучшим способом оценки знаний и навыков.

16% респондентов выбрали тестовое задание. Подпись гласит:
16% набрали тестовые задания.

Дальше я подписи начал угадывать с почти 100% точностью. То есть можно было кинуть пачку инфографики и этого было бы достаточно, на мой взгляд. Разве нет?
Для тех, кто не хочет вглядываться в цвета :)

Вглядитесь, пожалуйста, в цвета в последнем случае

Сопоставлять один из 50 оттенков розового из легенды с секторами на диаграмме и потом сортировать это всё в уме — удовольствие ниже среднего.

Считаю, что первым должно быть презентационное ("расскажите о себе") собеседование (не HR, лучше всего с непосредственным фактическим начадьником), потом ТЗ если нужно, потом техническое, а дальше оффер. В крайнем случае итоговое с большим начальником и/или командой.

Мне кажется, "непосредственному начальнику" совершенно ни к чему слушать стартовые эканья и мэканья на тему "расскажите о себе". Пусть этот фильтр будет полностью отдан на откуп эйчарне – нормальный порог отсеивания каких-либо крайних случаев.
Если всё относительно норм – зовём руководителя (тут же, в эту же встречу, тянуть на следующую тоже не стоит). Такой механизм мне кажется более разумным (я участвовал немного в собеседованиях в разных ролях).

Я с другой позиции настаиваю на таком порядке: чтобы мне рассказали о компании, проекте, команде и позиции. "эйчарня" на первом созвоне отсеивает. Ну или пускай поговорит со мной первые пять минут, пока начальник задерживается. Ну или ещё как, главное, чтоб за этот визит в компанию я понял хочу ли у них работать, чтобы соглашаться на технический собес или тестовое. Хотя бывало, что собес проводил CTO и там всё вместе было.

рассказали о компании, проекте, команде и позиции

Это очевидные стартовые движения.
Мы говорим уже о последующих.

Очень для многих они не очевидны, ответы на многие вопросы типа "насколько ваш скрам противоречит скрам-гайду?" или "вы только тактические паттерны DDD используете?", да даже банальный "критерии прохождения испытательного срока какие?", эйчарами и технарями откладываются на самый последний этап. Часто изначально даже не предусмотренный, просишь его уже оффер получив, а информации о позиции в целом имешшь может лишь чуть больше чем "нужен хороший программист чтобы хорошо программировал и в команду вписался".

Вы считаете, что HR сможет рассказать о проекте и позиции? Реально?
Хорошо подготовленный HR — сможет ответить на 90% вопросов, которые кандидат сможет задать. Другой разговор, что часто они перегружены работой или не очень мотивированы, поэтому имеем то, что имеем.

Не забываем, что ещё полно нештатных рекрутёров, которые, например, и в офисе компании никогда не были...


Вообще на моей практике даже штатные HR почти никогда не могут ответить на вопросы про процессы и технологии разработки больше чем написано в вакансии. Не говоря о "мелочах" типа путания Agile и Scrum.

Вот интересно, и откуда же обычные рекрутеры узнают ответы на вопросы о проекте? Ну, я намекаю на то, что если отдел HR отдельный, как это обычно и бывает, то рекрутеры в проекте не то чтобы не работают, но и не бывают как правило. То есть, они не знают ни людей, ни задач, ни процессов. В общем — ничего. Максимум что они могут сделать — это задать какие-то вопросы тому, что подавал заявку на найм. Но это будут их вопросы, а не вопросы кандидата.

Встречал практику когда менеджеры типа HR по неделе сидели в кабинетах "своих" команд, и хоть что-то да "впитывали" в фоне. Особенно про людей.

Это хорошая практика, без шуток. Но максимум что я видел — это когда HR прикреплен к команде (и по маштабу обычно получается, что один HR где-то человек на 100 команды и более, ну просто потому, что коллектив стабильный, и просто нет такой текучки, или такого расширения, чтобы прям много нужно было набирать), и этот человек заходит пару раз в неделю, пообщаться о том, каковы впечатления от тех, кого на прошлой недели присылали. Ну то есть, в особенности мелких команд (а в моей практике команда больше 10-15 человек была редко) все равно HR вникнуть не смогут. Лучшие из HR — да, пытаются. Но в технологические вопросы — никто на моей памяти даже не пробовал.

Технологические — то понятно. Хотя помню случай когда рекрутёр ушёл в python команду джуном — чуть ли не сам себя схантил )

Вопросы которые им задают кандидаты типовые. Через Х собесовов в паре с техспецом и последующими консультациями они на базовом уровне уже в курсе и могут вполне адекватно отвечать на вопросы.
>Вопросы которые им задают кандидаты типовые.
Я просто излагаю свой опыт, в реалиях которого у HR просто нет времени вникать в детали каждого небольшого проекта. И в лучшем случае они смогут рассказать например о том, что такое наш большой BigData проект, но не маленький (разница в численности сотрудников — два порядка). А разница таки есть, иногда большая.

>Через Х собесовов в паре с техспецом
В нашем случае маленького проекта это будет года через три :) То есть мы примерно раз в год/полгода кого-то нанимаем, не чаще.

Понятно что пообщавшись и вникнув — смогут. Но не всегда так складывается, что у них даже бывает такая возможность.

Это более-менее работает или на относительно небольших проектах с большой текучкой, или на больших проектах с унифицированными процессами и стэками.

Хороший вариант.
50% опрошенных считают допустимыми собеседования длительностью до 2-х часов.

Если это рассматривать как неравенство, то тогда тут должно стоять 89% а не 50%, так как ответы «до 1 часа» сюда тоже входят)
На рынке достаточно специалистов, которые делают тестовые задания. Потому тех, кто не делает, можно игнорировать.

А если рекрутер выходит с предложением, что кандидат очень хорош, но тестовое делать не будет, то в ответ улетает встречное предложение как-либо кандидату продемонстрировать свою «крутизну». На этом общение заканчивается.

Отсюда делаем вывод, что попытка проскочить без тестового — это просто попытка проскочить без тестового.
Может быть «попытка проскочить без тестового» — это просто иррациональное желание кандидата устроится в компанию, где не понимают как нанимать программистов?
Почему же?

34% опрошенных готовы делать тестовые задания только когда очень хотят быть нанятыми именно в эту компанию

Вполне согласуется с исследованием: в этой компании нанимают через тестовое. 1/3 как минимум мотивирована тем, чтобы пойти по нижней шкале. Это слишком много, чтобы парится о тех, кто не хочет делать тестовое.

Так что ваше
не понимают как нанимать программистов
— не более чем личное неприятие такого положения вещей.
То что часть кандидатов готовы делать тестовое чтобы попасть в какую-нибудь престижную компанию типа Google. Не значит, что это хорошая практика для работодателей. К слову, в Google ценят время кандидатов и не дают таких заданий.

Тестовое задание для работодателя — способ потратить время кандидата, не вкладывая своего.

Разумный человек не будет тратить свое время на тестовое задание, если может устроится не делая его.

Кандидат делает тестовое, потому что нет других опций, а не потому что горит желанием потратить свое время. В итоге компания практикующая тестовые получает в основном тех, кто менее конкурентен в обычных интервью.

Это же подтверждается опытом рекрутеров, которые поделились им в комментариях habr.com/ru/post/523666/#comment_22188324

Взятие кандидата без тестового приводит к большому проценту тех, с кем приходится прощаться в течение первого месяца работы.


На собеседованиях всё хорошо: и в шаблоны умеет, и задачи декомпозировал, и джунов менторил. И отвечает, как бы, от опыта. А код пишет так, что проще переписать, чем принять такой МР.


При этом понимаешь, что если бы он делал тестовое, то в какую кучку пошёл бы его пример реализации...


Тестовое — это огромная экономия денег для компании, чтобы от него отказываться.


Заменить его может разве что вайтбординг или предложение покодить прямо на собеседовании. Но это для многих психологически очень тяжело, поэтому не показательно.


Да и ноют по поводу тестового только рекрутеры, так как именно им оно мешает "эффективно" работать.

С одной стороны экономия, с другой — уменьшение количества кандидатов, в том числе подходящих. Если у вас сотни отзывов на вакансии — это одно дело, а если один в неделю откликается и 90% начальный собес не проходит...

Дело в том, что сделанное тестовое практически гарантирует оффер, если там действительно качественный код.


Джунов проверять тестовым нет смысла. Их можно на тестах.


Сеньеров тоже. С ними важно выяснить, насколько они бизнес ориентированы.


Остаются миддлы. Гонору у них обычно много, а качественно писать умеют крайне малое их количество.

Смотря на каких этапах давали тестовое. Если явно толком резюме ещё не изучив, то особо не гарантирует.

Вот такой подход мне кажется сильно ближе к истине, чем то, что вы же писали чуть выше.

На рынке достаточно специалистов, которые делают тестовые задания. Потому тех, кто не делает, можно игнорировать.


Ну то есть, если вы говорите об определенном уровне квалификации, не слишком низком, и с претензиями, то да, возможно тестовые задания могут быть хороши. Но только их подготовка мне кажется совсем не бесплатна для работодателя.
Просто там, где дают тестовое мне ни разу не давали оффера :) А чаще даже не отвечали. Так смысл впустую время тратить?
то в ответ улетает встречное предложение как-либо кандидату продемонстрировать свою «крутизну»


У меня так было раз. В качестве демонстрации крутизны я предложил им мои задания порешать, они согласились. В результате получил чудесного клиента :-).

На обратной стороне "баррикад" ситуация аналогичная. На рынке достаточно компаний, которые не предлагают тестовые задания. Поэтому тех, кто предлагает, можно смело игнорировать.


Тестовое задание — это попытка проскочить, скинуть проблему найма с компании на кандидатов. Отправить тестовое — одна минута. Сделать тестовое — несколько часов. Так зачем связываться с теми, кто заранее воспринимает тебя бесплатной рабочей силой? На собеседовании, по крайней мере, примерно одинаковое количество время тратят обе стороны.


А ещё, выполнение тестового задания не означает, что человек выполнил его сам. Индийцы с китайцами вообще довели это до абсолюта — пользуясь тем, что они очень похожи друг на друга, на собеседования ходит умный парень, а на работу выходит дурачок. И чтобы понять, что это разные люди, уходит до нескольких месяцев. Но это на западе, в России о таком ещё не слышал :)

Сделанное тестовое кем-то другим выявляется сразу же на собеседовании, потому что тестовое — это тема для разговора.


В любом случае, если вакансия подразумевает, что надо будет писать код основную часть времени, то кандидат должен будет продемонстрировать, какого качества код он пишет.

Сделанное тестовое кем-то другим выявляется сразу же на собеседовании, потому что тестовое — это тема для разговора.
Серьезно? Вы отправляете тестовое задание еще до самого собеседования?

В любом случае, если вакансия подразумевает, что надо будет писать код основную часть времени, то кандидат должен будет продемонстрировать, какого качества код он пишет.
А еще вакансия подразумевает оплату за написание кода, значит, компания должна продемонстрировать, какого качества у нее оплата. Месячную зарплату, указанную в вакансии делим на 22, умножим на коэффициент разовой работы, например, 1.5.

Готовы выплачивать по 20к каждому, кому высылаете тестовое задание? Если нет, то вы просто пытаетесь проскочить, получив пользу самому, а затраты перевесив на других людей.

20к по вашей формуле — это же 300к в месяц.
За такую ставку работают люди с хорошими скидками управления командой и создания продукта, а не те, кто основную часть времени пишут код


И да, тестовое уходит рекрутерам вместе с требованиями вакансии.


Тут главное понимать, что никто выцепить лучшего кандидата с рынка не ставит. Задача стоит найти того, кто будет справляться с возложенными обязанностями, и хорошо, если выше ожиданий.


И пока на рынке достаточно нужного качества раб. силы, чтобы игнорить нытье рекрутеров, что тестовое — это бед практика.

20к по вашей формуле — это же 300к в месяц.
За такую ставку работают люди с хорошими скидками управления командой и создания продукта, а не те, кто основную часть времени пишут код
Нет, я имел ввиду не управленцев. Именно техническая экспертиза может стоить гораздо больше. Понятное дело, что далеко не каждой компании нужны настолько квалифицированные кадры, большинству нужно тупо перекладывать json'ы за вдвое меньшую цену. Но если вас смущает 20к — пусть будет 15к — это 220к в месяц. Сама суть от этого не изменится.

И пока на рынке достаточно нужного качества раб. силы, чтобы игнорить нытье рекрутеров, что тестовое — это бед практика.
Тогда зачем изначально использовать негативную коннотацию по отношению к разработчикам вроде «хотят проскочить», если вы точно так же по полной пользуетесь своим преимуществом? Это похоже на лицемерие.

В целом это везде так, не только в айти. Если нужен работник с низкой квалификацией, работодатель может ставить любые условия, хоть сплясать чунга-чангу на интервью, к нему все равно будут идти толпы людей. А когда нужно найти человека с высокой квалификацией — приходится самому чунга-чангу танцевать, лишь бы согласился.

Поддерживаю.


Проблема тестовых заданий существует исключительно в области взаимодействия рекрутеров и работодателя.


А если нужен уникальный или редкий на рынке скилл, то там идут в ход совсем другие подходы.


Но то, что есть прогеры, которые возмущаются тестовым, как раз говорит о том, что они в эту категорию не попадают, и поэтому им приходится сталкиваться с шаблонными требованиям от работодателя.


Не хочется, чтобы тебя меряли общей линейкой, — создай бренд себя самого, чтобы работодатель знал, кто ты такой, а не просто "Василий Пупкин, очень хороший кандидат на эту вакансию, опыт на предыдущих местах точь-в-точь, чем вы занимаетесь. От тестового отказался. Давайте его сразу пригласим?".


"Василий Пупкин? Не знаю про такого. Пусть даст о себе информацию, чтобы мы могли верифицировать его слова о его навыках".

Всё-же «возмущаются» — это слишком сильное слово. Обычно выбираешь несколько компаний из тех, которые кажутся нормальными, получаешь от них офферы, сравниваешь между собой и принимаешь лучший. Если кто-то из них предлагает выполнить тестовое — просто вежливо отказываешь.

создай бренд себя самого
Хороший совет, но это скорее для консультанта, с работой по контракту. Но тут и цены будут совсем другие.
Меня вообще в последнее время убивают вакансии в тексте которых фигурируют «Hightload проект» и «какая то CMS» — где мозг?

Так всё логично же. Сделали MVP на CMS, взлетел, но простых шагов типа конфиги поковырять или сервер помощнее взять уже не хватает чтобы держать нагрузку

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории