О проблемах подбора персонала в IT-индустрии

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

Страх личной конкуренции

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

“мда... у меня тоже так в паре контор было... нарвался на единственного архитекта в конторе ну и он мне начал сыпать ересь лишь бы ему так дальше одному в конторе и остаться :) убирал конкуренцию))” (Solution Architect с многолетним стажем одной из крупнейших мировых IT-компаний)

Если тим-лидер не обладает достаточным уровнем храбрости, он никогда не одобрит сильного разработчика в свою команду, который может сместить его с лидерских позиций.

Помните телешоу “Последний герой” про выживание на острове, которое появилось в 2001 году? В полуфинале участники нередко голосовали за удаление из игры не слабых, а сильных участников, чтобы те не дошли до финала. Не помню дословно, но один из участников прямым текстом сказал что-то вроде того, что настало время убирать сильных конкурентов, так как финал уже близок.

“Why do we need a software process? For the same reason that we need laws, governments, and taxes: fear.” (“Planning Extreme Programming” by Kent Beck, Martin Fowler)

Developers are afraid, too. They fear that

  • They will be told to do more than they know how to do.
  • They will be told to do things that don’t make sense.
  • They are too stupid.
  • They are falling behind technically.
  • They will be given responsibility without authority.
  • They won’t be given clear definitions of what needs to be done.
  • They’ll have to sacrifice quality for deadlines.
  • They’ll have to solve hard problems without help.
  • They won’t have enough time to succeed.

(“Planning Extreme Programming” by Kent Beck, Martin Fowler)

“But when our fears are acknowledged and our rights are accepted, then we can be courageous.” (“Planning Extreme Programming” by Kent Beck, Martin Fowler)

Не исключив субъективного влияния, сложно говорить о качественном подборе персонала.

На личностном уровне, страх личной конкуренции является следствием застоя в личностном развитии. Если человек не развивается, у него возникает страх, что он безнадежно отстал от других, и уже не в состоянии быть на равных. Как показывает практика, и советует Steve McConnell, для постоянного развития достаточно читать 5 страниц в день профессиональной литературы. Правда, нужно еще уметь разбираться в литературе. Если Вы в ней не разбираетесь, то начните чтение с Robert Martin, Steve McConnell, Martin Fowler, Kent Beck, Erich Gamma. Когда человек постоянно растет как специалист, то он, наоборот, стремится работать с сильными специалистами для обогащения своего опыта.

“Неторопливое, но регулярное чтение — надежный путь к высоким профессиональным достижениям. Если, читая примерно по 35 страниц в неделю, вы будете прочитывать одну хорошую книгу по программированию каждые два месяца, скоро вы получите основательный багаж знаний и начнете выгодно отличаться почти от всех окружающих вас разработчиков.”

“A little reading goes a long way toward professional advancement. If you read even one good programming book every two months, roughly 35 pages a week, you’ll soon have a firm grasp on the industry and distinguish yourself from nearly everyone around you.” (“Code Complete” by Steve McConnell)

“Чтобы стать экспертом в практической или научной области, нужны огромный труд и долгое время. Если человек добросовестно трудится каждый час рабочего дня, когда-нибудь он проснется одним из самых компетентных специалистов своего поколения.” (Уильям Джеймс)

“We become authorities and experts in the practical and scientific spheres by so many separate acts and hours of work. If a person keeps faithfully busy each hour of the working day, he can count on waking up some morning to find himself one of the competent ones of his generation.” (William James)

Так же устранение личных страхов является одним из ключевых моментов гибкой методологии разработки программного обеспечения “Экстремальное программирование”.

В общем, будьте мужчиной, конкурируйте честно. А еще лучше - учитесь сотрудничать, а не конкурировать.

Компетентность

Мне приходилось сталкиваться с откровенной некомпетентностью, например, когда собеседующий доказывал что deadlock (взаимная блокировка) может возникнуть даже при блокировке одной-единственной строки БД (на самом деле в таком случае возникает “ERROR: could not serialize access due to concurrent update”).

Иногда бывает что на собеседовании задают вопросы, которые совершенно не раскрывают опыт кандидата, а, скорее наоборот, характеризуют невысокий уровень самой компании.

А иногда приходилось сталкиваться с настолько аморальным и лживым поведением собеседующих, что в реальность происходящего было трудно поверить.

Из общения с коллегами я понял, что такие случаи имеют массовый характер.

Существует очень опасное состояние человека, которое получило название “The Expert Beginner”, причиной которого является Эффект Даннинга - Крюгера. Но еще опасней, если подобные “специалисты” привлекаются для оценки соискателей.

Часто на собеседованиях также спрашивают, как бы поступил соискатель в случае, если он не согласен с решением руководителя. Суть этого вопроса не совсем ясна. Существует поведение профессиональной этики, ярко описанное Робертом Мартином в книге “Clean Coder”. Именно так и должен поступать профессионал - этично, профессионально и в интересах дела. Где-то в Индии, как я слышал, процветают проектные ошибки из-за того, что никто не смеет возражать руководителю, в силу особенностей национального менталитета. Хочется верить, что этот вопрос, все-таки, на осведомленность соискателя об этой книге.

Причины искажения объективности результатов собеседования

Существует ряд психологических законов, которые так или иначе проявляются при собеседовании:

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

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

Часто причиной разногласий может быть несовпадение фаз развития специалистов. Например, если у одного специалиста имеет место девиация в сторону паттернов, а у другого - в сторону алгоритмов. Очень хорошо это явление объясняет Сергей Тепляков:

Вторая причина столь разных точек зрения на использования инструментов заключается в «спирали обучения». Если у вас больше 5 лет опыта, то вы наверняка замечали, что кривая обучения на самом деле выглядит не совсем так, как обычно принято представлять, а несколько иначе. Я бы сказал, что кривая обучения – это скорее бесконечный процесс, который в лучшем случае будет «сходиться» к точке «идеального использования инструмента»:

Рис. 1: Кривая обучения vs. Спираль обучения

Рис. 1: Кривая обучения vs. Спираль обучения

Форма этой «спирали обучения» обусловлена нашей увлеченностью. Как только мы узнаем о новом инструменте мы начинаем его интенсивно использовать, нас «заносит» и мы начинаем его применять там, где нужно, и там, где без него было бы лучше обойтись. Со временем наша эйфория проходит и мы можем либо вообще отказаться от него («Все, паттерны проектирования не нужны!») или же перейти на новый уровень понимания и использовать инструмент более рационально.

Разные люди находятся на разных точках «спирали обучения», что также усложняет взаимопонимание. К тому же, у разных людей точка «правильного» понимания (линия «правильного понимания» на графике справа) находится на разном уровне, что проявляется в том, что кто-то полностью отказывается от инструмента («TDD не нужен!», или «IoC не нужен!», «или ОО не нужно» и т.п.), а кто-то продолжает упорно использовать инструмент не по назначению.

- “Is TDD Dead. Часть 5”, Сергей Тепляков

Такое простое объяснение профессиональных конфликтов. Которое объясняет, в том числе, почему соискатель и интервьюер часто не находят друг друга.

Часто собеседование воспринимается как оценивание, и в этом источник психологического напряжения. На самом деле, цель собеседования - выяснить, насколько соискатель и компания подходят друг другу.

Лучшая система отбора кандидатов в моей практике

В этой системе решение о переходе собеседника на следующий раунд принимал весь технический коллектив.

Сперва коллективно изучали резюме человека и изучали его Open Source библиотеки.

Если у человека открытого кода не было, то давали ему тестовое задание. Причем, тестовое задание было очень интересным, оно хорошо раскрывало навыки доменного проектирования кандидата. Задание было часов на 8-22, смотря какие технологии использовались. Высшим пилотажем было сделать задание без использования веб-фреймворка и без ORM (используя Patterns of Enterprise Application Architecture). Дело в том, что веб-фреймворк и ORM маскируют навыки проектирования кандидата. Но мы не возражали против их использования.

Если вы знаете что такое истинный Agile, то вы понимаете, что без качественного и простого проектирования невозможно достигнуть низкой стоимости изменения программы. А проектные решения должны применяться каждым разработчиком в процессе “Проектирования Через Рефакторинг”. Отличие между Архитектором в каскадной (Waterfall) разработке и Инструктором (Coach) в Agile методологии заключается именно в том, что Инструктор помогает участникам команды принимать проектные решения.

После этого делался коллективный код-ревью. Это не значит что все делали его одновременно. Каждый находил в течении дня несколько минут, чтобы просмотреть код кандидата и отписать свои замечания в системе online-review.

Обычно в задании были какие-то недочеты, и мы в процессе коллективного ревью просили кандидата устранить проблемы. Мы указывали на проблему, говорили о том как ее можно устранить, и смотрели, насколько человек способен ее исправить. Не так важна допущенная ошибка, как способность человека ее исправить и применить полученную информацию на практике. Всю информацию, необходимую для исправления ошибки, мы предоставляли в виде ссылок на соответствующие интернет-ресурсы.

После этого делали голосование, и человек переходил на следующий раунд.

Далее проводили коллективное собеседование. Всей командой. Любой мог задать вопрос.

Интервью - это вопрос очень тонкий. Есть разница между тем, чтобы “завалить” кандидата, откровенно демонстрируя ему свой апломб и утверждаясь на его фоне, и тем, чтобы оценить его реальный уровень знаний, да так, чтобы при этом он не почувствовал себя полным идиотом. Ведь он тоже не в единственной компании проходит собеседование, и у него должно сохраниться желание работать у Вас. Разумеется, готовый специалист нам практически никогда не попадался, поэтому основной задачей собеседования было оценить насколько быстро кандидата можно обучить и сделать его полезным участником команды.

Потом опять голосование.

После этого следовало интервью с CEO.

После этого - оффер.

Важно отметить, что такой подход воспитывал чувство ответственности за коллектив, и формировал высокую самомотивацию его участников. Командный дух был очень высоким.

Весь этот процесс был открытым для HR-менеджера и проходил под его наблюдением.

Поэтому к нам в команду попадали сильные ребята. Невозможно было никого “топить” из страха личной конкуренции, когда на тебя смотрит вся команда. Невозможно было сказать “нет” когда вся команда говорила “да”.

Если кто-то говорил “нет”, то он должен был обосновать свое “нет” каждому, кто сказал “да”.

Команда понимала, что им с этим человеком придется укладываться в дедлайны. И каждый был заинтересован в том, чтобы брать сильных ребят.

Страх личной конкуренции уходил на второй план, тем более, что у нас в команде люди постоянно развивались и работали с литературой. Как правило, технический уровень нашей команды был выше новых кандидатов, хотя и не без исключений.

Кроме того, мы использовали некоторые практики “Совместной Разработки” Agile методологии. А в таком случае разработчик либо достигает среднего уровня команды в кратчайшие сроки, либо просто выбывает из команды в течении первого месяца. Последний случай был всего один раз, и он имеет широко распространенное название “RTFM”. Примечательно то, что этот разработчик изначально не прошел систему отбора и был принят в порядке исключения под давлением обстоятельств.

Но вернемся к Agile. Все участники команды имеют примерно одинаковый и высокий уровень. В этом и заключается смысл истинного Agile, поскольку без этого невозможно осуществить “Коллективное Владение Кодом” и “Проектирование Через Рефакторинг”, а значит, невозможно обеспечить и низкую стоимость изменения кода, что и составляет основу Agile. Это еще одна из причин почему наша команда жаждала сильных кандидатов - они знали, что его опыт в считанные месяцы реплицируется на всех. Впрочем, не было и борьбы за кресло (тимлидов просто не было).

О тестовом задании

Вообще говоря, когда профессионал своего дела нанимает профессионала, то необходимости в тестовом задании обычно нет, ибо они способны узнать друг друга с нескольких слов. Когда к нам собеседовался, например, этот парень @crodas, то было очевидно, что если мы предложим ему пройти тестовое задание, то он воспримет его как, если ни прямое оскорбление, то, как минимум, проявление нашей профессиональной некомпетентности и неспособность разбираться в специалистах.

А как говорил один мой старый знакомый, лучше с умным потерять, чем с дураком найти.

Если компания предлагает пройти тестовое задание в тех случаях, когда оно откровенно излишнее, я считаю это проявлением жесткости компании (формализм), которая демонстрирует неспособность компании гибко адаптироваться к обстановке. Обычно это чревато невозможностью наладить Agail методологию в ее истинном виде и приводит к напряженной моральной обстановке и текучке кадров.

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

Однако, в некоторых случаях, тестовое задание может сослужить Вам хорошую пользу, например, если вы претендуете на прямой внешне-экономический контракт и неуверены в своем разговорном Английском. В таком случае тестовое задание поможет Вам продемонстрировать свой опыт в отдельности от Вашего разговорного Английского.

Хорошо когда наниматель, перед тем как выдать тестовое задание, трезво оценивает способность кандидата пройти его. Это простое проявление человечности. Не стоит отнимать время у того, кто его, с очевидной вероятностью, не сможет пройти. Это как бить лежачего.

Чтобы тестовое задание хоть что-то продемонстрировало, оно должно занять у кандидата 2-3 дня. Если Вы уважаете профессионализм, то будьте готовы оплатить это задание по той же ставке, на которую рассматриваете кандидата. Кандидат не должен платить за Ваши страхи.

Далеко не всегда тестовое задание может быть объективно оценено на соответствующем уровне. Многое зависит от профессионального уровня самого собеседующего инспектора. Поэтому, прежде чем потратить пару дней своего времени, прособеседуйте незаметно самого инспектора. Задайте ему невзначай пару “уточняющих” вопросов (желательно в режиме online, чтобы исключить гугление) которые продемонстрируют Вам его способность объективно оценить Ваше задание. Он Вам про селери - Вы ему про выбор реализации пула и интерфейс адаптера для сокрытия селери. Он Вам про асинхронность - Вы ему про выбор конкретной реализации. Он Вам про оптимизацию и массовую вставку данных - Вы ему про уровень изоляции транзакций и предотвращение взаимных блокировок. Разумеется, он не обязательно ответит на Ваши вопросы, но, по крайней мере, продемонстрирует свою способность оценить Вас. В конце концов, ум человека лучше видно по его вопросам, а не его ответам.

Полезные решения

Я опишу несколько полезных практик которые я наблюдал в грамотных компаниях.

В некоторых компания на всех этапах собеседования присутствует HR-менеджер лично. Это устраняет конфликт интересов, так как HR заинтересован в принятии сильных специалистов, а технические интервьюеры иногда имеют конфликт интересов (страх личной конкуренции).

В грамотных компаниях техническое собеседующее лицо привлекается из параллельной команды, чтобы исключить его личную заинтересованность (“потопить” потенциальных конкурентов или “протолкнуть” своих друзей).

Иногда на собеседовании присутствует представитель бизнеса, т.е. лицо заинтересованное в качестве разрабатываемого продукта, что тоже оправдано.

Иногда для собеседований используется внутрикорпоративная система видеосвязи, которая фиксирует собеседование.

А в очень грамотных компаниях кандидата просят оставить фидбэк о собеседовании и ответить на десяток вопросов.

Бывают случаи, когда представители бизнеса и HR-менеджеры, присутствовавшие на интервью лично, остаются недовольными оценками заангажированных технических интервьюеров, и устраивают контрольное интервью с привлечением других технических специалистов.

Превосходная статья Сергея Теплякова “Как проводить технические собеседования?”.

Советы кандидатам

Что делать тому, кто оказался несправедливо недооцененным?

Прежде всего - убедиться в том, что такая оценка затрагивает именно Ваши знания, а не Ваш апломб. Действительно ли Ваши знания были недооценены? Конечно, проверка знаний - это такая вещь, что можно придолбаться и к столбу. Еще Дейкстра говорил:

“Компетентный программист полностью осознает строго ограниченные размеры своего черепа, поэтому подходит к задачам программирования со всей возможной скромностью.” (Дейкстра 1972)

“The competent programmer is fully aware of the strictly limited size of his own skull; therefore, he approaches the programming task in full humility.” (Dijkstra 1972)

Но ответьте себе на такой вопрос, сколько технических книг Вы прочитали за последний год? Что нового вы узнали за последний год? Что хотите узнать в течении года?

Будьте честными перед собой, и не перекладывайте своей вины на окружающих.

“Каждый хочет, чтобы правда была на его стороне, но не каждый хочет быть на стороне правды.” (Ричард Уэйтли)

“Everyone wishes to have truth on his side, but not everyone wishes to be on the side of the truth.” (Richard Whately)

Подумайте о том, чтобы получить сертификаты авторитетных сертификационных компаний.

Следующие строки относятся к случаю, когда Вы полностью уверены в своей компетентности.

“Благоразумный лидер не старается защитить людей от самих себя.” (“Дао лидера”, Лао Цзы, Джон Хейдер)

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

“Легче обмануть человека, чем убедить его в том, что он обманут.” (Марк Твен)

“It’s easier to fool people than to convince them that they have been fooled.” (Mark Twain)

Давать оценку эффективности управления компании - это прерогатива рыночных законов. И они мастерски с этим справляются.

Иногда такая политика приводит к тому, что заказчик, на фоне ухудшения экономики разработки, увольняет всю команду целиком и потом набирает новую команду.

И не нужно трепать нервы рекрутерам, они и так работают как “между молотом и наковальней”. Не они устанавливают правила. Я знаю от рекрутеров как часто им приходится выслушивать негатив со стороны кандидатов. Будьте снисходительнее.

Советы работодателям

Очень часто рекрутеры ищут готового специалиста по определенному стеку технологий. По своему опыту знаю, что на поиск хорошего специалиста уходят месяцы. А на поиск хорошего специалиста с нужным стеком технологий - еще больше времени.

Допустим, Вам повезло, случилось чудо, и Вы нашли готового специалиста за пару месяцев. Пока он пройдет все формальности, поднимет рабочее окружение, и приступит к работе, пройдет до двух недель, и это если он уже рассчитался с предыдущим работодателем. Пока он войдет в суть проекта и начнет самостоятельно работать, пройдет еще пара месяцев, и это при условии если Вы используете методики “Совместной Разработки” для обмена опытом (что уже редкость).

Итого, четыре с половиной месяца до начала полноценной работы, и это в оптимистическом случае.

Освоить же Angular занимает 2-4 недели. Пока человек проходит все формальности и входит в суть проекта, он вполне может освоить эту технологию при условии, что у него уже существует базовая подготовка по JavaScript.

По этой причине мы иногда нанимали разработчиков без опыта с Python, но с большим опытом проектирования на PHP. Просто освоить Python можно намного быстрее, чем освоить проектирование. У опытного разработчика знание синтаксиса языка программирования составляет не более 10% его знаний.

Updated on Dec 23, 2017

Реализация паттерна Repository в браузерном JavaScript   Знакомство с Docker для Django-проекта

Comments

comments powered by Disqus