Тестове завдання в українських IT-компаніях: формат, оцінка, типові помилки

Скільки компаній досі дають тестові

У матеріалі DOU про те, чи «вбив» ШІ тестові для розробників, компанії розповідають по-різному. Це слова їхніх представників, а не загальна статистика ринку:

• ZONE3000 каже, що тестові є приблизно для 80% вакансій, а півтора року тому було близько 40%.
• Ciklum проводить 60-хвилинне технічне тестування на HackerRank (алгоритми, програмування, бази даних, хмарні технології).
• Ajax Systems залишає тестові для частини напрямів (Embedded, Mechanical, Hardware, C/C++); формат залежить від вакансії: домашнє завдання, live coding або завдання з обмеженням часу під час співбесіди.
• EPAM оцінює знання й аналітичне мислення на технічній співбесіді; Universe прибрала тестові два роки тому; Mate academy дає замість них задачу на system design; Levi9 вважає, що домашні завдання можуть відлякувати кандидатів.

Висновок для вас: не припускайте, що тестове буде (або що його не буде). Спитайте. Ці дані на момент написання беруться з однієї статті DOU; чи змінилась політика цих компаній зараз, не підтверджено.

Три формати тестового

1. Домашнє завдання

Ви отримуєте умову, робите вдома й надсилаєте технічним експертам. Автор матеріалу на dev.ua зазначає, що саме через домашнє виконання незрозуміло, чи людина писала код сама, але в розмові з кандидатом це зазвичай помітно. Кандидати на DOU скаржаться на нечіткі вимоги та довгі дедлайни («до понеділка» фактично означає роботу на вихідних).

2. Онлайн-тест із таймером

Платформа з жорстким лімітом (приклад Ciklum: 60 хвилин). Тут важливо тренуватися саме в такому режимі: перша хвилина на читання умови, друга на план, і лише потім код. Про платформу заздалегідь уточніть, чи є запис екрана чи камери: правила в кожної різні.

3. Live coding на співбесіді

Задача розв'язується разом з інтерв'юером. За словами Sigma Software з тієї ж статті DOU, вони дають завдання, наближені до реальних проєктів (незнайомий код, фіче-реквест, частково задокументований проєкт) і дивляться на сам процес: план, звуження задачі, уточнювальні питання. Тому говоріть уголос, що ви робите й чому.

Як оцінюють тестове

Офіційних універсальних рубрик оцінювання в українських компаніях ми не знайшли, тож нижче лише те, що прямо сказано в двох опублікованих матеріалах, і наші практичні висновки (позначені окремо).

• Оформлення проєкту. За dev.ua, на що дивляться в репозиторії: тести, README, коментарі, чистота й структура коду, зрозуміло названі методи й файли, коментарі в складних місцях, дотримання кодстайлу.
• Пояснення рішення. Той самий автор просить покроково описати, як кандидат реалізував би фічу: які файли створить, як структурує проєкт, чому обрав таке рішення. Також питає про досвід, архітектуру та інтеграції.
• Робота з ШІ. Представники компаній, яких цитує DOU, кажуть різне: Railsware заохочує використання ШІ-інструментів; Maklai та appflame не забороняють, але головний червоний прапорець для них — бездумне використання; appflame відмовляє кандидатам, які не змогли відповісти на додаткові питання щодо повністю згенерованого завдання. ZONE3000 шукає фахівців, які керують роботою ШІ й критично оцінюють результат.
• Жоден фактор не вирішальний. Автор dev.ua зазначає: якщо репозиторій сильний, а відповіді слабкі, варто спершу розібрати код разом із кандидатом.

Типові помилки (наш висновок)

Це не статистика, а узагальнення з прочитаного вище й загальної практики; перевіряйте на вимогах конкретного завдання.

1. Здати код, який не можете пояснити. Якщо вас попросять розповісти, чому саме так, а ви не можете — це найгірший сценарій; appflame прямо відмовляє в таких випадках.
2. Ігнорувати умову. Пропущена вимога коштує більше, ніж відсутність «красивої» архітектури. Складіть чекліст вимог і закресліть кожну.
3. Без README. Напишіть, як запустити, що вирішили й чого не встигли.
4. Без тестів і обробки помилок. Навіть кілька змістовних тестів покажуть культуру.
5. Один великий коміт. Розбийте роботу на кроки: історія змін теж розповідає про ваш процес.
6. Перевантажити рішення. Рішення, що перевищує обсяг, який просять, відбиває бажання його перевіряти.
7. Не питати про критерії. Уточніть, скільки часу компанія очікує, і не виходьте за нього.
8. Приймати результат ШІ без перевірки. Автор dev.ua зауважує, що згенерований код часто не працює і його треба перевіряти й виправляти.

План підготовки

1. Тренуйтеся в трьох режимах: 60 хвилин із таймером, 3–4 години домашнього міні-проєкту, 30 хвилин лайвкодингу вголос із другом.
2. Тримайте публічний репозиторій. Автор dev.ua замість тестового просить посилання на нього; це свідчить, що кандидат не боїться ділитися напрацюваннями.
3. Пояснюйте рішення. Після кожної задачі запишіть 3 речення: що, чому так, що б поліпшили.
4. Для QA дивіться окремий матеріал: питання на співбесіді для QA.
5. Загальна підготовка: підготовка до технічної співбесіди та фреймворк для system design.
6. Англійська. Частину співбесіди можуть провести англійською: технічна співбесіда англійською.

Про формат домашніх завдань загалом (англійською) див. take-home assignment interview.

Що з ШІ: правила й чесна позиція

З матеріалу DOU видно, що політика різна: від «заохочуємо» до «не змогли пояснити — відмовляємо»; EPAM, за їхніми словами, має внутрішню платформу, що виявляє порушення правил. Тому єдиний безпечний шлях: спитати рекрутера перед тестовим, що дозволено (ШІ-помічники, документація, пошук), і дотримуватися відповіді. Якщо заборонено — не користуйтеся. Якщо дозволено, відповідальність за результат усе одно ваша: ви маєте розуміти кожен рядок.

У цьому контексті Interview Copilot можна використовувати для підготовки й там, де це прямо дозволено: це десктопний оверлей, що слухає системний звук дзвінка й дає підказки в реальному часі, а також розв'язує задачі зі скріншота; є безкоштовний план без картки. На macOS і Windows вікно просить ОС не потрапляти в захоплення екрана, на Linux воно видиме, тож результат залежить від програми демонстрації: спершу перевірте приватним показом. Докладніше: безкоштовний план і помічник для кодових співбесід.

Що робити в день виконання

• Перечитайте умову двічі та запишіть вимоги списком.
• Запитайте про неоднозначності (якщо можна), а якщо ні — зафіксуйте припущення у README.
• Спершу мінімальний робочий варіант, потім покращення.
• Перед відправкою запустіть із нуля за власною інструкцією з README.
• Підготуйтеся розповісти рішення за 2–3 хвилини: структура, ключові рішення, компроміси, що зробили б далі.

Джерела

• DOU — «Складно придумати завдання, яке не можна кинути…»: чи вбив ШІ тестові для розробників
• dev.ua — блог про співбесіду з програмування (тестове завдання, публічний репозиторій)

Перевірено 13.11.2026. Цифри й позиції компаній — зі слів їхніх представників у наведених матеріалах; актуальні правила уточнюйте в рекрутера.

Як тут допомагає застосунок

Схожі статті

Читайте далі