«Это благотворительность в пользу работодателя»: тестовые задания в IT — за или против?

Разработчики обсудили целесообразность тестовых заданий при приеме на работу, а также свое отношение к ним на форуме DOU. И вот, что получилось.

Что происходит

People management consultant для IT Виктория Придатко провела опрос об отношении разработчиков к тестовым, предлагая варианты:

•       нормально, делаю при необходимости;
•       не нормально, не буду делать, даже если вакансия интересна;
•       свой вариант.

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

ЗА

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

«Через “поговорить” инженера не обнаружить. Инженер — это кое-что большее, особенно если в новой компании используются методы, с которыми кандидат не сталкивался на прошлой работе, — пишет Prototypes Engineer Андрей Слижевский. — Инженер постоянно учится и ищет новые решения. Тестовое необходимо, а еще лучше сменить подход к собеседованию на инженерную должность и начать с “технических” рекрутеров».

«Это нормально, и тестовое следует делать. Мы сейчас говорим об инженерной специальности. А не о “поговорить”, камон!», — считает Виталий Калиничевский.

ПРОТИВ

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

«Предложили немаленькое тестовое перед бесплатной стажировкой, после которой могут взять на оплачиваемую практику 3–6 месяцев. Оплатить выполнение отказались. Мне кажется, это уже перебор. Для понимания: даже по оценке рекрутера, на выполнение дается НЕДЕЛЯ».

«Делал несколько раз. Однажды даже интересно было, потратил где-то часов 5 на задание, должно было занять 1–2 часа, — рассказывает AndriP. — Ни фидбека, ни оценки никакой не получил. Сделал вывод раз и навсегда. Тестовое — это благотворительность в пользу работодателя».

Еще один момент, который раздражает разработчиков — неадекватная оценка времени выполнения задания.

«Пару раз сталкивался с тем, что дают тестовое «на 4 часа», но если делать его качественно (дизайн БД и API, понятная логика, тесты, сопроводительная документация по развертыванию в дев энвайроменте), то легко можно потратить на него несколько дней. А чисто за 4 часа выйдет спагетти-код, который может и выполнять поставленную задачу и пройти автотесты, но при ревью вызовет кучу WTF со стороны проверяющего», — говорит Josh Butler.

Компромисс

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

«Буду выполнять задачу только, если очень хочу попасть в эту компанию. Но не буду делать, если там будет что-то экзотическое (например, из последнего — автотесты на Cucumber) или если нужно будет сидеть больше 4–5 часов», — пишет Андрей.

Senior Software Developer в Access Softek Сергей Лобода даже расписал список критериев, по которым определяет, стоит ли браться за тестовое.

«Вообще я люблю программировать (сюрпрайз ;-), и лучше что-то показать, чем 100500 раз рассказывать, что такое GC и как он работает. Любые варианты live coding, за который здесь многие топят, не для меня: я ненавижу когда за моей работой наблюдают из-за спины.

Буду делать, если:

• это займет 2–4 часа;
• задача не является трэшем с Литкода;
• задача составлена ​​так, что не вызывает вопросов;
• есть хоть какие-то формализованные критерии оценки, например, заранее написанные юнит-тесты.

Не буду делать, если:

• задача напоминает продуктовую проблему;
• требует применения слишком широкого стека технологий (это автоматически влечет за собой превышение лимита времени в 2–4 часа);
• заранее не предусмотрена какая-либо встреча для обсуждения результатов (только письменный фидбек не пройдет, потому что нет гарантии, что его не сделают «на отцепись»)».