Чи справді live coding показує рівень розробника?

Дивитись детальніше

Уявіть: ви провели з кандидатом три співбесіди, він блискуче говорив про архітектуру й мав переконливе резюме, проте під час роботи над проєктом виявилося, що він не може розв’язати навіть елементарне завдання. Страх цієї помилки й робить live coding таким привабливим — тут людина пише код просто перед вами, майже без шансу підмінити себе кимось іншим.

Але що ближче до практики, то більше проблем: live coding часто не розкриває цілого пласта навичок, на яких тримається практична робота, та ще й спричиняє стрес навіть у сильних інженерів. Так формат, що мав знизити ризик помилки, сам стає її джерелом.

Далі ми розберемо, що таке лайвкодинг насправді, у чому його ризики і як організувати таку співбесіду з мінімальним хвилюванням для всіх сторін.

Що таке live coding і навіщо компанії його використовують

Live coding співбесіда — це формат, за якого кандидат розв’язує задачу з кодом безпосередньо під час розмови з інтерв’юером, а не самостійно вдома. Він шерить екран, пише рішення в реальному часі, поки представники роботодавця стежать за ходом його міркувань. Після цього всі разом обговорюють результат. Лайвкодинг може бути як окремим етапом, так і частиною технічного інтерв’ю, яка об’єднується з Q&A.

За пів години лайвкодингу помітно те, чого немає в резюме:

• Як кандидат розбиває задачу на частини — чи одразу береться писати код, чи спочатку ставить уточнювальні запитання й проговорює план роботи.
• Що він робить, коли застрягає — як шукає помилку, чи здатний повернутися до попереднього кроку й спробувати інший підхід, чи приймає підказки.
• Чи може пояснювати свої рішення вголос — чи зрозуміє колега хід думок, коли вони працюватимуть разом.
• Як кандидат реагує на зміну вимог, якщо інтерв’юер на ходу додає нову умову — чи швидко адаптується, чи губиться.

Проте live coding — це не уніфікований формат. Те, як він проходить, залежить від політики конкретної компанії, а підходи можуть суттєво відрізнятися.

Найпростіше систематизувати відмінності за двома осями:

• Що дозволено кандидату. Спектр від суворого «тільки порожній редактор» до повної свободи. На одному полюсі — заборонено все: ані гугла, ані документації. Посередині — можна гуглити й зазирати в документацію, як у звичній роботі. На іншому полюсі дозволено майже все, зокрема ШІ-асистента, адже тут оцінюють уже те, як кандидат користується інструментами.
• Наскільки втручається інтерв’юер. Це може бути колаборація — інтерв’юер поруч як напарник: підказує, спрямовує, разом із кандидатом шукає рішення. Проте може бути й мовчазний нагляд — інтерв’юер спостерігає, а кандидат самостійно долає усі труднощі.

Ці осі не пов’язані між собою, тож трапляються будь-які комбінації на практиці — від дружної парної сесії з Google під рукою до іспиту із порожнім редактором під пильним поглядом інтерв’юера.

Навіщо компаніям взагалі потрібен цей формат? Почнемо з раціональних причин:

• Перевірити реальний скіл. Ані резюме, ані портфоліо не показують практичних навичок безпосередньо: у резюме — лише перелік досвіду без доказу, що людина справді володіє зазначеними навичками, а за роботами в портфоліо часто не зрозуміти, яку частину проєкту зробив кандидат, а яку — команда. Тестове завдання в IT теж нерідко генерується або віддається на виконання досвідченішому спеціалісту. Проте «живий» код одразу показує, чи підтверджене реальними вміннями те, про що кандидат розповідав на співбесіді.
• Швидко оцінити навички. Замість тижня очікування на тестове й окремих годин на його перевірку — одна сесія, під час якої ви бачите результат і обговорюєте його одразу.
• Прокомунікувати наживо. Тут видно не лише код, а й людину: як вона ставить запитання, реагує на критику та пояснює свою логіку.

Микола Клєстов

CTO в ITExpert

«В останні роки компанії все частіше обирають лайвкодинг, а не тестові. Зараз ТЗ можна просто віддати ChatGPT чи іншим агентам, тож воно перестає показувати результат. Лайвкодинг цінний саме тим, що ти бачиш, як людина пише самостійно.

Зазвичай коли кандидат просить скасувати тестове/лайвкодинг, одразу вмикаються сумніви — чому не хоче, чому ставить умови? Під питання потрапляють уже й його soft skills. Аргумент “у мене великий репозиторій” спрацьовує, лише якщо там є проєкт, схожий на те, що робить компанія. Однак були кейси, коли hiring-менеджер сам міг сказати “людина крута, обійдемося без тестового, поспілкуємося про досвід”».

Вікторія Іванова

Venture Talent Acquisition Specialist

«Live coding почав набирати оберти ще роки три тому — передусім, щоб не витрачати час кандидата, прискорити hiring-процес і не ображати сеньйорів тестовими завданнями. Я особисто підтримую лайвкодинг, особливо в часи AI, бо, на мій погляд, це не лише про “напиши нам код, а ми оцінимо“, а часто спосіб перевірити взаємодію і як людина буде працювати з реальними завданнями. До оферу важливо дізнатись, як людина тримається під тиском і в стиснуті дедлайни, як спілкується, чи сприймає фідбек. Через AI-асистентів домашні тестові завдання втрачають актуальність, тому, з мого досвіду, лайвкодинг обирають усе частіше.

Велика перевага лайвкодингу — швидкість для обох сторін, бо кандидат одразу бачить, чи комфортно йому з hiring-менеджером, виконання не займає багато часу, а менеджер у процесі дає підказки й коментарі. Саме про такий формат я отримувала багато позитивних відгуків».

Проте так само за цим можуть стояти менш об’єктивні причини:

• «Так складніше обманути». Тестове можна списати, а на онлайн live coding людина сама перед камерою — формат здається надійнішим. Спойлер: уже не зовсім так через AI-асистентів та фейкових кандидатів, які використовують технології заміни обличчя.
• «Бо так роблять у Google». Частина практик впроваджується в компаніях просто за інерцією, адже у топів це працює. Але те, що підходить корпорації з тисячами відгуків на вакансію, не завжди має сенс для команди з п’яти людей.
• «Ми так звикли». Інколи формат живе просто тому, що так заведено. Його ніхто не переглядав роками, а навіщо він і що саме перевіряє — пояснити вже ніхто не може.

Головні ризики лайвкодингу

Попри зручність формату, погано організований лайвкодинг створює ризики, де одна частина псує якість самої оцінки, а інша — шкодить враженню кандидата про компанію.

Стрес замість демонстрації навичок

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

Алгоритмічні задачі не відповідають реальним

Розробники роками скаржаться, що задачі на лайвкодингу з LeetCode далекі від практичної роботи. Одна з головних причин — умова в завданні чітка й вичерпна. У справжній тасці половина справи — зрозуміти, що взагалі треба зробити з розмитого формулювання у тікеті.

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

Втрата сильних кандидатів через тривалий відбір

Тривалий процес рекрутингу із лайвкодингом не відлякує, якщо компанія змогла замотивувати кандидата: упізнаваний бренд, прозорі етапи, якісна комунікація, конкурентна пропозиція. Проте вирішальним може стати порівняння з іншими роботодавцями: якщо дві компанії зі схожою репутацією процесять одного кандидата, одна дає офер за тиждень, а друга за три — найчастіше виграє швидша.

Тому ще до того, як найняти Senior-фахівця, варто чесно оцінити свої шанси: коли до довгого процесу додається слабкий бренд, то пошук спеціаліста може затягнутись.

Приховане використання AI

Асистенти на кшталт Cluely та Interview Coder працюють як невидимий шар поверх екрана й не потрапляють у демонстрацію, тому стандартний live coding їх не виявить. Дослідження показують, що 48% кандидатів на технічних ролях несанкціоновано використовують AI.

Також лайвкодинг майже не показує ряд компетенцій, необхідних для роботи в комерційній розробці:

• Доменні знання. Та сама задача має різні «правильні» рішення залежно від сфери: наприклад, у кібербезпеці перевірку пароля треба захистити від атаки за часом відповіді, а в ритейлі — вирішити, як рахувати залишок під флешрозпродаж, де є лише бізнес-компроміс. Формат перевіряє, чи вміє кандидат писати код, тоді як справжня цінність полягає в тому, чи розуміє розробник, що саме й навіщо потрібно реалізувати для цього бізнесу.
• Читання чужого коду й дебаг легасі. Формат не показує, наскільки добре людина розбереться в чужому коді п’ятирічної давності без тестів.
• Довготривалу командну взаємодію. Під час лайвкодингу ви не зможете оцінити скіли код-рев’ю, менторства, командної роботи та співпраці з декількома стейкхолдерами.

Чек-лист: коли live coding доречний

Ситуації, коли лайвкодинг — це метч з вашими потребами або необхідний разом технічним інтерв’ю:

• Кандидат не має релевантних проєктів у портфоліо. Спеціаліст виріс з Senior на попередній позиції, але працював в іншому домені — наприклад, переходить з Retail в FinTech. 
• Потрібна швидка адаптація до незнайомого коду або стека. Якщо роль передбачає роботу з декількома проєктами, де постійно доведеться занурюватись у чужу документацію, кодову базу й легасі, лайвкодинг може показати ці навички краще за тестове завдання, яке кандидат виконує протягом кількох днів.
• Ролі, де наявний кодинг під тиском у реальному часі — наприклад, SRE/DevOps, інженери на нічному чергуванні.
• Коли це зручно самому кандидату. Обсяг тестового завдання навіть за умови дотримання «хорошого тону» може сягати 3-4 годин, які є не у всіх. Live coding економить вечори неоплаченої роботи над великим тестовим і передбачає швидкий фідбек замість тижня очікування.

Коли ж від лайвкодингу краще відмовитись?

• Дефіцитні кандидати, яких відлякує цей формат. Якщо людина має кілька оферів, зайвий етап просто підштовхне її вийти з процесу.
• Сильний репозиторій чи open-source. Коли можна подивитися готові проєкти, штучна задача під наглядом нічого не додає. У відкритому комерційному коді чи опенсорсі видно архітектурні рішення, стиль і культуру код-рев’ю. Головне — переконатися, що код справді належить кандидату: пройтися по історії комітів і поставити кілька запитань про ухвалені рішення.
• Роль про архітектуру і/чи легасі. Лайвкодинг майже не вимірює ці компетенції, тому тут може дати false positive результат: кандидат відмінно впорається з алгоритмічними задачами, але губитиметься в роботі.
• Слабкий бренд роботодавця. Від Big Tech природно очікують лайвкодингу, тому кандидати будь-якого грейду готові пройти кілька додаткових етапів. Стартапу той самий формат коштує дорожче: розробник із кількома оферами радше відмовиться, ніж витрачатиме годину на стрес-тест заради маловідомої компанії.

Які методи оцінки кандидатів можна обрати замість лайвкодингу?

• Оцінка портфоліо чи опенсорсу. Код має бути доступним для перегляду, а його авторство — підтвердженим. Коротка розмова швидко показує, чи справді кандидат написав цей код самостійно.
• Розбір кейсу або системний дизайн. Розмова на кшталт «розкажіть, як би ви спроєктували архітектуру під такий продукт» дає змогу оцінити зрілість суджень і бізнес-мислення — те, чого live coding не показує.
• Парне програмування. Той самий код у реальному часі, але інтерв’юер — напарник, а не суддя, що ближче до реальної співпраці й менш стресово. 
• Тестове завдання. Реалістичне, з адекватним лімітом часу й оплачене, якщо займає понад чотири години.
• «Зворотне» завдання. Запропонуйте кандидатові проаналізувати ваш код, провести його рев’ю або знайти й виправити помилки. Такий формат оцінює саме ті навички, яких звичайний лайвкодинг майже не охоплює, і краще відтворює повсякденні робочі завдання.

Як провести лайвкодинг комфортно для всіх сторін?

Якщо ви обрали формат лайвкодингу, перевірте, наскільки він наближений до чесної перевірки, а не зайвого стресу.

Давайте реальну задачу, а не карколомну головоломку

Завдання має бути схоже на те, чим людина займатиметься на роботі, а не на головоломку з підступом, де треба пригадати один конкретний трюк. Реалістична задача показує реальні навички, а трюкова — лише те, чи розв’язував кандидат щось подібне раніше.

Не намагайтеся «підловити» кандидата

Лайвкодинг — це спроба побачити, як кандидат працює, тож і ставитися до нього варто як до майбутнього колеги, а не екзаменованого. Каверзні запитання «на засипку», мовчазне очікування, поки людина сама потрапить у пастку, демонстративне виправляння кожної дрібниці — усе це додає стресу й нічого не каже про hard skills. Колаборативний формат, де інтерв’юер спрямовує й підказує, забезпечує об’єктивніший результат, ніж пасивне спостереження.

Дайте доступ до інструментів — і визначтеся щодо AI

Документація, пошукова система, звична IDE — це не «підказки», а нормальні умови роботи. Забороняти їх означає тестувати штучну ситуацію. Заздалегідь визначте політику щодо AI та проговоріть її з кандидатом — невизначеність тут шкодить обом сторонам. Наприклад, ви можете дозволити AI для рутинної задачі — зокрема, згенерувати форму, щоб швидше перейти до складної частини, — але заборонити LLM для написання коду від початку й до кінця.

Окресліть правила

Формат, мова, приблизний тип задачі й що саме ви оцінюєте варто повідомити до співбесіди. Це вирівняє умови для всіх, адже ви перевіряєте навичку, а не вміння імпровізувати.

Так само стандартизуйте оцінювання заздалегідь: чіткі критерії та ознаки якісного результату. Інакше фідбек перетворюється на «сподобався / не сподобався».

Оцінюйте процес, а не лише фінальну відповідь

Часто хід міркувань важливіший за те, чи дійшов кандидат до фінальної версії коду за відведений час. Давайте бали за роздуми, декомпозицію й підхід до дебагу — саме це допомагає спрогнозувати, як фахівець буде діяти на проєкті.

Знайдіть баланс між глибиною й кількістю етапів

З одного боку, не намагайтеся за одну сесію оцінити і практичні навички, і знання архітектури, і комунікацію, і стресостійкість. Розділіть критерії на різні етапи рекрутингу, а тут зосередьтеся на чомусь одному. З іншого — так само не розтягуйте процес наймання штучно.

Тож live coding — це перевірка хард скілів чи стресостійкості? Чесна відповідь: і те, і інше, залежно від того, кого і як ви ним оцінюєте. Тому головне запитання — не «використовувати чи ні», а «що саме ви хочете виміряти й чи цей формат допоможе». Лайвкодинг працює лише за певних умов: під конкретні ролі й задачі, а не як універсальний фільтр. Тож не варто триматися за метод, який не працює для вашого кейсу — краще адаптувати для конкретної ролі чи команди або замінити іншим.