Чи можна з тестового завдання зробити нормальну співбесіду?

💡 Усі статті, обговорення, новини про Front-end — в одному місці. Приєднуйтесь до Front-end спільноти!

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

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

З цього бажання й народився цікавий формат співбесіди у вигляді code review. Я чудово розумію, що цей підхід мало хто почне використовувати вже завтра, адже для цього потрібно докласти трохи зусиль, на противагу співбесіді-допиту зі «100 питань».

Чим мені імпонує code review як формат співбесіди?
По-перше, ми обговорюємо конкретні речі, запропоновані кандидатом, замість абстрактних питань чи уявних прикладів. По суті, саме виконавець тестового завдання задає напрямок співбесіди, використовуючи той чи інший підхід. А наше завдання, як інтерв’юєрів, — перевірити, чи може кандидат обґрунтувати свої рішення, чи здатен навести переконливу аргументацію і чи, зрештою, саме він є автором коду.

По-друге, ми наочно бачимо рівень технічних знань і навичок: наскільки кандидат володіє мовою, які патерни використовує і наскільки доцільно це робить, як залучає готові технічні рішення.

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

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

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

Ну а поки мої досліди тривають, я запрошую вас переглянути новий випуск співбесід саме у форматі code review на моєму каналі. Одразу зазначу, що рівень співбесіди визначають мої очікування та очікування запрошеного експерта. Тобто учасники не завжди є того рівня, який є в заголовку, бо хочуть випробувати долю та свої сили. Чи виходить у них? А це ми зазвичай дізнаємося з розгорнутого фідбеку запрошеного «таємного експерта».

Цього разу завданням було створити погодний застосунок з використанням реального API. Кандидат обрав React, Zustand та MUI. Чому? Для чого? Як це вплинуло на розробку? Відповіді на ці та інші питання у новому відео:

А що ви думаєте про цей підхід? Чи може він знайти практичне застосування, чи залишиться цікавим, але радше розважальним форматом? Якби вам запропонували пройти таку співбесіду, погодилися б? Поділіться своєю думкою в коментарях (а особливо під відео)!