Як ви опитуєте когось із більшим досвідом, ніж ви? [зачинено]

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

Хто-небудь може порекомендувати питання технічного інтерв'ю, щоб задати, що є хорошим засобом для оцінки навичок програмування вищого рівня, але все ж таки я можу зрозуміти?

Я б сказав, що я минув молодший. рівень програміста, але ніде не є старшим. Більшість з того, що я робив, - це побудовані невеликі додатки (веб і настільні ПК), деякі з них досить складні, але всі вони були призначені не для того, щоб використовуватись лише декілька користувачів. Я відчуваю, що я гідно розумію більшість концепцій програмування і здатний навчитися / навчити себе практично чомусь, однак мені не вистачає досвіду. Оскільки мій начальник любить говорити мені: "Ти не знаєш, чого не знаєш".

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

ОНОВЛЕННЯ:

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

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

Ви не можете.

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

Це дуже цікавий метод з наступних двох причин:

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

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

Використовуйте свій вік як перевагу.

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

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

Я взяв інтерв'ю у когось із досвіду весни java. Я використовував Spring на своїй попередній роботі, і однією з головних особливостей весни є введення залежності. Я сказав кандидату, з яким я брав інтерв'ю, що чув про Весну і ніколи не використовував її. Він почав лунати і продовжувати, але не зміг сказати мені, де він використав Spring AOP і не міг пояснити мені ін'єкцію залежності, навіть після того, як я явно попросив, побачивши, що ці речі викликали його резюме. Він щойно сказав мені, що вони справді круті, і там можна багато чому навчитися, і т. Д. І т. Д. Це дійсно виявляється, що він не знав джека ... і я був єдиним, хто зрозумів, що з цього приводу я був молодший член команди розробників.

Тож використовуйте свій вік як перевагу! Увійдіть, будьте впевнені і задайте кілька питань щодо технології, яку ви добре знаєте.

Пам’ятайте, що лише тому, що у них більше досвіду, ніж у вас, вони можуть бути не кращим розробником, ніж ви. Фраза «Один рік досвіду повторюється n разів». приходить, тому що ви бачите, що це відбувається в промисловості. Таким чином, вашим першим завданням під час співбесіди має бути встановлення того, що вони дійсно мають відповідний досвід і можуть представити себе як хтось, хто знає, що вони роблять. Так само, тому, що хтось мав n років досвіду в галузі, це не означає, що він має багато досвіду в даній мові, бібліотеці чи рамках, тому вони все ще можуть час від часу приходити до вас, задаючи питання, поки вони чомусь навчитися.

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

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

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

Мені дуже подобається відповідь на використання вашого віку як переваги , і я б запропонував щось подібне:

Використовуйте нижчий рівень досвіду як перевагу

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

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

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

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

Мені довелося це робити кілька разів. Я навчився це робити поетапно.

1. Почніть з тих же запитань, які я даю до дипломів коледжу. Я зробив це, тому що посада, в якій я робив технічне співбесіду, була позицією програмування, де ми очікували, що розробник буде переданий у коді, і я хотів переконатися, що кандидати зможуть запрограмувати. За єдиним винятком жоден з кандидатів не міг - вони були гірші за будь-який із випускників коледжу. Усі вони занадто довго були на керівних посадах.
2. Для кандидата, який пройшов базовий тест на компетентність з кодування, у мене були деякі більш загальні питання "як би ти поводився зі сценарієм X". Наприклад, якщо ви робите веб-сервіси у своєму проекті, наприклад, придумайте цікаве запитання щодо веб-служб і запитайте кандидата, як він би це вирішив. Я б не рекомендував, щоб це було над тим, над чим зараз ви працюєте, головним чином через проблеми інтелектуальної власності та власних даних компанії. Не видавайте цього!
3. Проведіть час, розпитуючи кандидата про матеріали, що містяться в його резюме. Це важливо. Ви можете дізнатися про його найкращий та найгірший досвід роботи в команді, досвід керівника тощо. Спробуйте відчути стиль роботи людини, щоб побачити, чи вписується він у вашу команду.

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

Що стосується фактичного процесу співбесіди, ви принципово ставитесь до них так само, як і до будь-якої іншої людини, яку ви наймаєте. Має бути подібний процес найму:

1. Вибір за резюме або рекомендацією агентства.
2. Тест на придатність (комбінування таких речей, як FizzBuzz , strdup () / isAlpha (), OOD тощо)
3. Телефонне інтерв'ю (для швидкого усунення, якщо вони не добре спілкуються)
4. Інтерв'ю віч-на-віч
5. Письмова вправа на кодування
6. Знайомтесь із деякими членами команди.
7. Для досвідченої людини, що передбачає більш високий ризик та більші витрати, додаткові раунди співбесіди є прийнятними, але ви повинні чітко повідомляти їх там, де вони перебувають (тобто це 1 з 3 раундів інтерв'ю).

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

На всіх етапах процесу співбесіди досвідчена людина повинна продемонструвати чудове розуміння своїх рекламованих спеціальностей. Ви можете дослідити їх з великою глибиною на будь-яку тему, яку ви висвітлюєте під час обговорень. Поставте запитання до меж рівня досвіду / комфорту та подивіться, чи можуть вони тривати без побоювань. Якщо вам потрібно вийти з глибокого кінця з тим, з чим у вас немає великого досвіду, зробіть в Інтернеті кілька прикладних запитань (отримайте підбірку з них), прочитайте та зрозумійте відповіді перед інтерв'ю , а потім запитайте кандидат будь-яке з цих питань. Не чекайте, що вони знають усі відповіді, тому майте вибір питань.

Ви можете найняти двох типів досвідченого інженера:

1) Відповідний галузевий досвід

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

2) Немає відповідного галузевого досвіду

Тож цей кандидат, можливо, міняє галузь, але має хороший досвід роботи у фундаментальних технологіях / платформах / навичках. Заглиблюйтесь у ці питання, але не сподівайтесь, що вони зможуть знайти рішення для проблем, пов’язаних із доменом, хоча ви можете просто поговорити навколо них. Наприклад, якщо у вашій компанії є Facebook, а людина, з якою ви опитуєтесь, гаряча з PHP та C ++, було б нереально сподіватися, що вони знають усі підводні камені масивних фермерських серверів (якщо вони не заявляють про це у своєму резюме).

Річ, на яку я не бачив прямого вказівки, - це "Ви дуже добре знаєте технологію X, і це звучить дуже цікаво. Чи не могли б ви мені пояснити це за п’ять хвилин?"

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

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

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

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

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

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

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

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

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

Я серйозно рекомендую вам прочитати книгу "Розумний і отримує речі зроблені: Короткий посібник Джоела Спольського щодо пошуку найкращого технічного таланту" .

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

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