Technical Context
Я розглядаю цю дискусію не як «чітерство кандидатів», а як нову поверхню атаки на ваш процес оцінювання. У чаті колеги обговорюють, як зрозуміти, що кандидат читає відповіді з екрана, і діляться посиланням на textream.fka.dev — тулзу, яку називають «суфлером для підказок». Паралельно звучить робочий консенсус: відходити від питань на загальні знання і «прожарювати» досвід з резюме — конкретні проєкти, конкретні рішення, конкретні компроміси.
Що мене як архітектора чіпляє: технічно LLM-підказки сьогодні майже не вимагають інтеграцій. Кандидату достатньо другого екрана, оверлея або окремого вікна. Багато інструментів такого класу не зобов'язані бути широко відомими або індексуватися — вони можуть бути нішевими, self-hosted, швидко змінювати домени. Тому спроба «заборонити Textream» як сутність — хибна ціль. Правильна ціль — зробити так, щоб підказки не давали кандидату пройти ваш фільтр без реальної компетенції.
В обговоренні звучить спостереження «по очах видно, як бігають по рядках». Так, поведінкові маркери іноді ловлять підказки, але я не будую на цьому захист. По-перше, це погано масштабується і суб'єктивно. По-друге, кандидати швидко адаптуються: камера вище, текст ближче, паузи природніші. По-третє, ви ризикуєте помилково покарати сильного інженера з особливостями комунікації.
Технічно у вас є три площини контролю:
- Зміст питань: наскільки вони прив'язані до особистого досвіду і вимагають контексту, якого немає в LLM.
- Формат взаємодії: живе спільне рішення, відлагодження, робота з артефактами, а не монолог.
- Інструментальний контур: мінімальний прокторинг/логування там, де це виправдано ризиком і юридично коректно.
Офлайн-інтерв'ю, як зауважили колеги, дійсно надійніше. Але я в реальних проєктах бачу, що повністю офлайн — розкіш: розподілені команди, швидкість найму, географія. Отже, потрібно проєктувати «віддалено-стійке» інтерв'ю, а не мріяти про повернення в переговорки.
Business & Automation Impact
Якщо ви наймаєте інженерів, аналітиків, продукт-менеджерів або навіть операторів процесів, LLM-суфлер перетворює класичне інтерв'ю на поганий датасет. Ви думаєте, що відібрали сильних, а насправді купили красиву мову і шаблонні відповіді. Ціна помилки — не тільки зарплата. Це зрив термінів, токсичність у команді, роздування технічного боргу і повторний цикл найму.
Хто виграє в новій реальності? Компанії, які вміють оцінювати процес, а не «правильність відповіді». Програють ті, у кого інтерв'ю — це список питань з інтернету і перевірка термінів. Я це бачу постійно: як тільки питання має «ідеальний абзац» з LLM, воно перестає розрізняти рівні.
Я перебудовую інтерв'ю навколо артефактів кандидата і вашої реальності:
- Беру проєкт з резюме і прошу відновити контекст: чому обрали цю БД, чому саме такий пайплайн, що ламалося в проді.
- Задаю питання на компроміси: що б ти спростив, якби потрібно було здешевити інфраструктуру на 30%.
- Даю коротке відлагодження: лог інциденту, шматок коду, схему черги — і дивлюся, як людина мислить вголос і де ставить датчики.
Парадоксально, але в цій точці допомагає і ШІ-автоматизація з боку роботодавця. У моїй практиці в Nahornyi AI Lab ми впроваджуємо не «ШІ, щоб замінити інтерв'юера», а автоматизацію навколо процесу: структуровані рубрики оцінки, авто-конспекти по запису, вилучення тез і протиріч, контроль покриття компетенцій. Це знижує шум і робить рішення консистентним між різними інтерв'юерами.
Однак є тонкість: якщо ви починаєте використовувати ШІ для скорингу кандидатів, ви зобов'язані тримати архітектуру прозорою. Хто і на підставі чого прийняв рішення? Які дані використовувалися? Де зберігаються записи? В архітектура ШІ-рішень для HR завжди впирається не в модель, а в контури доступу, аудит і юридичні підстави обробки даних.
Strategic Vision & Deep Dive
Я очікую, що «суфлери» стануть стандартом так само, як колись стали стандартом автодоповнення в IDE. І тоді питання звучатиме інакше: чи наймаємо ми людей, які вміють ефективно працювати з LLM, або людей, які можуть без нього? Моя відповідь — і тих, і інших, але під різні ролі і з різними інтерфейсами контролю.
У проєктах Nahornyi AI Lab я вже бачу патерн: компанії, які серйозно роблять впровадження ШІ в процеси (підтримка, продажі, аналітика, виробництво), починають вимагати від співробітників «вміння з інструментами». Але при цьому вони найчастіше провалюються на базовій речі — на здатності людини діагностувати проблему, формулювати гіпотези і перевіряти результат. Суфлер допомагає сформулювати текст, але не створює інженерного чуття.
Тому моя нетрівіальна порада: не боріться з підказками заборонами — боріться з ними дизайном задач. Я закладаю в інтерв'ю «повороти сюжету», де шаблон розвалюється:
- Змінюю обмеження в середині: «а тепер уяви, що GDPR/PII, логувати не можна». Сильний кандидат перебудовує рішення, слабкий залипає.
- Прошу назвати 2 альтернативи і критерій вибору. LLM видасть список, але без внутрішнього пріоритету і без прив'язки до бюджету/ризику.
- Питаю про «найбільший технічний челендж» і добиваю деталями: метрики, таймлайн, що відкотили, що вимірювали після фіксу.
Пастка, яку я часто бачу: компанія ускладнює прокторинг, робить інтерв'ю неприємним, і в підсумку втрачає сильних кандидатів швидше, ніж ловить чітерів. Утиліта тут важливіша за хайп: м'який контроль + розумний сценарій інтерв'ю дають найкраще співвідношення точності і конверсії.
Далі буде тільки жорсткіше: віддалені процеси стануть нормою, а інструменти підказок — непомітнішими. Переможуть ті, хто перетворить найм на інженерну систему: вимірювану, повторювану, зі зворотним зв'язком від перформансу найнятих людей.
Якщо ви хочете перебудувати найм під епоху LLM — від структури інтерв'ю до контурів даних і автоматизації оцінки — я запрошую вас обговорити задачу з Nahornyi AI Lab. Напишіть мені, Vadym Nahornyi, і я запропоную практичну схему, яка захищає якість найму, не перетворюючи процес на допит.