«Є ризик втратити цікавого кандидата та уповільнити найм». Чи потрібні тестові в IT і якими вони мають бути
Єдиної думки про те, чи варто компаніям давати тестові завдання технічним спеціалістам, а кандидатам — виконувати їх, в IT-індустрії немає. Дехто вважає, що це непоганий спосіб відсіяти тих, хто ще не готовий до обов’язків, які доведеться виконувати. Інші ж кажуть, що це марнування часу, оскільки тестове не обовʼязково свідчить про здатність вчитися та виконувати робочі завдання в реальних умовах.
Немає і єдиної думки щодо того, якими тестові мають бути у
«Те, що в кандидата є відповідний досвід, тестове навряд чи покаже, особливо роздуми і вміння спеціаліста розвʼязувати проблеми»
Станіслав Кошель, Software Engineer
Тестові, які я виконував, були звичайними: побудувати вебзастосунок на кшталт простої соцмережі чи блогу, задеплоїти на Heroku чи аналогу і запушити код на GitHub. Зазвичай компанії виділяли на це близько тижня.
Оплати за виконані тестові мені ніколи не давали, нормального відгуку жодного разу не побачив, та й сам зворотний зв’язок отримував не завжди.
На мою думку, тестове має оплачуватися за таких умов:
- якщо його виконує людина, що претендує на посаду middle та вище;
- виконання тестового займає понад годину.
Але компанії це невигідно, особливо тепер, коли ринок на боці роботодавця. Я принципово ігнорую всі вакансії з тестовими завданнями (або відразу кажу, що не маю наміру їх виконувати) — просто не хочу марнувати час, є багато інших пропозицій.
Тестове повинне щось комусь довести. Вочевидь те, що в кандидата є відповідний досвід, тестове навряд чи покаже, особливо процес роздумів і вміння спеціаліста розвʼязувати проблеми. Натомість live coding закриває цю потребу.
Якби я шукав у свою компанію спеціалістів рівня Junior, тоді тестові мали б сенс. Але для цього я б використав сервіс онлайн-тестування, де є питання і варіанти відповідей — це дозволить «поганяти» по теорії чи перевірити основні навички з програмування. Але важливо, щоб не було неадекватних питань, які в реальній практиці не трапляються. Після першого етапу з тестовим я б відбирав найкращих кандидатів і запрошував на технічне інтерв’ю, де їх чекатиме live coding.
Схожий досвід у мене був з BetterMe. Там потрібно було виконати тестове з двох частин, година на теорію і година на практичне завдання, все виконувалося в браузері. Потім мене разом з п’ятьма іншими кандидатами запросили на тестовий робочий день в офіс, але, на жаль, далі я не пройшов.
Фідбек за результатами тестового я вважаю дуже важливим. Він потрібен для роботи над помилками, як у школі, щоб згодом зробити найслабше місце найсильнішим. Наполегливі кандидати зазвичай пишуть раз на тиждень рекрутеру, щоб дізнатися статус перевірки їхнього тестового.
Є ще один момент, на який треба було б зважити. Припустимо, компанія вирішила зупинитися на одному з кандидатів до перевірки решти тестових, бо їх він уже влаштовує. У такому разі буде добре, якщо про це повідомлять решті кандидатів. Як на мене, це має лягати на плечі платформ з пошуку роботи, інакше сотням відповісти може бути дуже важко, а зробити це в один клік буде зручно для всіх.
«Компанія не повинна писати розгорнутий відгук щодо кожного технічного спеціаліста»
Ігор, репетитор з математики, шукає роботу React-розробником (спікер зажадав залишитись анонімним)
Останні два з половиною місяці я намагаюся змінити роботу, проте активно перебуваю в пошуках два-три тижні, оскільки мав великі проблеми з електроенергією. Я з маленького містечка, тому роботу шукаю віддалено.
Я React-розробник, знаю JS/React/TypeScript/CSS, тобто класика. Відгуків на таку вакансію приблизно безліч, а якщо точніше, то орієнтовно 400 за день.
Наведу два приклади тестових, з якими я стикався:
- Завдання — написати інтернет-магазин, буквально. Термін — два дні. Його я не виконував, бо це надто безглуздо.
- Другий приклад розмитий, оскільки це траплялося часто. Вакансії з jQuery, PHP тощо — всі трешові, буквально кожне тестове — написати сайт.
Ніхто ці тестові не оплачував, хоча я й не вважаю, що компанія має це робити. Оплата тестового доречна, коли кандидат виконує завдання, результати якого використають у «живому» продукті.
Здебільшого після тестових я отримував фідбек. Втім не можу сказати, що відгуки мене влаштовували, оскільки не були розгорнутими. Проте я ставлюся до цього з розумінням, адже кандидатів занадто багато і компанія не повинна писати розгорнутий фідбек щодо кожного технічного спеціаліста.
Найбільша проблема сьогодні — кількість кандидатів, зокрема джунів. Я усвідомлюю, що більшість хочуть відсіяти й набрати найкращих. Та деякі компанії дають легкі завдання і додають собі цим зайвої роботи, оскільки слабкі тестові не показують реальні навички кандидата.
У таких випадках краще, на мою думку, дивитися на пет-проєкти. Потім має сенс дати тестове, що кине виклик знанням, але водночас його можна буде зробити за день. Тобто легкі завдання з LeetCode або ж створення інтернет-магазину — дурниця. Варто обирати щось середнє за складністю.
Попри те, що війна — це додатковий стресовий чинник, не думаю, що є сенс давати більше часу на виконання тестового або робити його меншим за обсягом. Зараз конкуренція величезна з огляду на те, що чимало людей намагаються перейти в IT, а ринок зменшився. І такі зміни в підході до виконання тестових не допоможуть швидше знайти роботу чи найняти найкращого спеціаліста.
Але всі мої роздуми — лише про джунів. Якщо брати вищі позиції, ситуація відрізнятиметься. Втім оскільки мені далеко до інших грейдів, то оцінити ситуацію з ними не можу.
«Стрес і зовнішні чинники на тестове мають впливати не більше, ніж на звичайну роботу»
Сергій, Full Stack Developer (спікер зажадав залишитись анонімним)
Я працюю півтора року на посаді Full Stack Developer, але вирішив підшукати ще один проєкт, оскільки гроші зайвими не бувають.
Два ТЗ були у вигляді проєктів на GitHub з пропущеними методами (тобто @todo). В одному були чіткі коментарі, що має реалізовувати метод, з коментарями щодо аргументів/формату відповіді (були абстрактні класи). У другому — лише назви методів, потрібно було дописати чужий код. На виконання кожного виділили три години. Я погодився виконати завдання з умовою, що буде зворотний зв’язок. Але в результаті відгук довелося буквально випрошувати.
У третьому випадку я мав розібратися в API СРМ-системи, реалізувати логін/авторизацію/методи до основних ендпойнтів СРМ. Дедлайн — до трьох днів. Фідбек був «нас влаштовує, ось офер» (це засмутило, хотілося б отримати розгорнуту відповідь, незалежно від наявності оферу, але мені тільки сказали, що все добре).
Якщо на виконання тестового потрібно до трьох годин і йдеться про посади рівня Junior і Middle, я вважаю, що оплачувати його з боку компанії не потрібно. Якщо це Strong Middle, Senior і вище — тоді так, оплата має бути в разі, якщо тестове працює. Компенсація — у розмірі погодинної оплати згідно із зарплатною вилкою, на яку претендує кандидат. Якщо компанія не хоче оплачувати, тоді має бути live coding на технічній частині інтерв’ю. Це набагато стресовіше, зате швидше за часом і допомагає краще зрозуміти стиль мислення кандидата.
Зазвичай я не отримував відгуки на свої тестові. А якщо зворотній зв’язок і був, то здебільшого загальними словами, а це ображало, особливо якщо тестове виконане повністю. Виходить, компанії шкода п’ять хвилин на детальніше пояснення відмови, тоді як від кандидата вимагають виконати суттєвий обсяг роботи. Я подібні компанії вношу в особистий чорний список [усміхається].
Розгорнутий фідбек неабияк важливий, оскільки допомагає зрозуміти причину відмови й виконати роботу над помилками. А можливо — і пояснити роботодавцю, чому тестове виконане саме так, а не інакше. Якщо кандидат не завершив завдання на 100%, справедливо залишити питання надання фідбеку на розсуд компанії, оскільки очевидно, що він не відповідає вимогам вакансії (свої сили можна було оцінити ще до початку виконання тестового).
Джуну потрібний саме відгук від компаній, навіть не оплата. Компанії, які наймають початківців, прекрасно розуміють, що джуни — «пластилін», з якого можна ліпити що завгодно. Але для цього треба хоча б намагатися надати йому форми. Якщо кандидат не пройшов у компанію джуном, є ймовірність, що через рік-два він повернеться туди мідлом, якщо в нього залишаться приємні враження від першого спілкування.
Мені здається, що повномасштабна війна не має сприяти зміні тестових. Вважаю, що стрес/зовнішні чинники на тестове мають впливати не більше, ніж на звичайну роботу.
Також ми запитали кілька компаній про те, що вони думають про тестові завдання для технічних спеціалістів: чи передбачено це в їхньому найму у 2023 році, хто готує тестові в компанії й перевіряє їх та чи завжди є фідбек для кандидатів.
GlobalLogic
Тестові завдання ми даємо у двох випадках:
- Коли це є додатковою умовою під час пошуку і підбору спеціаліста. Тоді рекрутер дає кандидату тестове завдання, рішення якого надсилають на розгляд технічній команді разом з резюме та іншими деталями. На основі цього команда ухвалює рішення, чи запрошувати людину на співбесіду.
- Якщо після технічної співбесіди залишилися уточнення або питання щодо досвіду спеціаліста і відповідності вимог проєкту до досвіду кандидата. Попередні приклади робіт, викладені на репозиторіях, не завжди висвітлюють потрібний досвід для певного проєкту/ролі. Завдання пишуть індивідуально і під певну роль, а рішення дає змогу роздивитися саме потрібний досвід і логіку у виконанні тестового.
Щодо формату і часу на тестові — наразі нічого не змінилося. Зазвичай рішення потрібно записати в текстовий документ. Тестове завдання має займати не більше як
Тестові завдання та їхні умови — це завжди індивідуальний підхід, адже всі проєкти різні, як і стек, завдання. Тому в написанні умов ТЗ бере участь суто команда, в яку ми шукаємо людину. Ця ж команда і перевіряє його.
Тестові, які кандидат отримує на самому старті від рекрутера, ми не оплачуємо. Вони не потребують багато часу й зусиль від кандидата, який потенційно підходить для ролі.
Рекрутер упродовж одного бізнес-дня має надати фідбек щодо співбесіди чи виконання технічного завдання. Якщо є затримка з боку технічної команди чи розгляд триває довше, ніж день, рекрутер тримає кандидата в курсі. А якщо в спеціаліста є свої аргументи на відгук, рекрутер передає їх технічній команді. І це теж може спрацювати на користь кандидата.
Наразі ми шукаємо інженерів, які пишуть код або алгоритми чи описують тест-кейси — і все це ручна робота. Тож технічні завдання — це саме опис практики й логіки. І тут не допоможе ChatGPT.
Intetics
В Intetics здебільшого намагаються обходитися без технічних завдань. Ми вважаємо, що це додатковий час, витрачений кандидатами, та не кожен спеціаліст готовий до цього. Відповідно є ризик втратити цікавого кандидата та уповільнити найм. Утім є випадки, коли це необхідно та обумовлено вакансією, проєктом тощо. Тоді спеціалісти компанії намагаються зменшити час на виконання завдання або навіть інтегрувати його в технічну співбесіду.
Зазвичай за підготовку тестових відповідають технічні спеціалісти, які працюють на тому ж проєкті, куди шукають людину.
Якщо тестове оцінює внутрішній технічний спеціаліст Intetics, то з боку компанії намагаються надавати фідбек якомога скоріше та розгорнуто. Коли до оцінювання долучається спеціаліст з боку клієнта, ситуація із часом та форматом відгуку може різнитися. Проте в компанії намагаються контролювати ці процеси.
У деяких випадках тестове завдання оплачуємо. Сума винагороди залежить від рівня вакансії та приблизного часу на виконання цього завдання й відповідає середньому рейту для рівня кандидата.
Intellias
Тестові завдання не є обов’язковими в Intellias. При відборі кандидатів на більшість позицій їх немає. І лише іноді клієнтське інтерв’ю має нескладні тестові завдання. Виконання тестових ми не оплачуємо.
За підготовку технічних завдань відповідає наш технічний експерт або клієнт Intellias.
Кандидат отримує фідбек за кожен етап, що передбачені у процесі інтерв’ю, зокрема й за тестове, якщо воно є.
Залежно від технологічних потреб, у тестові додають завдання, що схожі на майбутні обов’язки людини на проєкті. Вони можуть оновлюватися відповідно до вимог вакансії, якщо з’являється нова технологія або бізнес-потреба.
Avenga
У
Тестове — це радше виняток, ніж правило, й воно обумовлене вимогами конкретного проєкту чи клієнта. Також інколи тестове завдання є в рекрутинговому процесі для більш «творчих» позицій, наприклад SMM Specialist, Graphic Designer тощо. Воно допомагає розкрити потенціал і досвід кандидатів і співвіднести його з вимогами вакансії.
Наразі ми не практикуємо оплату тестових завдань, проте формуємо їх таким чином, щоб кандидати витрачали мінімум часу. Завдання для технічних позицій розробляє Engineering Director і технічні спеціалісти з урахуванням особливостей проєкту та вимог вакансії. Перевіряють теж спеціалісти, що залучені в рекрутинговий процес на конкретну вакансію. Вони ознайомлюються з кожним тестовим. Зі свого боку ми стараємося надати розгорнутий відгук, де виділяємо сильні сторони й зони зростання, щоб виконання завдання принесло користь і самому кандидату.
