DICEUS

Мій досвід взаємодії з вакансією

Мене самостійно знайшов HR у LinkedIn та запропонував розглянути вакансію. Після короткого спілкування мені вислали масштабне тестове завдання — розробити телеграм-бот із сучасною архітектурою, повною інтеграцією, підготовкою Docker-контейнера, розгортанням у хмарі, написанням README, документації, юніт-тестів, колекції Postman, а також підготовкою робочого посилання на бота і (за бажанням) відеопрезентації.
Що мене не влаштувало:

Об’єм тестового завдання: воно рівнозначне типовому комерційному проекту або фриланс-замовленню, а не етапу відбору.

Вимоги до повної «упаковки»: документація, деплой, діаграми, Docker та супровідні матеріали потрібні для production, а не для демонстрації навичок на співбесіді.

Суворе покриття тестами: обов’язковість юніт-тестів та повної документації значно збільшує часові витрати й зміщує фокус зі змісту на «обгортку».

Ставлення до подібних практик

В сучасному ІТ такі практики негативно сприймаються:

Занадто великий об’єм роботи як для тестового завдання, особливо коли ти не шукаєш вакансію, а до тебе звертається компанія.

Відсутність гарантій навіть на фідбек після багатьох витрачених годин або днів.

Кваліфіковані розробники часто відмовляються співпрацювати з компаніями, які пропонують завдання рівня готового комерційного продукту без жодної компенсації.

Чому я відмовився виконувати це завдання

Неадекватність очікувань: компанія висуває вимоги до «готового продукту», а не до демонстрації технічної бази.

Акцент на деталях production, а не на перевірці професійних навичок: реакція більше нагадує фріланс-тендер, ніж якісний рекрутинг.

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

Побажання компаніям

Переглядайте масштаб тестових завдань: завдань на 2–4 години достатньо для технічної оцінки.

Якщо потрібен повний production або «упаковка» — пропонуйте оплату праці.

Зосереджуйтесь на перевірці основних технічних навичок, а не вмінні готувати повноцінний проект до деплою.

Висновок

Відмовився від виконання завдання й рекомендую розробникам оцінювати свої ресурси та час тверезо, а компаніям — цінувати кандидатів і фокусуватися на суть, а не на обгортку. Тестове завдання — це інструмент технічної перевірки, а не спосіб отримати production-проект безкоштовно.