Мы все встретили их. В программистах , которые не могут программировать . Они вряд ли могут написать что-нибудь, что собирается самостоятельно. Создание качественного качественного кода намного выше их навыков. Каким-то образом они все еще нанимаются. Пытаясь выяснить, почему, я перечислил 7 распространенных ошибок, допущенных при наборе персонала.
Семь ошибок
- Ориентация на многолетний опыт.
- Доверяйте людям собственную оценку их мастерства.
- Не просите кандидата написать код.
- Рекрутинг для «другой команды».
- Прощайте орфографические ошибки в резюме.
- Сосредоточьтесь на технических навыках, а не на навыках общения.
- Страх найма кого-нибудь получше.
Фокус на годы опыта
Многолетний опыт прост и объективен для измерения. Для любого отдельного человека любой дополнительный опыт добавляет к навыкам, поэтому естественно сделать вывод, что количество лет опыта является наиболее важной мерой для навыка.
К сожалению, этот вывод совершенно ошибочен, особенно для программирования. Самый важный навык стать великим программистом — это талант. Некоторые люди имеют склонность стать программистом; некоторые нет . Приоритет номер один при наборе программистов — выяснить, обладает ли кандидат способностью. Если кандидат не имеет, несколько лет опыта не помогут. Кандидат не является и никогда не будет великим программистом.
Доверяйте людям собственную оценку их мастерства
При собеседовании я всегда спрашиваю кандидата о собственной оценке его мастерства в разных областях. Знание их собственного мнения об их навыках имеет решающее значение, но я бы никогда не стал им доверять. Проблема в том, что люди с самой высокой компетенцией обычно будут очень скромными. С другой стороны, будут кандидаты, которые имеют некоторые базовые навыки и будут хвастаться этим.
Вместо того, чтобы доверять оценке собственных навыков кандидатов, я ищу кандидатов с реалистичным взглядом на их навыки.
Я также использую этот вопрос, чтобы выяснить, в каких областях кандидат претендует на высшую компетенцию. Затем я выбираю одну из этих областей для тестирования кода. Я стараюсь быть милым, позволяя кандидатам показать свои навыки написания кода в своей сильнейшей области.
Не просите кандидата написать код
Я думаю, что тестирование кода является важной частью интервью программиста, но многие люди, очевидно, игнорируют его. Я удивлен этим, потому что есть люди, которые могут говорить, но полностью застряли, когда их попросили написать код.
Тест кода не должен быть очень сложным. Те, кто вообще не умеет программировать, покажут это даже на простом тесте. В своих недавних интервью я использовал две задачи.
Первый касается доступа к данным. Представляю небольшую базу данных с таблицами Persons и Cars. Существует также внешний ключ от стола автомобилей к столу человека, указывающий на владельца каждого автомобиля. Я позволил кандидату объяснить, как эти отношения должны быть реализованы с помощью внешнего ключа, что также требует установки первичного ключа в таблице персонала. Затем я прошу их произвести простой набор результатов.
| Car Reg No | Имя владельца |
|---|---|
| ABC123 | |
| LDB109 | |
| CED456 | Альбин Суннанбо |
Я позволил кандидату выбирать между LINQ и SQL для реализации запроса. В любом случае, для опытного разработчика, который привык писать код доступа к данным, запрос должен быть действительно простым для записи.
Другое, что я использовал, — это запись подкласса Square в базовый класс Shape, который я предоставляю.
public abstract class Shape { public abstract float GetArea(); }
Я также думал о том, чтобы попросить людей решить проблему шипения, но еще не сделал этого шага. Как вы думаете, я должен попробовать?
Рекрутинг для «другой команды»
В конце интервью я всегда задаю себе критический вопрос.
Хотел бы я, чтобы этот человек в одном из моих проектов сидел за столом рядом с моим несколько месяцев?
Если нет, то это не прокат. Как пишет Джоэл Спольски в своем « Партизанском руководстве по интервью », брать на работу в другую команду — плохая идея:
Никогда не говори «найми, но не для моей команды». Это грубо и подразумевает, что кандидат недостаточно умен, чтобы работать с вами, но, возможно, он достаточно умен для тех неудачников в другой команде.
Прощайте орфографические ошибки в резюме
Перед собеседованием я всегда читаю резюме кандидата. Конечно, я смотрю на предоставленную информацию, но я также внимательно смотрю на то, как она предоставляется. У него хорошая структура? Это написано правильно?
Письменные навыки общения всегда важны в любой работе программиста. Хотя программист в основном будет писать код, он также должен иметь возможность писать документацию и время от времени писать электронные письма заказчику. Если они не могут четко выразить свое резюме, они, вероятно, также не смогут выразить что-либо еще ясно.
Если существует много орфографических ошибок, которые любая текстовая обработка помечает как неправильные, это признак чистой лени оставлять их без исправлений. Если кандидат ленив в отношении заявления о приеме на работу, существует огромный риск для лени в работе тоже.
Сосредоточьтесь на технических навыках, а не на навыках общения
Люди иногда утверждают, что разговорные навыки общения не важны для программистов. Пока они пишут отличный код, это все, что актуально.
В командной среде нет ничего более неправильного. Не имеет значения, что все в команде пишут отличный код, если они не могут сообщить о своих намерениях. Для достижения отличного результата команда должна работать вместе над общей идеей.
Я обычно прошу кандидата описать архитектуру предыдущей системы, над которой работали. Неважно, что это за система. То, что я ищу, так это то, что кандидат понял основы архитектуры и может рассказать о ней.
Страх найма кого-то лучше
Техническое интервью (если оно вообще проводится) обычно проводится старшим разработчиком или архитектором. Этот разработчик, вероятно, занимает определенную должность в компании, будучи единственным, кто знает, как решить действительно сложные проблемы
Что произойдет, если с таким же хорошим или, может быть, даже лучше, с программистом взяли интервью? Есть две возможные реакции от интервьюера.
- Этот человек действительно хорош, я больше не буду лучшим в компании. Это будет угрожать всей моей позиции.
- Этот человек действительно хорош, наконец-то у меня будет кто-то, кто бросит мне вызов. Вместе мы сможем создать действительно сильную команду и стать еще лучше.
Мысль об угрозе очень распространена (не только среди программистов). К сожалению, это ведет к падению компетентности, если каждый всегда набирает кого-то менее компетентного, чем они сами.
Смеете ли вы нанять кого-то, кто может быть лучше, чем вы?
Наем сложно
Наем труден и требует тяжелой работы. Требуется уверенность в себе, чтобы позволить себе нанять кого-то, кто может бросить вызов себе (в позитивном ключе). В конце концов, для этого требуются очень жесткие решения, с выбором «без найма», даже если они испытывают огромное давление со стороны руководства на развитие компании.
Я иногда думаю о наборе персонала как о единственной дате, а затем о необходимости решить, расстаться или предложить. Это решение о том, с кем вы будете проводить 40 часов в неделю в течение следующих нескольких лет.