Давайте поговоримо про інтерв’ю на дошці та можливі альтернативи

Ні для кого не новина, що багато інженерів ненавидять питання інтерв’ю на основі дошки.

Незалежно від того, чи є це у Twitter, Medium або LinkedIn, легко знайти когось, хто випускає повітря. Фраза «процес найму порушений» використовується так часто, що це стає кліше.

На жаль, велика частина цього розчарування падає на глухі вуха.

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

Чи є кращі альтернативи?

Це питання останнім часом у мене на думці. Чотири тижні тому я влаштувався на свою першу штатну інженерну програму. Поки я ще не беру участь у процесі найму, врешті-решт буду брати участь.

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

Ця скрутна ситуація призвела мене до двох питань:

  1. Чи найкращий вибір інтерв’ю на дошці?
  2. Якщо ні, то які найкращі альтернативи?

У цьому дописі я спробую відповісти на ці запитання. Майте на увазі, це мої особисті думки, сформовані моїм власним досвідом співбесіди.

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

Чи найгірші інтерв’ю на дошці?

Першим кроком у цьому процесі є вивчення дошки.

Плюси:

  1. Швидкі та низькі зусилля
  2. Не залежить від мови та домену
  3. Ви знаєте (загалом), чого чекати
  4. Підтримка спільноти (Glassdoor, LeetCode, Pramp тощо)

Мінуси:

  1. Удача - це великий фактор (алгоритм лотереї)
  2. Не обов'язково перевіряти технічні здібності
  3. Сприяє молодим інженерам та останнім студентам

Для компаній, які вимагають від інженерів глибокого розуміння основ CS, алгоритмів низького рівня та не залежності від бібліотек, ідеальне інтерв’ю з дошки.

SpaceX, MacOS / Windows та React від Facebook були створені інженерами з такими знаннями. Очікується отримати співбесіду в дошці з однією з цих компаній.

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

  • Масиви / рядки
  • Бінарні дерева
  • Зв’язані списки
  • DFS / BFS
  • Зворотне відстеження
  • Динамічне програмування

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

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

Не кожен може довгий час вчитися, щоб засвоїти алгоритми.

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

Тож якщо є сумнів, що співбесіда з дошки є найкращим інструментом для роботи, що може бути краще?

Давайте розглянемо деякі альтернативи.

Проблеми з кодуванням за допомогою комп’ютера

Плюси:

  1. Отримайте користування комп’ютером та звичним середовищем розробника
  2. Це можна зробити віддалено за допомогою спільного доступу до екрану
  3. Усі інші переваги інтерв’ю на дошці

Мінуси:

  1. Більш суворо щодо синтаксису та можливості роботи.
  2. Середовище програмування та плагіни можуть зіграти важливу роль
  3. Такі ж недоліки інтерв’ю на дошці

Виклики кодування на ноутбуці - менш суворий двоюрідний брат інтерв’ю на дошці.

Кандидати мають перевагу від використання власних комп’ютерів. Їх можна зробити віддалено або в парному середовищі програмування.

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

Недоліком цього є те, що набагато більше наголошується на функціональності.

Під час полювання на роботу мене двічі запитували про проблему зміни монет. Один як виклик дошці, а інший - у редакторі.

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

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

Із викликами коду не так.

Деякі можуть стверджувати, що акцент на функціональності є кращим, оскільки нам платять за те, щоб писати робочий код. Це правда, але нам не платять за це за 30–45 хвилин спринту.

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

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

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

Візьміть домашні оцінки

Плюси:

  1. Може працювати над цим у вашій піжамі
  2. Зазвичай дається понад тиждень для роботи за завданням
  3. Використовуйте власний редактор та середовище розробника
  4. Може бути новим доповненням до портфоліо
  5. Зазвичай веселіше, ніж дошка

Мінуси:

  1. Рівень складності може різко коливатися
  2. Набагато більше зусиль і часу, ніж завдання кодування
  3. Може бути залежним від домену
  4. Може призвести до повзучості функцій через конкуренцію
  5. Не відображає повсякденну роботу

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

Однак у домашніх тестів є деякі основні недоліки.

По-перше, ними легко маніпулювати.

Багато компаній проводять свої тести на GitHub. Введіть "Challenge" або "Test" у пошуку GitHub, і ви знайдете багато. Це дасть кмітливому кандидатові достатньо часу для попереджувального дослідження проблеми.

Це насправді не скарга. Просто більше про підказку.

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

Ви навіть можете перевірити це самостійно. Введіть “Challenge” у пошуку GitHub і подивіться, що ви знайдете.

Я живу поруч із штаб-квартирою Etsy у Брукліні і мені було цікаво, чи зможу я знайти відповіді на деякі їх тести. “Etsy Challenge” розкрив чотири. У “Тесті Etsy” було ще більше.

Це правда, що компанії можуть змінити свої оцінки. Однак змінити процес співбесіди кожні кілька місяців може бути клопотом через витік деталей.

По-друге, рівень складності та час, необхідний для вирішення цих завдань, дуже різниться.

Під час мого останнього полювання на роботу мені дали чотири завдання взяти додому. Три компанії сказали, що їм потрібно лише 3-5 годин, щоб закінчити.

Усі вони зайняли у мене кілька днів.

Основна причина цього полягала в тому, що проблеми часто були специфічними для конкретної галузі. Вони вимагали кількох годин вивчення документів API та нових технологій.

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

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

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

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

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

На основі проекту / укладання договору найму

Плюси:

  1. Отримайте можливість співпрацювати з кандидатом / командою
  2. Заробляйте за роботу
  3. Приступайте до роботи над реальними проектами
  4. Оцінюються наскільки добре ви працюєте з командою та судновим кодом

Мінуси:

  1. Тривале зобов'язання
  2. Робота без гарантії працевлаштування
  3. Ніякої користі для здоров’я як підрядник
  4. Може поставити кандидата в погану переговорну позицію
  5. Мовна залежність

Інтерв’ю за проектом зустрічаються рідко. Але чимало компаній підтримують їх, такі як Basecamp та Automatic. Я можу зрозуміти чому.

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

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

Безпрограшний. Або так здається.

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

Перші пару місяців будь-якої роботи, як правило, найскладніші. Ви адаптуєтесь до нової команди, культури, кодової бази. А тепер уявіть, що працюєте над проектом, не знаючи, чи матимете роботу до кінця.

Мій хороший друг нещодавно взяв інтерв’ю в Automatic і підтвердив, наскільки це може бути стресовим. Судять про все, від того, як ви взаємодієте з колегами до питань, які ви задаєте. У цих умовах, там є такі поняття , як «дурне питання.»

Гірше те, що його відпустили після тримісячного контракту. На щастя, він не дозволив це вплинути на його самооцінку. Він знає свої здібності і заряджається вперед. Я не впевнений, чи міг би я чи багато інших інженерів зробити це так легко.

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

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

Їх би стимулювали зайняти цю позицію, навіть якщо це не їхній кращий вибір. Альтернатива - приєднатися до ринку праці знову на площі.

Помилка коштувала помилки в найкращому вигляді.

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

То що найкраще?

Як ви вже здогадалися: Це залежить ™.

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

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

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

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

Будь ласка, дайте мені знати, який ваш метод співбесіди вам більше подобається в коментарях нижче!

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

Не будь такою людиною.

Припиніть скаржитися.

Знайдіть рішення.