Ця стаття — для людини, яка закриває вакансії. Не програміста. Ми розберемо, що ви робите у merged і що робить система, щоб на фінал до hiring-менеджера дійшов кандидат, в якому ви впевнені.
Ніякого коду. Ніяких абревіатур, які не пояснені в тексті.
Що таке merged у двох реченнях
merged — це технічний скринінг, який не вимагає від вас дзвонити інженеру-ревʼюеру. Замість "live coding" кандидат робить невелику реальну задачу в коді, а система автоматично оцінює результат за рубрикою, яку склав ваш staff-інженер.
Ви отримуєте звіт, з якого видно пройшов / не пройшов / на межі — і чому саме.
Крок 0: налаштування (один раз на вакансію)
Ви заводите роль. Це займає ~10 хвилин:
- назва позиції, грейд (middle / senior);
- стек (TypeScript, Go, Python тощо);
- хто з інженерів замовника калібрує задачу — ми пишемо йому один раз, далі він сам.
Далі staff-інженер замовника один раз витрачає 3–4 години: вибирає шматок репо, формулює задачу, погоджує рубрику. Це робота, яку він робив би все одно, якби сам вів скринінг — тільки у нас це артефакт, яким потім користуються сотні разів.
Крок 1: ви запрошуєте кандидата
Коли у воронці зʼявляється релевантний кандидат, ви натискаєте "Надіслати задачу". Кандидат отримує листа з:
- посиланням на задачу;
- чіткою оцінкою часу (медіана по поточній задачі — наприклад, 1 год 15 хв);
- дедлайном (за замовчуванням — 5 днів, ви можете змінити);
- посиланням на FAQ для кандидатів.
Ваша дія тут — одна кнопка. Ми не питаємо у вас код-рівʼю і не просимо вказувати складність.
Крок 2: кандидат виконує задачу
Кандидат працює у себе: у своєму редакторі, зі своїми звичками, з AI-асистентом, яким користується щодня. Ми не ставимо йому камеру, не блокуємо AI і не міряємо швидкість.
Що система бачить під час роботи:
- факт старту;
- факт відправки результату (pull request — це такий "пакет змін", який інженери роблять щодня);
- автоматичні прогони тестів.
Що ми не бачимо і свідомо не ловимо: який саме редактор, який AI, скільки разів кандидат дивився в StackOverflow. Це не наша справа.
Крок 3: автоматична оцінка (~2 хвилини)
Після того як кандидат відправив результат, система запускає оцінку. Це займає близько двох хвилин. За цей час:
- прогоняються тести (автоматичні перевірки, які писав ваш інженер);
- LLM-суддя (це Claude від Anthropic, один з провідних AI-судівників у галузі) оцінює код по 8–12 критеріях рубрики;
- формується звіт українською.
Крок 4: ви читаєте звіт
Звіт має три рівні деталізації:
- Верхня лінія: pass / fail / borderline, і чому.
- Середня секція: 4–5 ключових сигналів, кожен — 1–2 речення людською мовою. "Тести перевіряють поведінку системи, а не її внутрішню реалізацію — це правильний підхід." "Commit-повідомлення розмиті, не пояснюють мотивацію змін — може бути червоним прапорцем у великих командах."
- Технічна секція: для hiring-менеджера, якщо він захоче заглибитись.
Ви читаєте верхню і середню секцію. Цього достатньо, щоб:
- вирішити, йти з кандидатом далі чи ні;
- сказати hiring-менеджеру конкретну причину, якщо кандидат не пройшов;
- підготувати 2–3 питання на фінальний дзвінок на основі сигналів зі звіту.
Крок 5: фінал
На фінал у hiring-менеджера йдуть тільки кандидати з pass або borderline. Для них зустріч стає обговоренням рішень і мотивації, а не перевіркою чи вміють вони програмувати взагалі.
За нашими даними з закритої бети: hiring-менеджери скоротили середню кількість технічних зустрічей з 3–4 до 1. Фінал став коротшим (30–45 хвилин замість години) і змістовнішим.
Чого ми не робимо
- Не ранжуємо кандидатів по балу. Бал — це gate, а не рейтинг. Два кандидати з "pass" однаково годяться для фіналу — далі вирішує людина.
- Не пропонуємо "sourcing" чи ATS. Ми працюємо з вашим існуючим ATS і вашою воронкою. Ми — одна станція, не конвеєр.
- Не караємо за використання AI. Якщо ваш інженер у 2026 році не користується AI — у вас інша проблема.
Типові питання
"А якщо кандидат зловживає AI і здасть сміття?" Це саме те, що ловить рубрика. Якщо людина скопіювала першу пропозицію асистента без розуміння — тести впадуть, код не зматчить існуючі інваріанти, commit-повідомлення будуть порожні. Це не сіра зона, це чіткий fail.
"А якщо у нас senior-роль з сильним дизайном?" У такому випадку merged — тільки першовий фільтр. Ми поки не закриваємо staff-level дизайн-рішень автоматично. Для таких ролей ми рекомендуємо merged-скринінг + окрему system-design сесію в hiring-менеджера.
"Скільки це коштує?"
Цю частину контракту не друкуємо в блозі — пишіть на [email protected]. Ми працюємо з pay-per-screening і annual license; модель залежить від вашого обсягу.
Що далі почитати
Якщо хочете зрозуміти, що саме оцінюється в звіті і чому цим критеріям можна довіряти — читайте "Звіт по кандидату: що означає кожен пункт". Якщо ж вам цікаво, як це все працює під капотом — у нас є серія технічних статей про рубрику і LLM-суддю.