Співбесіда з pair programming: чого очікувати і як підготуватися

Якщо ви готувалися переважно алгоритмічними головоломками, раунд pair programming може здатися незвичним. У цьому розділі пояснюється, чим він відрізняється і чому це змінює вашу підготовку. Коротка відповідь: вас оцінюють як майбутнього члена команди, а не як розв'язувача головоломок.

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

• Уточнювальні запитання. Чи підтверджуєте ви вимогу і те, що означає 'готово', перш ніж писати код.
• Мислення вголос. Чи може ваш партнер стежити за вашим планом, не перепитуючи.
• Поступовий прогрес. Невеликі робочі кроки замість однієї великої зміни наприкінці.
• Тестування. Чи пишете або запускаєте ви тест, щоб довести, що зміна працює.
• Читання коду. Наскільки швидко ви орієнтуєтесь у коді, який написали не ви.
• Сприйняття підказок. Як ви реагуєте на підказку або іншу ідею від свого партнера.

Інші формати кодування, включно з whiteboard, take-home та живими алгоритмічними раундами, порівнюються в interview types hub.

Backend-інженера, який проходив співбесіду на позицію mid-level у логістичному стартапі, попросили додати правило знижки до наявного модуля checkout. Перш ніж почати писати код, він запитав, чи можуть знижки підсумовуватися і що має статися із замовленнями, які вже обробляються. Він прочитав наявні тести, написав один тест, що не проходить, для нового правила, зробив так, щоб він проходив, найпростішою можливою зміною, а потім запитав свого партнера, чи має правило належати класу pricing, чи окремому об'єкту policy. Коли інтерв'юер запропонував інший підхід, він спробував його і пояснив компроміс. Він не завершив додаткову вимогу, але зворотний зв'язок все одно зосереджувався на тому, наскільки легко з ним було працювати.

Саме такий потік — уточнення, тестування спочатку, невеликі зміни та обговорення дизайну — і покликана спостерігати більшість раундів pair programming.

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

Будьте реалістами щодо живих інструментів у цьому контексті. Pair programming значною мірою залежить від демонстрації екрана, і все, що ви показуєте, видно вашому партнеру; ваш інтерв'юер також спостерігає, як ви пишете код у реальному часі. SubcueAI транскрибує інтерв'юера і готує чернетки тез для відповіді під час розмовних частин відеоспівбесіди, з настільного застосунку або розширення браузера, без жодного бота у дзвінку. Саме кодування залишається на вас, а середовища з проктерингом і пристрої, керовані компанією, виходять за межі цього. Деталі налаштування — на сторінці tutorial.