Питання, яке нам ставлять на кожній демці: "Ви ж бачите, що кандидат писав сам, а що — Copilot?"
Ні. Не бачимо. І не хочемо бачити.
Чому не хочемо
У прод-коді 2026-го року середній інженер у вашій команді вже пише ~40–60% коду з AI-асистентом. Це не прогноз, це вимірюване число з нашої когорти 3400 розробників. Якщо ваш скринінг обирає людей, які не користуються AI, — ви відбираєте людей, які в реальній роботі будуть повільніші за медіану.
Питання, яке насправді треба ставити: чи вміє кандидат користуватись AI відповідально?
Дві властивості калібрувальної задачі
1. Контекст ширший за вікно промпту
Якщо всю задачу можна скопіювати в одне повідомлення асистенту — ви тестуєте промпт-інжиніринг, а не інженерне мислення.
Наші задачі включають:
- модуль на 800–3500 рядків коду, з якого релевантні ~15%;
- 2–4 сусідні модулі, які кандидат має знайти сам;
- historical context у git-історії (коміти, що пояснюють, чому саме так);
- реальні тести, деякі з яких падають неочевидним чином.
Кандидат має вирішити, що саме подати асистенту. Це найважливіше рішення в задачі — і воно не передається в промпт.
2. Найочевидніше рішення ламає невидимі інваріанти
Типовий патерн: є функція, яку треба "трохи змінити". AI радісно генерує зміну. Вона компілюється. Зелені тести проходять. Але один тест, який спеціально тестує інваріант, ламається — і кандидат має зрозуміти, чому.
Приклад з нашого senior-task каталогу:
У білінговому модулі
calcTax(amount, country)треба додати підтримку України з опцією exempt-планів. AI запропонує early-return. Але в модулі є інваріант:taxне може бути відʼємним для жодної країни. Exempt-план з промо-знижкою в деяких гілках дає tax = amount − discount < 0. Тест зproperty-basedперевіркою це ловить.
Це не "trick question". Це звичайний робочий день у legacy-коді. І AI тут не перешкода — просто він вирішує першу проблему, не бачачи другу.
Що ми НЕ робимо
- Не забороняємо AI. Це примусило б кандидата прикидатись, що він його не використовує. Ми хочемо побачити, як він його використовує.
- Не ловимо "AI-fingerprint" у коді. Це анти-метрика. Якщо ваша рубрика наказує кандидату писати "ненатурально людський" код — ви оптимізуєтесь у протилежний бік від продуктивності.
- Не вимірюємо швидкість. Задача проєктована на 45–120 хвилин, але ми не карає за 4 години роботи. Карає — за 12 хвилин з unreviewed AI-слопом.
Сигнали, які ми насправді ловимо
У реальній роботі з AI відрізняються ці поведінки:
| Новачок з AI | Сеньйор з AI |
|---|---|
| Копіює пропозицію цілком | Приймає по фрагментах, інші — відкидає |
| Не пише додаткові тести | Пише тести специфічно на edge-кейси пропозиції |
| Підлаштовує код під AI-архітектуру | Підлаштовує промпт під існуючу архітектуру |
| Коміти: "implement feature" | Коміти: "fix UA VAT exempt; keep non-negative tax invariant" |
| Відповідь на ревʼю: "AI так написав" | Відповідь на ревʼю з обґрунтуванням чи визнанням помилки |
Рубрика ловить різницю не по тому, що кандидат НЕ використовує AI, а по тому, що він розуміє межі його компетенції.
Практичний висновок
Якщо ви зараз проєктуєте тестові завдання для кандидатів, мінімальний checklist:
- Чи містить задача ≥2 файлів, з яких релевантність треба визначити самому?
- Чи є хоча б один інваріант, який не виражається в типовій сигнатурі функції?
- Чи бачить кандидат чому саме існуючий код був написаний саме так?
- Чи можна змінити задачу так, щоб наївний single-prompt до AI її не вирішив — не через заборону, а через структуру?
Якщо відповідь "так" на всі чотири — ви калібрували під 2026. Якщо ні — ви калібрували під 2019.