Як на співбесіді відрізнити крутого фахівця від офігенно буллшітера або непотрібного пожирателя смузі? Методик інтерв'ю багато: домашні завдання, програмування в блокноті, тестові завдання, Розкажи про себе розваж мене за 2 хвилини так, щоб я взяв тебе на роботу, але майже у всіх компаніях, куди я ходила проводити співбесіду, в тому чи іншому вигляді задавали завдання, взяті з Quizful. Про них ми сьогодні і поговоримо!
- Який патерн ви бачите в цьому коді?
- Я бачу тільки кров! Кров!
- Ок, спробуємо наступне питання
Навіщо ми взагалі наймаємо людей? Наприклад, у нас bodyshop і будь-який кандидат, який уміє відрізнити масив від Логгер, буде приносити компанії + $ 500 в день. Або ми - серйозна компанія і треба, щоб він пройшов фейс-контроль (софт пишуть люди в костюмах). А можливо, ми шукаємо тих. Ліда, який вміє показувати фокуси з кодом.
Але припустимо, ми шукаємо Java розробника, який буде писати справжній софт (ну прям справжній-справжній, який працює і комусь потрібен). Ми хочемо зрозуміти, чи зможе він вирішувати реальні повседневневние проблеми, а так же уникнути ситуації, коли викликаний сантехнік відразу відповів, яке по ГОСТу тиск в трубі 3/4 ", а після цього дістав свої іржаві пасатіжі і відкрутив кран, забувши перекрити воду.
Деякі проблеми вирішаться самі специфікою мови - сильної типизацией, автоматизацією всього, що тільки можна і тестуванням. Від кожного за здібностями: комп'ютер робить те, що у нього виходить краще, ніж у людини, а людина - все інше (смузі, кава, rock'n'roll).
Однак, часто співбесіди проходять в стилі "Каспаров vs Deep blue". Розглянемо кілька прикладів цієї нерівної боротьби.
Дано. 120 питань з тіста Quizful "Java основи".
Мета. визначити хто вирішував би ці питання в реальному житті.
Можливі варіанти відповідей:
- Компілятор і / або IDE - коли IDE поганого не порадить, а компілятор дозволяє вичавити максимум з суворої типізації та знайти всі помилки ще до того, як ви встигли включити мозок
- Рефакторинг - коли код простіше переписати, ніж розібратися як він працює
- Юніт-тест - коли код вже переписали, але все ще нічого не зрозуміло, а покладатися на метод пильного погляду страшнувато
- Людина - якщо нічого не допомогло або, навпаки, сніпетів такі прості, що навіть людина може відразу побачити правильну відповідь
Прим .. Для кожного питання можливо кілька варіантів класифікації.
Пограємо в компілятор
U for Refactoring
Що бачу я. Летіли два верблюди - один рудий, інший ліворуч. Скільки важить кілограм асфальту, якщо їжакові 24 роки?
У наш час шізофазія можна зустріти в:
- психіатричній лікарні
- функціональних вимогах
- питаннях на співбесіді
- legacy коді
В останньому випадку допомагають рефакторинг і тести.
Припустимо, приклад зверху не тільки пекельно виглядає але і не працює належним чином. Наприклад, він повинен був друкувати "578". Зізнайтеся чесно, ви віддасте перевагу щоб ваш колега пофиксил його так:
Як проводилась класифікація:
Беремо питання і дивимося, як би ми вирішували проблему в реальному житті: писали б тест, переписували б код, покладалися на підказки IDE або просто відразу бачили б проблему самі.
За результатами питання класифікувався як:
- Для відповіді потрібна людина - якщо інші варіанти не спрацюють. В основному це виявилися питання типу "які є модифікатори доступу". Так, можна написати тест, але в житті передбачається що відповідь повинна даватися відразу.
- Для відповіді людина не особливо потрібен - коли можна написати тест або отрефакторіть, але можна і очима проблему побачити (наприклад, нескладні сніпетів типу
або екзотична теорія типу перевантаженого методу sum (Number) і sum (Integer)). - Для відповіді не потрібен чоловік-коли код вже досить заморочений, помилитися - раз плюнути, і в житті, коли на кону продакшн, ми б чесно витратили час як мінімум на дебаг.
Популярність тестів легко пояснити простотою перевірки результату, але якщо нас цікавить дещо інший "результат", то я б запропонувала знайти краще застосування сніпетів.
Наприклад, можна попросити кандидата написати тести на заданий шматок коду і подивитися які граничні випадки він буде перевіряти. Або дати отрефакторіть клас або метод. Інакше завтра ваш кандидат вийде на роботу і скаже "А чого тут рефактору? Нормальний код. Я завжди так пишу ".