Питання для інтерв'ю

AI-агент бере на себе рутинну частину підготовки до інтерв'ю: читання резюме, зіставлення з описом вакансії та складання чернетки запитань. Рекрутер перестає починати щоразу з чистого аркуша і отримує структурований сценарій, який залишається лише перевірити та доопрацювати під контекст конкретного кандидата.

Типовий робочий процес:

1. Рекрутер або hiring manager завантажує резюме кандидата та опис вакансії в систему — через інтеграцію з HRIS або напряму у файлове сховище.
2. AI-агент вилучає ключові компетенції з опису ролі та зіставляє їх із досвідом, зазначеним у резюме.
3. Агент формує чернетку списку запитань: behavioral, technical, situational — залежно від рівня ролі та стадії інтерв'ю.
4. До кожного запитання додається контекст із резюме — конкретний проєкт, навичка або прогалина в досвіді, яку варто прояснити в розмові.
5. Готовий сценарій зберігається в HRIS або доступний рекрутеру у вигляді документа перед зустріччю.
6. Після інтерв'ю рекрутер відзначає, які запитання спрацювали найкраще, і зворотний зв'язок враховується під час генерації майбутніх сценаріїв.

Результат — кожен кандидат отримує інтерв'ю, адаптоване під його досвід, а не уніфікований опитувальник для всіх. Це особливо важливо на позиціях middle+, де поверхневі запитання не дають сигналу про реальні навички.

Що автоматизація НЕ робить

• Не приймає рішення про найм — це залишається завданням рекрутера та hiring manager, які спираються на живе обговорення та експертизу.
• Не замінює живий діалог: згенерований сценарій — це чернетка, а не жорсткий скрипт, від якого не можна відступити в розмові.
• Не оцінює soft skills або культурну відповідність автоматично за відповідями — для цього потрібна людська інтерпретація.

Підхід потрапляє в категорію «генерація контенту (чернетки)»: AI готує перший варіант, людина валідує та відправляє в роботу. Це знімає навантаження з креативної частини роботи рекрутера, але залишає фінальний контроль якості в руках команди.

Технічна реалізація використовує no-code стек: зв'язку automation-платформи (наприклад, workflow-рушій або Zapier), LLM-провайдера та сховища документів. Рекрутер не пише код — налаштування зводиться до конфігурації вузлів і промптів.

Потік даних

Дані йдуть по передбачуваному маршруту: джерело резюме → обробка LLM → генерація сценарію → доставка рекрутеру.

1. Тригер. Нове резюме з'являється у файловому сховищі (Google Drive, Dropbox, SharePoint) або в модулі кандидатів HRIS. Automation-платформа відловлює подію.
2. Вилучення тексту. З PDF або DOCX вилучається текстовий шар. Для сканів додається OCR-крок — це збільшує час обробки.
3. Завантаження опису вакансії. Паралельно система забирає актуальний job description з HRIS або з попередньо визначеного документа.
4. Виклик LLM. Резюме та опис вакансії надсилаються в промпт разом із шаблоном: «склади N питань за компетенцією X, прив'яжи їх до конкретних пунктів резюме».
5. Структурування відповіді. LLM повертає сценарій у структурованому форматі (Markdown або JSON), який простіше парсити та оновлювати.
6. Доставка. Готовий сценарій зберігається назад у HRIS (прикріплюється до картки кандидата) або надсилається рекрутеру у вигляді документа та сповіщення в месенджері.

Компоненти рішення

Кроки впровадження

1. Визначення шаблонів. Команда HR формулює, які типи питань потрібні для різних ролей (junior/middle/senior, engineering/sales/ops). Це перетворюється на набір промпт-шаблонів.
2. Налаштування інтеграцій. Підключення automation-платформи до HRIS та файлового сховища через готові конектори. На цьому кроці перевіряється, що система має права на читання резюме та job description.
3. Промпт-інжиніринг. Ітеративне налаштування промптів: прогін 10–20 резюме, порівняння згенерованих питань із тим, що склав би рекрутер вручну.
4. Налаштування виводу. Вибір формату сценарію — Markdown-документ, сторінка в Notion, картка в HRIS. Команда визначає, де зручніше працювати з результатом.
5. Пілотний запуск. Паралельна робота: рекрутер готує питання і вручну, і через агента, потім порівнює. Збирається фідбек за 2–3 тижні пілоту.
6. Розгортання на команду. Після пілоту — навчання решти рекрутерів (1–2 години), додавання feedback-loop для збору оцінок після інтерв'ю.

Контроль якості

Генерація контенту через LLM потребує контролю: модель може упустити контекст або видати шаблонне питання. Мінімальний набір перевірок — це обов'язковий людський review перед відправкою сценарію в роботу, періодичний аудит якості за вибіркою та явна заборона на формулювання дискримінаційного характеру (за віком, статтю, сімейним станом). В конфігурацію промпту закладаються правила, що відповідають політиці компанії та законодавству про захист даних.

Для запуску автоматизації команді потрібен мінімальний набір даних і доступів. Більшість SMB вже має все необхідне — достатньо HRIS або хмарного сховища для документів.

Дані та доступи

• Актуальні описи вакансій з переліком ключових компетенцій і вимог.
• Резюме кандидатів у цифровому вигляді (PDF або DOCX з текстовим шаром).
• Доступ на читання до HRIS або файлового сховища, де зберігаються резюме.
• Право на запис назад — для прикріплення сценарію до картки кандидата.
• Обліковий запис у LLM-провайдера з активним API-ключем і лімітом, що покриває очікуваний обсяг інтерв'ю.

Готовність команди

• Один відповідальний за налаштування — рекрутер або HR ops, готовий витратити 1–2 тижні на налаштування шаблонів і промптів.
• Згода рекрутерів працювати з чернеткою і доводити її до фінального сценарію, а не чекати «ідеального» результату від моделі.
• Домовленість з юристом або DPO про те, що резюме кандидатів можна передавати у зовнішню LLM-модель (або використовується enterprise-версія з обробкою у потрібній юрисдикції).

Таймлайн за етапами

Складність weekend означає запуск MVP-версії за 2–4 тижні:

1. Налаштування інтеграцій і шаблонів вакансій — 3–5 робочих днів.
2. Промпт-інжиніринг на вибірці з 10–20 резюме — 3–5 робочих днів.
3. Пілот з однією командою рекрутерів і збір зворотного зв'язку — 1 тиждень.
4. Розгортання на решту рекрутерів — 1–2 дні навчання.

Якщо HRIS відсутній і резюме розкидані по пошті, додається крок зі збору даних у єдине сховище — це подовжує запуск до 4–6 тижнів.