Тестовые задания в ИТ – пережиток прошлого или важный этап отбора? Часть 2
В первой части статьи эксперт по ИТ-рекрутингу Татьяна Аква перечислила основные мифы в отношении тестовых заданий в сознании компаний-нанимателей. Но понимать проблему недостаточно, нужно иметь варианты ее решения. Как же выстроить найм, чтобы обойтись без тестовых заданий? Разбираемся во второй части материала.
Чем заменить тестовое задание
- Самое популярное, и пожалуй, самое работающее — это просто устное собеседование с техническим руководителем. За час-полтора беседы более опытный и зрелый разработчик/руководитель может составить адекватную картину сильных и слабых сторон кандидата. И на основе полученной картины принимать решение, какие слабые места можно восполнить работой на проекте именно по вашим задачам (то есть обучаясь нужным именно вам скиллам быстрее, чем вы найдете их на рынке), а с какими смириться не получится, т.к. это критически важно для вашего проекта.
- Дайте в тестовом небольшую задачу, над которой вы реально работали в последнее время, но прямо на собеседовании, в обсуждении. Это и для вас показательнее, и кандидату будет понятно, какого рода задачи у вас могут возникать. Вы увидите какие варианты он предлагает, насколько эти варианты совпадают с вашими. Может быть, кандидат даже при наводке не видит слабых мест в своем решении или, напротив, у кандидата сразу появилось пару решений, к которым вы долго шли? В зависимости от результатов решения такого кейса гораздо легче принять решение о том, чтобы отказаться от продолжения общения или наоборот срочно брать его на работу.
- При наличии Open Source проектов у кандидата можно изучить их. Посмотреть на код, разобрать спорные моменты, задать вопросы, почему принято то или иное решение или выбран тот или иной инструмент. У вас есть задачи по производительности? Попросите показать код, где кандидат учитывал эти моменты и какую архитектуру закладывал. Проблемы с взаимодействием API? Попросите показать релевантное решение в его проекте и обсудите. При этом код, который вы увидите, будет реальнее и правдивее того, который кандидат будет писать «на показ» для тестового.
- Смотрите senior на крупные задачи для разработки с нуля? Расскажите ему о вашем текущем проекте и попросите рассказать, как он бы строил его с точки зрения архитектуры, дав достаточно вводных. Послушайте его рассуждения. Попросите рассказать, какие потенциальные узкие места он видит и о чем нужно подумать заранее. Не факт, что он должен решить все проблемы прямо на собеседовании, в реальном мире ему нужно будет на это время, но вы точно увидите, насколько предлагаемые решения и рассуждения совпадают с вашими.
- Посмотрите на встрече код вашего разработчика, который находится на ступень ниже нанимаемого, попросите провести ревью. Тоже довольно показательная вещь: показывает навыки поиска ошибок и подход к предложению более оптимальных решений, и взгляды на качество кода.
- Если у вас внутри нет достаточной экспертизы, то не стоит давать тестовое, которое для вас кто-то составил и проверять его по «правильным ответам». Разработка — не точная наука, и предложенное составителем решение может не быть неоптимальным в реальных условиях или просто допускать вариативность при достижении нужного результата. Лучше найдите эксперта, который поможет вам в процессе собеседования. Спросите у друзей, комьюнити или обратитесь в некоторые кадровые агентства, которые помогут найти такого эксперта. Например, у нас есть база топовых экспертов по разным направлениям, которые помогут вам в оценке и найме кандидата под ваши критерии. Скорее всего, в итоге выйдет даже дешевле, чем если бы вы работали по воронке с обязательным тестовым.
- Не забывайте делиться опытом и советоваться. Прежде чем внедрять в найм психологическое тестирование, потому что у вас не срослось с двумя сотрудниками, спросите совета на рынке, в сообществах или у тех же кадровых агентств, кто регулярно занимается оценкой и наймом – скорее всего вам подскажут несколько работающих техник для проверки навыков, с которыми вы придете к желаемой цели более «экологичным» путем.
Что делать, если тестовое задание необходимо
Как вы уже поняли, я не большой поклонник тестовых заданий и убеждена, что в подавляющем большинстве случаев без него можно обойтись. И все же бывают случаи или проекты, когда тестовое необходимо.
Что можно улучшить, если без тестового совсем никак? Пересмотрите его формат и содержание, чтобы сделать его менее болезненным как для кандидатов, так и для вас самих – ведь тестовые нужно кому-то проверять и давать оценку, а это время, которое – деньги.
- Сделайте тестовое задание небольшим — на 1-2 часа максимум. Такое время кандидату гораздо проще выделить, а значит он с большей вероятностью согласится его сделать.
- Приблизьте содержание задания к боевым задачам. Вы сможете оценить, насколько решения кандидата близки к тем, c которыми придется работать.
- Альтернатива предыдущему пункту: дайте нестандартную, интересную задачу, которой можно будет зацепить кандидата. При этом не забывайте, что вам нужно будет как-то оценить решение и сделать вывод, нужен ли вам такой соискатель или нет.
- Давайте тестовое только после общения с непосредственным руководителем. До этого момента кандидат минимально заинтересован в том, чтобы вкладывать усилия, ведь он не знает что его ждет внутри компании.
Мнение большинства кандидатов на рынке звучит примерно так: «Никогда не буду делать тестовое ДО общения с руководителем, так как для меня важнее всего понять, сойдемся ли мы с ним. Зачем тратить время на тест, если мне человек не понравится или у нас разные подходы и цели?»
Важно понимать, что собеседование — это процесс, в котором не только наниматель оценивает кандидата, но и кандидат — нанимателя. И чем более комфортным будет взаимодействие между двумя сторонами в процессе собеседований, тем больше шансов на то, что стороны захотят сотрудничать в дальнейшем. А значит, стоит стремиться к тому, чтобы сделать процесс отбора как можно более бесшовным, устраняя острые моменты. И отказ от тестового задания может стать одной из таких точек роста.
«Мы в FriFlex все этапы собеседований проводим онлайн. Тестовые задания даем обычно прямо на собеседовании. Предварительно готовим для кандидата задачи (часто в coderpad.io), и он решает их в режиме онлайн, по ходу общаемся и модифицируем задачи. Обычно после такого теста становится понятен уровень кандидата».
Итоги
Чем тестовое осложняет найм:
- Сужает воронку отбора или делает ее более длинной;
- Наличие тестового приводит к выбор не из «максимально подходящих» кандидатов, а из «готовых делать тестовое»;
- Оторванные от реальности тестовые задания не дают оценить потенциал кандидата применительно к действительным рабочим задачам.
Какие альтернативы тестовому заданию существуют:
- собеседование с техническим руководителем;
- решение реальной рабочей задачи;
- разбор открытого кода/примеров проектов (GitHub);
- обсуждение архитектуры уже реализованного проекта, как будто его нужно строить с нуля;
- ревью кода другого разработчика;
- привлечение стороннего эксперта с опытом.
Вы не обязаны верить мне на слово. Если отбор с помощью тестового задания давно и эффективно работает в вашей компании, рекомендую провести эксперимент: постройте два пути работы по одной и той же вакансии — на одном оставьте все по- старому, а на другом замените тестовое на одну из перечисленных выше альтернатив, и сравните результаты в цифрах. Вдруг получится, что без тестового задания вы получите более сильных и заинтересованных в вашем проекте кандидатов?
Комментарий недоступен
Комментарий недоступен
Комментарий недоступен
Фиг знает.
1. Насчет интереса. Я задания делал не потому что они такие интересные (что там интересного-то, лол), а потому что хотел на работу устроиться.
2. И насчет времени. Лично мне есть куда потратить время, дофига куда.
Я в принципе был готов потратить время на тестовое задание, но не потому что мне нечего делать, а потому что "фиг с ним, потрачу время на это задание, но честно предпочел бы потратить на что-то другое".
Время на них тратил не потому, что время мне некуда девать, а потому что рассматривал это как возможную мини-инвестицию, что ли.
И кстати мой опыт в плане тестовых заданий негативный.
"Почему все с этим временем носятся как с торбой? Камон ребята, куда вы его утилизируете потом?"
А вам реально настолько некуда время девать, и вы сидите с ума сходите от безделья? ;-)
Если у человека есть хобби, увлечения, девушка, друзья, жена, дети, семья и прочее - вопрос "куда же мне утилизировать время" не возникает ;-)
Скорее вопрос - где бы найти дополнительное время.
У вас настолько пустая и никчемная жизнь, что нужен дядя, который хоть как-то ее наполнит смыслом? Без обид.
"Я сколько раз делал тестовые всегда интересно".
Это тоже крайне странная точка зрения - относиться к заданиям "ой какое интересно задание, дай-ка я его сделаю. Из интереса, лол".
Лично у меня своих интересных идей наверное на сто лет вперед есть, которые было бы крайне интересно сделать.
У вас настолько все прямо по нулям в плане интересных личных проектов?
Могу накидать идей, бесплатно, на сто лет вперед хватит.
Прилетает тебе такое. Твоя оценка времени выполнения и готов ли сделать бесплатно в своё свободное время? И это одно из двух. Там ещё и второе было, но там просто SQL запрос хитрый.
Problem #1:
Given:
System A generates messages (simple strings) in random way. That system may generate N messages per second and then be idle for hours. Every message has its own priority.
System B can process messages in some way, e.g. by sending them to stdout/console. Message processing logic is very slow, it is limited by 1 message/second.
Problem definition:
Implement mentioned program logic (systems A and B).
The implementation of the system A should generate messages. The implementation of the System B should receive generated messages and process them (e.g. send to stdout) with the mentioned performance limitation.
Processing should be priority based - messages with higher priority must be processed first
No messages generated by the System A can be lost, all messages should be processed according to their priority
Implementation limitations:
Use only native Java v6+ API
Do not use any external software and database servers
Do not use any external open source frameworks, all program routines should be implemented by the candidate
Additional statements:
Usage of Maven & Gradle is optional
Usage of any DI framework is optional
Problem #2:
Additional complicated problem definition.
Implement the Problem #1 with the following additional requirements:
The number of System B instances varies (>1)
Every B instance should receive all messages generated by the System A
зависит от размера компании.
Вряд ли код из тестового задания крупная контора будет запихивать себе))
а дизайн студия где 2.5 калеки работают - вполне да.
Поэтому у многих такой печальный опыт.
Время, потраченное на бессмысленное тестовое или 100500 собеседование в цепочке (в отличие от автора я не считаю все тестовые бессмысленными) всегда можно потратить на что-то еще. Я уверена, что большинство разработчиков, например, имеют свои пэт-проекты, либо контрибьютят в открытое ПО, которым пользуются, либо просто дома за чаем в спокойной обстановке изучают новые фреймворки и другие инструменты, занимаются разработкой чего-то по фану.. Кто-то, внезапно, имеет хобби – обустраивает в свободное время умный дом, изучает иностранный язык, занимается спортом, строительством и т.д. Несколько объемных тестовых заданий в купе с несколькими параллельными собеседованиями способны сделать жизнь невыносимой, пусть и на достаточно короткий период времени.