Поради на співбесіді з програмування

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

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

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

Спершу дійдіть до правильної відповіді, а потім — до розумної. Просте рішення методом brute-force, яке працює, цінніше за елегантну ідею, що ніколи не компілюється, а оптимізувати можна вже тоді, коли щось запрацювало. Пишіть невеликими, тестованими частинами, використовуйте зрозумілі назви змінних, а якщо застрягли — кажіть, що ви розглядаєте, замість того щоб замовкати. Інтерв'юери часто дають підказки, але лише коли чують, на якому етапі ви перебуваєте.

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

Розгляньмо frontend-інженера, який проходить співбесіду на посаду середнього рівня, пише робоче рішення методом двох вказівників, а потім, без запиту, проходить через нього порожнім масивом і масивом з одним елементом та називає час виконання як O(n). Ця остання хвилина самоперевірки й аналізу складності часто відрізняє наймання від «можливо», адже вона сигналізує, що інженер помітить власні баги на роботі. Називайте часову та просторову складність вголос, навіть якщо про це не просять.

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

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