«Це благодійність на користь роботодавця»: тестові завдання в 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 Сергій Лобода навіть зробив собі список критеріїв, за якими визначає, чи варто братися за тестове.

«Взагалі я люблю програмувати (сюрпрайз;-), і краще щось показати, ніж 100 500 разів розповідати, що таке GC і як це працює. Будь-які варіанти live coding, за який тут багато хто топить, не для мене: я ненавиджу, коли за моєю роботою спостерігають з-за спини.

Робитиму, якщо:

• це займе 2-4 години;
• завдання не є трешем з Літкод;
• завдання складено так, що не викликає питань;
• є хоч якісь формалізовані критерії оцінки, наприклад, наперед написані юніт-тести.

Не робитиму, якщо:

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