Найм сотрудников. Часть 1 – Профессионализм.
Хочу продолжить давнюю тему о найме сотрудников, начатую некоторое время назад Тимофеем Евграшиным. Мне по долгу службы приходится очень часто проводить собеседования. Больше всего собеседую Java программистов и технических лидеров разного уровня для проектов компании. В этой серии статей я хочу поделиться своими наблюдениями, мыслями, идеями и приемами проведения собеседования.
Первая часть будет посвящена такому интересному явлению как “профессионализм”. Это вроде бы очень простое и часто употребляемое понятие, но каждый вкладывает в него совершенно разный смысл. Большая часть людей, проходящих собеседование, считают себя профессионалами. Почему же тогда заявленный уровень знаний и опыта сильно расходится с действительностью? Для чего в резюме включено столько различных аббревиатур, представляющих технологии, инструменты и языки программирования? Как может Java разработчик с опытом работы более 7 лет не разбираться в JMS? Я задавал себе эти вопросы не раз и, мне кажется, я знаю ответ.
Многие из программистов привыкли думать, что компания-работодатель отвечает за их карьеру, опыт, технологический рост и накопленные знания. Я не знаю откуда взялось такое предубеждение. Может быть из университета, где дела обстояли именно так, может быть от специфики индустрии или по неизвестным мне причинам. Эта мысль выстраивает весь остальной путь развития такого программиста. Он не изучает технологии, которые не применяются в проектах, он не ходит на тренинги и конференции, если их не оплачивает компания, он не следит за тенденциями в индустрии и новыми технологиями. Но разве в этом заключается профессионализм? Настоящий профессионал сам отвечает за свое образование и развитие. Он инвестирует свое время в развитие, изучение технологий, общение с коллегами, чтение технической литературы и многое другое. Отношения с работодателем рассматриваются только как контракт, в результате которого вы получаете материальную прибыль за выполнение определенной работы.
В этом случае цена контракта напрямую зависит от ваших профессиональных навыков, от того, насколько хорошо вы делаете свою работу. Система обретает логичность – вы вкладываете в себя, компания платит вам согласно успешности вложений. Вам выгодно продолжать вкладывать, потому что тогда вы можете повысить свою стоимость. Что же происходит на рынке труда в IT? За счет кризиса профессиональных кадров многие компании пилят сук, на котором сидят. Они сначала вкладывают средства в развитие сотрудника, а потом сами же за это ему платят в виде повышения заработной платы. Доходит до абсурда, когда сотрудник приходит на тренинг, на который никогда бы не пошел в случае самостоятельной оплаты (хотя бы минимальной). Я не знаю ни одной индустрии с похожей ситуацией.
Вторая черта, присущая профессионалам – это ответственность за свою работу. Профессионал не выпустит код, который он ни разу не запускал, надеясь, что отряд бравых тестировщиков найдет все допущенные ошибки. Он неоднократно проверит свой код и приложит максимум усилий к тому, чтобы не было найдено ни одного дефекта. Возвращаясь к предыдущей мысли по поводу контракта, нужно отметить простой принцип – чем качественнее и эффективнее вы работаете, тем на большую сумму контракта вы можете претендовать. Но за качество должен отвечать сам сотрудник, прилагая максимум усилий, чтобы его повысить. Я рад, что в последние пару лет наблюдается заметный рост в использовании практики модульного тестирования кода. Теперь почти каждый собеседуемый если и не пишет модульных тестов, то осознает их важность и полезность. А это шаг в правильном направлении.
Ответсвенность важна не только на уровне написания кода. Мы все работаем в команде, состоящей из разных людей. Профессионал должен это четко понимать и брать ответственность за результаты командной работы. Без командной работы результаты одного человека теряются на фоне общего провала команды. Фразы “зато моя часть кода работает” и “я то пишу код без багов” никак не улучшают общую тенденцию, возможно даже наоборот. Профессионал стремится приложить максимум усилий для того, чтобы улучшался командный результат. Это касается качества кода, оценок и планов, процессов и практик. Профессионал не гонится сугубо за собственной эффективностью, а успехи в улучшении командной работы дают ему дополнительные баллы к условиям контракта.
Многие программисты не практикуют написание кода. То есть, они конечно пишут код на работе на своем проекте, но не более чем. Работая на одном проекте в течении года, многие программисты изменят свой стиль и практики, следуя проектным стандартам. Но они не всегда есть и далеко не всегда достаточно хороши. Профессионал же пытается привнести в проект полезные практики, пишет код того уровня, который удовлетворяет его внутренним стандартам. Он не увязает в “болоте” существующего кода, а старается превратить его в “красивое озеро”. Для этого нужна практика, лучший способ получить которую – это писать код. Писать код в паре с другим программистом (не обязательно из вашей команды), участвовать в разработке разных модулей системы, проводить ревью чужого кода, свободное время практиковаться в рефакторинге существующего кода. Существует еще немало способов. Те же самые правила распространяются на архитектуру и дизайн. Важное качество профессионала в данном случае – это инициативность.
Все мы хотели бы работать с профессионалами, потому что они грамотно делают свою работу и у них есть чему поучиться. К сожалению, встречаются они не так часто. Чтобы исправить ситуацию стоит самим сделать шаг в сторону профессионализма и начать двигаться в этом направлении. Читайте больше технической литературы, изучайте основные технологии из вашего направления работы, посещайте конференции и смотрите выступления онлайн, подпишитесь на блоги и новостные порталы, чтобы быть в курсе событий. А главное, практикуйте много и постоянно.
В следующей части я расскажу как за время собеседования сложить представление об уровне профессионализма кандидата. Оставайтесь с нами!
Спасибо за комментарий. Имелось ввиду, что рефакторить можно не только код разрабатываемой системы, но и другой код. К примеру, можно взять библиотеку с открытым кодом или код другой системы в вашей компании. Отличие от рабочего рефакторинга заключается в том, что вы можете экспериментировать сколько угодно и потом просто выбросить свои изменения. Это своего рода упражнение “на кошках”. Я очень люблю подобные упражнения, потому что они учат вырабатывать хороший дизайн и применять различные шаблоны. Понятное дело, что упражняться нужно в свободное время.
Абсолютно с Вами согласен !!!
Но все же во фразе “свободное время практиковаться в рефакторинге существующего кода”, слова “свободное время” явно лишние, IMHO.
Разработка, там более, agile разработка включает в себя понятие рафакторинга, как составной части – поэтому не понятно, почему рефакторинг некого рабочее кода надо делать в свободное время, а не в рабочее.