Back to "Безкоштовне опитування розробників програмного забезпечення"

This is a viewer only at the moment see the article on how this works.

To update the preview hit Ctrl-Alt-R (or ⌘-Alt-R on Mac) or Enter to refresh. The Save icon lets you save the markdown file to disk

This is a preview from the server running through my markdig pipeline

Interviewing

Безкоштовне опитування розробників програмного забезпечення

Friday, 13 September 2024

Вступ

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

  1. The "Як би ви перемістили гору Фудзіяма? за допомогою логічних головоломок та дразників мозку.
  2. "Давайте подивимося, як багато ви пам'ятаєте з вашого комп'ютерного наукового ступеня" підхід з алгоритмічними питаннями.
  3. " Спостерігати за вами, коли ви пишете підхід до коду " з вправами з кодування.

Протягом років я опитував десятки разів і найняв сотні розробників різних компаній від Microsoft до Dell до крихітних стартапів. Дивно, але я також був дослідницьким психологом, що спеціалізується на психометриці (науці вимірювати розумові здібності) та Розробникі програмного забезпечення. Я бачив процес зі всіх сторін.

Проблема

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

Наша професія також поширена на синдромі обману. Я бачив це в собі і в багатьох інших. Це справжнє. Так как ты собираешься взять интервью с кем-то, кто уже чувствует себя мошенником?

Наша професія кишить соціальною незграбністю (і так само, як я трохи аутизм), інтерв'ю, яке є стресовим і потребує соціальної взаємодії, в той час як розв'язання проблем з програмуванням є рецептом катастрофи. Так как ты собираешься взять интервью с кем-то, кому социально неловко?

Розв'язання

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

По - друге, проведення інтерв'ю (або інтерв'ю) повинно бути якомога вільнішим для учасників. Це означає:

  1. Зверніть увагу на все, що в нас є. Не начинай интервью с кем-то, кто замечает 24 часа (або хуже того же дня).
  2. Щоб зрозуміти, яким буде формат інтерв'ю, хто буде там очікуваний результат (це кінцевий, технічний екран і т.д.)
  3. ПРОЧИТАЙ ЛЮДСТВО ОСОБИСТІ. Я не могу на этом напрягаться. Якщо ви маєте інтерв'ю з кимось, ви повинні знати їх резюме навиворіт. Це не тільки шанобливе ставлення, але й дає можливість ставити запитання про їхній досвід.
  4. Переконайтеся, що ви маєте подробиці у MAIL; якщо це Команди / Масштаб переконатися, що у них є посилання. Если это личное дело, убедиться, что они знают куда идти.

Інтерв'ю

БУДЬТЕ ЧАСОМ; ніщо не робить людину більш стурбованою ніж чекати на інтерв'ю. Якщо спізнишся, ти вже починаєш не на ту ногу. Якщо вони запізнюються, дайте їм кілька хвилин, вони, ймовірно, не були на зворотному зібранні, так що їх налаштування може бути оманливим.

Чи вони підходять команді з огляду на її темперамент? Це важливо; ви можете мати найкращого програміста в світі, але якщо вони є придурком, то вони цього не варті.

Одна порада, яку я придумала (після років питань послідовності Fibonacci, зміни масивів, пов'язаних зі списками тощо) - це:

ДРУЗІ ЛЮДЕЙ, ЯК ГОЛОСУЮТЬ ПРО ПОДІБНІ ВОНИ

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

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

Щоб було зрозуміло, що ти не просиш про великий проект чи якийсь дивовижний інноваційний код. Це просто код, про який вони можуть говорити. БАГАТО людей мають такі "родини," ймовірно, що вони не були 365-денним учасником головного проекту Open Source.

Ви не берете на роботу на основі того, скільки вільного часу хтось має.

ЧОМУ?

Так почему я предпочитаю этот подход? Чому я думаю, що це кращий спосіб інтерв'ювати розробників?

  1. Це не так напружено. В інтерв'ю людина говорить про щось, що вони знають. Вони не намагаються розв'язати проблему, яку вони ніколи раніше не бачили; насправді, більшість часу, коли програмують, ви хвилюєтеся за те, як вони пишуть код, коли їм надано час, щоб написати його. Більшість з нас не грає божевільних алгоритмів, щоб робити речі, які наша система вибору вже робить для нас.
  2. Ви можете оцінити, чи вони брешуть про свій досвід. Якщо вони не можуть говорити про якийсь фрагмент коду, який вони написали, то, ймовірно, не написали його.
  3. Ви можете копати код більш природним чином; чому вони вибрали такий підхід проти іншого, чому вони не використовували бібліотеку і т.д.
  4. Ви бачите код, який вони хочуть вам показати. Це щось велике. Якщо ви попросите їх написати код на місці, то побачите, що вони пишуть під тиском. Якщо ви просите їх поговорити про код, вони написали, що ви бачите код, який вони написали, коли вони не під тиском. Знову ж таки, якщо ваша робота - це справа кошика більшість часу, коли ви не пишете код під тиском.

Винятки до правила

Отже, існують винятки, супермладші програмісти іноді потребують невеличкої вправності в кодуванні, але повільно. Попросить их определить и починить или починить какой-то огромную базу кодов, это жестоко. Для них ви можете запитати про базові концепції, зокрема цикли, умовні умови тощо (зберігаючи фокус на роботі, яку ви наймаєте). Візерунки? Ну, я бачив багато людей, які не можуть назвати шаблона, але можуть сказати, коли вони його використовують. Так что не вешай на это слишком много времени.

Логічні головоломки? Я ніколи не бачив у цьому сенсу. Я ніколи не бачив роботи, де тобі потрібно переїжджати на гору Фудзіяма. Я ніколи не бачив роботи, де вам потрібно знати, скільки вміщається м'яч для гольфу в "747." Я ніколи не бачив роботи, де вам потрібно знати, скільки піаніно у Нью-Йорку.

Перейти вгору

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

logo

©2024 Scott Galloway