І що слід використовувати замість тестових завдань
Уявіть, що ви директор невеликої середньої школи, який хоче найняти нових вчителів. Оскільки у вас в штаті їх має бути не більше 20, ви повинні переконатися, що кожен вчитель, якого ви наймаєте, зможе викладати в будь-якому класі. Ускладнимо приклад. Нещодавно звільнилася одна з кращих вчителів з більш ніж 15-ти річним стажем, і яка була наставником для багатьох молодших співробітників. Ким ви зможете її замінити?
Після деяких роздумів, ви створюєте, як вам здається, творчий підхід до інтерв'ювання. Коли кандидат прийде на інтерв'ю, ви попросите його провести урок, взятий з навчальної програми середньої школи. Оскільки ви хочете переконатися в тому, що кандидат добре підготовлений, то ви не скажете йому який урок він повинен буде дати. Якщо він справляється з таким завданням, то ви робите висновок, що він з легкістю зможе провести будь-який урок, так як він добре себе проявив з випадково обраною темою.
Ви розміщуєте оголошення про найм і, через деякий час, кілька цікавих кандидатів подають заявки. Однак, протестувати свій новий підхід ви плануєте на вчителі, якого рекомендував один з ваших співробітників, який працював з нею в минулому, як класного фахівця. Ви не вірите в своє щастя, що вона взагалі погодилася, і думаєте, що вона буде ідеальним піддослідним кроликом у вашому експерименті. Ви зв'язуєтеся з нею, щоб призначити день співбесіди і розповідаєте її про свій новий підхід, щоб дати їй можливість підготуватися.
Нарешті, настає день інтерв'ю і ваш кандидат з'являється в школі. Ви помічаєте, що вона трохи нервує, що дивно, тому що вона досвідчений кандидат і її резюме бездоганно. Ви вирішуєте не думати про це і проводите її в один з ваших класів, щоб почати співбесіду. «Мені б хотілося, щоб ви дали мені урок з теорії чисел». У цей момент її обличчя помрачніло. Справа в тому, що вона не викладала у 8-му класі ось уже більш ніж 10 років. Але ви про це не були обізнані. Як професіонал, вона пішла до дошки і почала урок. Вона розповідає про чисел і про те, як визначити, чи ділиться число на 2, 5 і 10. Але видно, як їй важко. Ви просите її розповісти про GCF і LCM, але вона просить уточнити, що означають ці абревіатури. Ви розцінюєте це як поганий знак і пояснюєте, що мали на увазі «найбільший спільний ділник» і «найменше спільне кратне». У цей момент ви помічаєте, що її впевненість в собі похитнулася і відчуваєте роздратування в її голосі.
До кінця години, з горем навпіл, вона пройшлася по всіх основних моментах теорії чисел. Однак це не вселило у вас впевненість, що вона зможе провести цей урок перед групою неслухняних 8-ми класників. Вона успішно пройшла ще пару тестів, але ви ніяк не можете відбутися від почуття, що вона, можливо, не найкращий класний вчитель. Після ще кількох інтерв'ю, ви вирішуєте не зупиняти свій вибір на ній і наймаєте вчителя з набагато меншим досвідом, який пройшов «тест уроком».
. . .
Можливо, цей приклад вам здасться надуманим. Досить дивний спосіб відібрати претендента на посаду вчителя, чи не так? Однак він точно відображає метод інтерв'ювання інженерів ПЗ. Тим не менш, я тут не для того, щоб сперечатися, що тестові завдання з кодування абсолютно не працюють (хоча багато хто так вважає). Я переконаний, що таким завданням не місце в інтерв'ю на посаду рівня Senior.
Чому? Дуже просто! Сеньйор розробники дуже різні і типові завдання з кодування ставить їх у невигідне положення з ряду причин:
- Вони забирають купу часу на підготовку - оскільки тестовий кодинг спирається на всю область розробки програмного забезпечення, до нього неймовірно важко підготуватися вичерпно. Для сеньйор-девелопера ця проблема ще й посилюється. По-перше, за визначенням, час шкільного навчання вже далеко позаду, де вони можливо і стикалися з більш езотеричними аспектами розробки ПЗ (динамічне програмування, червоно-чорні дерева або, навіть, рекурсія). Щоб освіжити знання за таким величезним діапазоном алгоритмів і структур даних, може знадобитися значний час. До того ж, сеньйор інженери більш стислі за часом (у них більш жорсткі проектні рамки і значна особиста відповідальність) і це справжня проблема. Я знаю кілька випадків, коли сеньйор-інженери цікавилися проходженням інтерв'ю у замовника і, якщо він пропонував кодингове тестування, то відмовлялися його проходити.
- Вони змушують сеньйор-інженерів працювати в незвичному середовищі - сеньйор-інженери давно вже не користуються засобами розробки пропонованими на інтерв'ю. Зазвичай вони користуються тонко налаштованими середовищами розробки, які вдосконалювалися багато років і заточені на те, щоб позбавити від зайвої писанини низькорівневого коду. Якщо врахувати, що інтерв'ю накладає тимчасові обмеження на виконання тесту, то витяг зі звичного середовища розробки ставить сеньйор-інженера в невигідне становище. Більш того, останні кілька років вони могли працювати з власними бібліотеками (управління пам'яттю, контроль помилок, трейсинг) свого замовника. Кодингове інтерв'ю висмикає їх із зони комфорту в світ стандартів і примітивних редакторів.
- Насправді вони не перевіряють навички, які сеньйор-інженери будуть застосовувати - ймовірно найбільш дебільне те, що такі інтерв'ю перевіряють тільки малу частину того, заради чого ви наймаєте сеньйора. Він зазвичай заробляють в 3-5 разів більше, ніж джун. Очікувати при цьому, що сеньйор буде писати в 3-5 разів більше коду, як мінімум нерозумно. Їм просто не вистачить на це часу. Основне, для чого потрібен сеньйор, це щоб вести команди джунів, навчати їх, виявляти систематичні проблеми, налагоджувати складні процеси в розробці і, коли справа доходить до кодингу, розібратися в складній системі і заплутаній роботі, щоб кодити разом з ними. Жоден з цих аспектів не тестується кодинговими інтерв'ю і це головне, чому сеньйор-інженери ненавидять тестові завдання.
- Вони стають недобрим передзнаменуванням - як ви вже знаєте, сеньйор-інженера наймають не для того, щоб кодити, і вони це теж знають. Але коли ви робите акцент на кодингових тестах у процесі найму, ви змушуєте сеньйора сумніватися в тій ролі, для якої ви його наймаєте. «Вони просто хочуть, щоб я став код-макакою», «Чи не розтрачу я свій талант тут?», «Це крок вперед або крок назад?». Напевно ви не дуже хочете, щоб який-небудь талановитий інженер засумнівався в вакансії або у вашій компанії під час інтерв'ю. Попросіть їх покодувати на інтерв'ю - засумніваються.
Поміркувавши над усім сказаним не дивуєшся, чому це сеньйор-інженери ненавидять кодингові інтерв'ю. Якщо ви хочете дійсно залучити талановитих сеньйорів на цьому напруженому ринку праці, то перестаньте просити їх щось кодити.
Однак, ви можливо подумали, а як я дізнаюся чи зможе він взагалі кодити? Ну, якщо ви вже так хочете переконатися, що найманий сеньйор зможе кодити, можу запропонувати дати невелике завдання на будинок (щоб воно займало не більше одного-двох годин). Більшість сеньйорів цілком можуть знайти небагато часу, щоб виконати таке завдання, тим більше, що це усуває підготовчу роботу, необхідну для тестового кодингу і може бути розбите на короткі відрізки часу, які легше спланувати в напруженому графіку. Таке завдання додому також дозволяє працювати у звичному середовищі розробки і витратити будь-який доступний час, щоб вивчити або освіжити знання з якої-небудь стандартної бібліотеки.
Додаткова перевага це те, що претендент може присвятити стільки часу, скільки він захоче, щоб виконати ваше завдання і це дасть вам уявлення про його персональні особливості роботи. Чи уважні вони до коментарів? Наскільки ретельно продумують тести? Наскільки добре структурують свій код? Якою мірою дбають про якість роботи, яку відправляють? Іншими словами, ви будете знати не тільки те, що вони вміють кодити, а ще й наскільки добре вони вміють кодити в більш-менш реалістичній обстановці.
…
Сеньйор-інженери - це «жива кров» будь-якої софтової компанії. Вони найбажаніші, найдорожчі і важкі у відборі. І особливо в історично сформованому, тісному ринку праці, ваш процес найму повинен бути більш гнучким до їх специфічних потреб, оскільки ви потребуєте їх більше, ніж вони у вас.
Так, сеньйор-інженери ненавидять кодингові інтерв'ю і ви в процесі пошуку кращого способу відбору, теж повинні їх ненавидіти.