Ми часто чуємо від рекрутерів: "Я розумію, що звіт — це добре, але як мені його перечитати, коли я не писала коду ні дня?"
Коротка відповідь: верхні дві секції звіту — саме для вас. Третя секція — для hiring-менеджера. Розберемо по порядку.
Структура звіту
Звіт має фіксовану структуру. Ми не міняємо її від задачі до задачі — це дозволяє вам після 3–5 звітів упевнено розуміти, куди дивитись.
- Верхня лінія: результат одним словом + одне речення чому.
- Сигнали: 4–5 головних спостережень.
- Технічні деталі: рубрика з оцінками, приклади з коду.
Вам потрібні секції 1 і 2.
Верхня лінія: три стани
У верхній лінії завжди один з трьох станів:
Pass (зелений). Кандидат справився впевнено. Можна призначати фінал. Наше правило: "pass" = такого сигналу нам достатньо, щоб ви не соромились витратити годину hiring-менеджера.
Borderline (жовтий). Кандидат близько до порогу, але щось бентежить. Зазвичай це або "технічно зробив, але скоріш за все списав у AI без розуміння", або "хороший вайб, але напівпуста задача". Borderline — це привід для додаткового розмовного скринінгу, не для відмови.
Fail (червоний). Не дотягнув. Важливо: fail — це не "кандидат поганий". Це "ця конкретна задача показала, що по критеріях для цієї ролі не проходить". На іншу роль (нижчий грейд, інший стек) та сама людина може пройти впевнено.
Поряд з станом — коротке чому, наприклад: "Задача виконана, але тести не покривають ключовий edge-кейс, який критичний для цієї ролі. Borderline."
Секція сигналів
Тут 4–5 пунктів. Кожен — одне спостереження, сформульоване звичайною мовою. Ось найпоширеніші категорії сигналів і що вони означають:
Сигнали по тестах
"Кандидат додав тести на нові сценарії" — це дуже добрий сигнал. Означає, що людина не просто "робить, щоб працювало", а думає про надійність.
"Тести проходять, але не перевіряють нову поведінку" — тривожний сигнал. Формально все зелене, але по суті роботи не зроблено. Часто буває, коли кандидат покладається на AI без перевірки.
"Тести перевіряють внутрішню реалізацію, а не зовнішню поведінку" — техні́чний нюанс: це означає, що тести крихкі й доведеться переписувати при будь-якій зміні. Не драматично, але сигналізує про не зовсім зрілий стиль.
Сигнали по комітах
Коміти — це "історія змін", яку інженер пише, коли здає роботу. Як журнал лікаря.
"Атомарні коміти з ясними повідомленнями" — людина вміє розкладати роботу на зрозумілі кроки. Це важливо у великих командах.
"Один великий коміт з повідомленням 'fix'" — тривожний сигнал у senior-ролях. У junior-ролях — прийнятно, але варто звернути увагу.
Сигнали по ревʼю
Після відправки кандидат отримує автоматичні коментарі-питання ("а що буде, якщо ...?"). Його відповіді — це секція ревʼю.
"Відповідає змістовно, визнає недогляди, коректно аргументує" — найсильніший soft-сигнал. Так виглядає доросла технічна комунікація.
"Відповідає оборонно або ігнорує питання" — жовтий прапорець для команд з активною ревʼю-культурою.
"Не відповів на коментарі" — не обовʼязково fail, але точно borderline, особливо для senior.
Сигнали по фокусу
"Зміни сфокусовані, не зачіпають нерелевантні файли" — добре. Людина знає, де зупинитись.
"Зміни зачіпають багато нерелевантних файлів" — або людина не розуміє скоупу задачі, або "прилетіла" через AI-пропозиції, що оптимізують усе навколо. У продакшні це створює конфлікти і ускладнює ревʼю.
Чого у звіті НЕ буде
Ми свідомо не пишемо у звіті таких речей:
- Особистісних характеристик. "Здається розумним", "впевнений у собі". Ні. Ми міряємо артефакт, а не людину.
- Швидкісних оцінок. "Зробив за 45 хвилин" — не сигнал. Хтось із кращих кандидатів сидить 2 години, бо ретельно перевіряє.
- Порівняння з іншими кандидатами. Жодних "8-й з 12". Кандидат або проходить планку, або ні — планка абсолютна, не відносна.
Якщо ви бачите в звіті щось, що схоже на такі формулювання — напишіть нам, це баг.
Як говорити про звіт з hiring-менеджером
Ось три короткі шаблони, які працюють.
Якщо pass:
"Кандидат пройшов технічний скринінг. Сильні сигнали: тести, фокус змін, змістовні відповіді на ревʼю. Пропоную фінал 45 хв — зосередитись на мотивації і командному фіті."
Якщо borderline:
"Кандидат на межі. Задача зроблена, але [один конкретний сигнал зі звіту]. Пропоную 30-хв дзвінок з технічним колегою до фіналу, щоб перевірити саме цей момент."
Якщо fail:
"Кандидат не пройшов скринінг на цю роль. Основна причина: [одне речення зі звіту]. Якщо у вас є роль нижчого грейду — можна передивитись для неї."
Ці шаблони працюють, бо звіт дає вам конкретні формулювання, на які можна спертись, а не абстрактне "не зовсім те".
Коли варто перевірити звіт ще раз
Хоча LLM-суддя дає 87% узгодженості з сеньйором, 13% — це не нуль. Ми рекомендуємо уважніше передивлятись звіт, якщо:
- кандидат дуже близько до порогу pass/fail (borderline);
- ви знаєте попередні роботи кандидата, і звіт їм суперечить;
- hiring-менеджер запитав "а чому саме так".
У таких випадках у звіті є посилання "запросити second opinion" — це виклик живого інженера merged, який за 24 години дає незалежну оцінку. Це безкоштовно в межах підписки, ми це свідомо зробили стандартним.
Що ви насправді вмієте після 10 звітів
Наш досвід: у рекрутера, який прочитав 10 звітів merged, зʼявляється інтуїція, яка до цього вимагала 3–5 років hands-on hiring-досвіду в tech. Ви починаєте впевнено говорити з інженерами про технічні сигнали — не вдаючи, що ви самі інженер, а опираючись на структурований артефакт.
Це і є основна цінність merged для вас: не "ми економимо ваш час" (хоча так), а "ми даємо вам мову".