Правила прийому програмістів на роботу
Більшість статей, написаних на тему найму програмістів, звучить більш-менш однаково. Як правило, такі статті рекомендують «наймати тільки найкращих». Зізнаюся, я не в захваті від цієї ради, тому що він звучить занадто невизначено. Це все одно, що якби ви прийшли в автосалон і запитали б у продавця яку б він машину вам порекомендував, а він вам би відповів що «Кращу» при цьому не вказано ні на яку знаходиться в автосалоні.
Будь ласка, зрозумійте мене правильно, я зовсім не раджу навмисно вишукувати посередніх програмістів. Зрозуміло, всі хочуть наймати тільки самих талановитих і досвідчених програмістів. У рішеннях про наймання ставки високі. Ваше рішення вплине на роботу всієї команди та її окремих учасників. Як кажуть:
Але стандартний рада все одно мене дратує. Справа навіть не стільки в самій раді, скільки в тому, що люди схильні розуміти його невірно. Якщо застосовувати його без додаткових поправок, ця практика в основному формує почуття власної переваги. Цей ефект особливо часто поширений серед програмістів, оскільки елітарність так чи інакше властива нам. Коли ми чуємо, що наймати потрібно тільки «найкращих», ця рада проходить підсвідоме перетворення:
«Найкращих?» Але це ж я! Я найкращий". Зрозуміло, я повинен наймати людей, таких же обдарованих, таких розумних і симпатичних, як я сам. Та й навіщо засмічувати мою прекрасну команду всяким набродом?
Хто вони, найкращі програмісти?
Само собою, такий підхід створює не найкращі умови для прийняття рішень. Стандартне правило працює набагато краще, якщо розуміти його трохи інакше:
«Я хочу сформувати якомога більш ефективну команду. Наймаючи додаткового працівника, я прагну не тільки до чисельного розширення штату. Кожен найманий людина повинна покращувати мою команду в певному відношенні. Я зовсім не шукаю такого ж обдарованого людини, як я сам. Швидше, мені потрібна людина, обдарований більше мене принаймні в одному важливому напрямку ».
Найгірший начальник - той, який відчуває загрозу з боку своєї команди. Свідомо чи ні, він побоюється «найкращих», і тому постійно наймає людей, на тлі яких він буде виглядати виграшно.
Напевно, у великій компанії з таким підходом можна прожити. Я сильно підозрюю, що Кошлатий Начальник в коміксах про Ділберта був змальований з натури.
кадри програмістів
Справжній сенс стандартного правила полягає не в тому, щоб потішити наше самолюбство - воно повинно нагадувати, щоб ми не боялися шукати кращих працівників. І все ж необхідно більш точно з'ясувати, що насправді означає слово «кращий».
Шукайте людей, схильних до самоаналізу
«Найкращі» працівники ніколи не перестають вчитися.
Люди, серйозно налаштувалися на свій майбутній успіх, з великою ймовірністю домагаються успіху. Часто цей настрій є найсильнішим ознакою для прийняття рішень при наймі.
Це не означає, що наймати потрібно тільки тих людей, які бажають досягти успіху. Всі люди хочуть домогтися успіху. Я раджу наймати людей, серйозно ставляться до постійного навчання. Такі люди не витрачають час на спроби переконати вас в тому, як багато вони знають. Вони зосереджені не на минулому, а не майбутньому. Поки ви проводите з ними співбесіду, вони проводять співбесіду з вами, намагаючись дізнатися, чому вони зможуть у вас навчитися.
Як знайти таку людину?
По одному добре помітною ознакою: люди, налаштовані на постійне навчання, добре знають, чого вони не знають. Вони знають свої слабкості і не бояться говорити про них.
На співбесідах кандидату часто пропонується описати свою основну слабкість. Хоча це питання до жаху традиційний, він мені подобається.
На жаль, багато кандидатів намагаються ухилитися від відповіді. Вони йдуть в книжковий магазин і купують книгу про проходження співбесіди. Книга попереджає, що я задам їм це питання, і пропонує «творчі» способи ухилитися від щирої відповіді:
- Іноді я занадто багато працюю.
- Іноді мою увагу до деталей дратує інших учасників групи.
Коли я прошу кандидата розповісти про свої слабкості, я сподіваюся на розумний, щирий і впевнену відповідь. Коли я чую, що кандидат визнає свою слабкість, це справляє враження. Але якщо кандидат дає ухильну відповідь, взятий прямо з книги, я починаю думати про наступний кандидата.
У дрібній фірмі «найкращими» програмістами є ті, які не обмежуються власне програмуванням. Намагайтеся наймати розробників, а не програмістів. Хоча ці слова часто використовуються як синоніми, я їх розрізняю. Йдеться про відмінності між простим програмуванням і участю в групі роботи над продуктом. Наведу цитату зі статті, яку я написав на цю тему в своєму блозі:
«У цій статті« програмістом »називається той, хто займається виключно кодуванням нових функцій і [якщо пощастить] виправленням помилок. Програмісти не пишуть специфікації. Вони не створюють автоматизовані контрольні приклади. Вони не допомагають підтримувати автоматизовані системи збирання в актуальному стані. Вони не допомагають клієнтами вирішувати технічні проблеми. Вони не допомагають писати документацію, не беруть участі в тестуванні і навіть не читають код. Все, що вони роблять, - це написання нового коду. У дрібній фірмі таких людей тримати не варто.
Замість «програмістів» (людей, що спеціалізуються на написанні коду) вам необхідні «розробники» (люди, що вносять багатосторонній внесок в успіх продукту) ».
Що ж означає стандартне правило? Який саме атрибут потрібно виміряти, щоб визначити, чи є кандидат «найкращим»?
Зазвичай це правило розуміється стосовно тільки до навичок кодування. Але по-справжньому хороші програмісти відрізняються кмітливістю. Вони розуміють те, чого зазвичай не вчать, і можуть працювати раз в 10 ефективніше середнього програміста. Звичайно, було б розумно пошукати одну з таких «десятикратних» особистостей, особливо в великих організаціях, де фахівці на зразок «чистих» програмістів виявляються цілком доречними. Але в маленькій фірмі потрібна універсальність. Нерідко потрібно, щоб учасники команд виконували кілька функцій, не обмежуючись написанням коду. У таких випадках дуже важливо знайти кращого розробника, і ця людина зовсім не обов'язково виявиться кращим програмістом.
Конкретні правила і рекомендації
Отже, стандартне правило працює цілком нормально, але від загальних рекомендацій необхідно перейти до більш конкретних. Щоб підвести підсумок того, про що говорилося в попередніх розділах, я пропоную 10 питань, які слід задати собі при розгляді кандидата на посаду розробника:
- Чи здатний цей кандидат зробити для групи то, що не зможе ніхто інший?
- Знаходиться він в процесі постійного навчання?
- Чи знає цей кандидат про свої слабкості і чи може спокійно обговорювати їх?
- Наскільки цей кандидат універсальний і здатний зробити «все, що буде потрібно», щоб забезпечити комерційний успіх продукту?
- Чи належить кандидат до числа «десятикратних» програмістів?
- Чи володіє він ступенем бакалавра, отриманої в одному з поважних університетів?
- Якщо кандидат має докторським ступенем, чи є інші ознаки, що свідчать про його здібностях до розробки комерційних продуктів?
- Чи є у кандидата досвід роботи в групах, що займалися розробкою комерційних продуктів?
- Чи може кандидат уявити приклади хорошого коду?
- Чи любить кандидат програмування настільки, щоб писати код у вільний час?
Позитивна відповідь на всі 10 запитань не обов'язковий. Я навіть не збираюся вказувати максимальну кількість позитивних відповідей, необхідних для прийняття кандидата. Наймання - це лотерея, і кожне питання може послужити ознакою для оцінки придатності кандидата.
В кінцевому рахунку, будь-яке рішення з області найму здійснюється вольовим рішенням, і ніякі гарантії тут неможливі. І все ж якщо приділити увагу цим питанням, вони підвищать ймовірність того, що вам не доведеться пізніше пошкодувати про прийняте рішення.
Додаткова інформація по темі
Огляд партнерських програм, поради як на них можна заробити гроші не виходячи з дому