Собеседования. Найм программистов.
От: msk78 Россия http://miccro.livejournal.com
Дата: 17.09.08 10:45
Оценка: 88 (30) +20 -7 :))) :))) :))) :))) :)))
Ответ автору темы "в очередной раз о собеседованиях" (http://rsdn.ru/forum/message/3094939.1.aspx
Автор: mymuss
Дата: 09.09.08
)

Собеседования. Найм программистов.
(сильно не ругайте А ругайте несильно )

Очень много высказано мнений, как нанимать, кого нанимать на должность программиста.
Кто-то даёт тестовые задания, кто-то, к счастью не даёт их. Кто-то заставляет решать головоломки, кто-то нет.
Народ уже даже начал составлять книжки таких головоломок типа "Горы Фудзиямы". Выучи-де и будет тебе счастье. Некоторые задают вопросы из теории графов, спрашивают разного рода алгоритмы поиска.

Нормально ли это? Да, нормально. Можно спрашивать хоть площадь круга, хоть площадь Ленина. Можно даже нанимать программистов по размеру члена. Вопрос только в том, кто вам нужен, какой фильтр вы хотите наложить на кандидатов, каких работников хотите нанять.
Прежде всего работодатель, именно работодатель, а не люди, проводящие собеседования, должен задать себе вопрос, кто ему нужен.

Люди часто исходят из предпосылки, что программист — творческая работа, но задумайтесь, всегда ли это так. Я вам отвечу — нет, не всегда. Из-за непонимания этого сплошь и рядом происходят казусы, которые в результате заканчиваются плачевно для работодателя.

На самом деле зачастую программист — это лопатная работа, не требующая сверх-навыков мышления. На неё отлично подходят вполне посредственные люди.

Теперь давайте посмотрим на примере одного из наших проектов, к чему приводит достаточно сложное тестовое задание и/или решение кандидатами головоломок. С одной стороны наняты творческие люди с хорошими математическими способностями, программисты до мозга и костей, люди, которые лучше просидят за ЭВМ всю ночь, чем будут трахать свою жену хотя бы раз в неделю. Такой программист полностью переписал механизм сессий, реализованный Майкрософтом, для коммерческого веб-проекта из трёх страничек с примитивными операциями типа getAllUsers() и getAccountByID(departmentID). Этому человеку стандартная обработка сессий, видите ли, показалась недостаточно универсальной. Как результат, этот проект делался около года, он очень тяжёлый в поддержке, куча багов, относящихся к реализации сессий, а не к бизнес-логике. Хотя сам по себе проект простой, но на него работодателю очень тяжело нанять людей, так как в нём задействовано очень много редко используемых технологий. Собеседования проводит сам же этот программист и отсеивает большую часть народа. Помню, некоторых даже выгоняли с этого проекта. В результате геморрой только у работодателя — с наймом персонала, поддержкой плюс недовольство заказчика.

Пример из другого проекта. Были наняты подобные люди (мегамозги), которых не устроил майкрософтовский WCF и они написали свой и ещё много чего наворотили. Результат:
— они уже сами толком не помнят, как это работает;
— Работает всё это жутко медленно;
— глюкает жутко, ибо всё сложно, куча багов;
— в некоторых случаях работает не в соответствии с бизнес-логикой;
— проект тяжёл в поддержке;
— тяжело найти людей

В действительности же работа среднестатистического программиста рутинна. Причём неважно старшего разработчика или просто программиста. В большинстве своём это поддержка уже существующих проектов, исправление багов. Здесь не нужны мегамозги, а нужны обычные усидчивые люди, способные выполнять частенько монотонную работу — исправить очередной среднестатистический баг, собрать очередной (!) билд, поправить старый юнит-тест и т.д.

А теперь посмотрим, что после всего этого происходит на рынке труда.

Частенько уже наняв (!) C# программиста, работодатель предлагает ему поддерживать уже существующий проект на какой-нибудь старой (!) технологии. Как следствие мегамозг на таком проекте чувствует себе неудовлетворённым и в итоге увольняется, ибо ему скучно. Мегамозгу плохо, но на самом деле хуже всего работодателю — снова нужно искать нового человека, которого опять надо обучать. Итак рационализаторское предложение такой конторе: давайте не будем выпендриваться, наймём обычных людей, знающих, как держать молоток и умеющих просто им работать. И не надо нанимать лётчика-космонавта и слесаря в одном лице. Будьте проще!


Новый проект. Работодатель нанял мегамозгов. В долгосрочной перспективе имеет кучу геморроя с поддержкой проекта и наймом персонала. В итоге работодатель материться, теряет деньги, снова вынужден набирать мегамозгов за дорого, ибо в этом коде, похожем на густое дерьмо, являющемся дьявольским сплетением самых новых, сложных и никому ненужных технологий, простому среднему программисту разобраться очень тяжело. Нанятые же мегамозги-маньяки увольняются через полгода, потому что не хотят заниматься поддержкой, не хотят править JavaScript и старые юнит-тесты.


В качестве заключения.
Мегамозгов нанимать можно, но только использовать их под чутким руководством прагматичных людей и только там, где это действительно надо.
Можете спрашивать хоть сколько яичек у гиппопотама, но задумывайтесь при этом, что получите в результате.
Следствием всего этого является огромное количество неуспешных проектов.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.