Прежде всего, давайте определимся, кто такой ведущий разработчик, по крайней мере, как это понимаю я. Ведущий разработчик, также известный как синьор, это разработчик с многолетним опытом работы (10+ лет), который успел поработать в нескольких конторах над несколькими проектами. За свою немаленькую карьеру такой разработчик, скорее всего видел и махровый легаси и смузи стартапы и кровавый энтерпрайз.
- Он не верит во всякие переходы на .Net Core, разбиение монолита, микросервисный подход и высокие нагрузки. Потому что это ему обещали уже много раз, а на деле кодовая база была слабоструктурированным плохим кодом, а высокая нагрузка – это 100 заказов в минуту.
- Он не верит во всякие гибкие методологии, которые на самом деле сводятся к отсутствию ТЗ и некомпетентным менеджерам, которые ставят задачи. Ах да, и еще тот эджайл коуч без технического образования с опытом работы 2 года, который объясняет тебе, как нужно работать.
- Он не верит во всякие дух и ценности, потому что они куда-то сразу деваются, когда выручка перестает расти и срочно возникает необходимость искать виноватых. Ибо вот эти ребята с систематической ошибкой выжившего не прекращают верить, что они крутые управленцы, а не им просто повезло.
- Он не нуждается в пятничных посиделках в свободной обстановке, шашлыках и выездах на тимбилдинг, так как у него, скорее всего, уже семья и дети и он хочет проводить с ними свободное время.
- Ему не нужны бесплатные энергетические напитки и сэндвичи в офисе, так как он лучше поест дома вкусный и здоровый ужин, чем будет пичкать себя этой химией.
Прежде чем сказать, ну мол, какой капризный, все ему не то, давайте разберемся, а что обычно хочет ведущий разработчик от компании?
- Он хочет адекватный менеджмент. Чтобы руководитель проекта понимал свою предметную область и, желательно, еще немного разбирался в разработке. Чтобы не обещали клиентам заведомо невыполнимые фичи.
- Он хочет работать по согласованным требованиям. И не потому, что он такой привередливый. А потому, что он понимает, что требования определяют архитектуру и сроки реализации, и смена их может привести к тому, что архитектуру нужно будет подпирать костылями, так как время на изменение никто не даст.
- Он хочет, чтобы команде давалось время на разработку архитектуры и рефакторинг не для того, чтобы смотреть интернеты в это время, а чтобы потом, через пару лет не страшно и не стыдно было смотреть кодовую базу.
- Он хочет, чтобы в компании была политика в области разработки программного обеспечения. Чтобы были четкий стиль кода, реализованный в средствах рефакторинга, статические анализаторы, средства CI/CD, тестовые контура.
- Некоторые разработчики хотят отдельные комнаты, а не опенспейс, чтобы не слышать разговоры пятидесяти людей вокруг или не сидеть в шумопоглощающих наушниках.
- И да, разработчик с опытом прекрасно понимает, что он, как и любой наемный персонал просто обменивает свои знания, умения и опыт на зарплату. Конечно, гораздо приятнее это делать в компании, которая приносит пользу людям, но многие, увидев прибавку 50% пойдут и блокчейн делать с бигдатой. У них ведь там семья и дети.
Теперь, определившись с вводными, можно перейти к теме здорового собеседования.
Так как же можно собеседовать таких капризных существ, как ведущие разработчики?
Общение с HR, наверное, необходимый пункт и, вероятно, с него и нужно начинать. Основная цель тут – отбросить заведомо непроходные варианты, чтобы снизить нагрузку на людей, проводящих техническое интервью. Это по сути единственная цель, потому что я лично видел пару раз на своем веку, как адекватные в общении люди слетали с катушек через полгода.
По техническому интервью.
Начнем сначала с того, для чего все это спрашивается? Скорее всего, все это нужно лишь для того, чтобы обезопасить себя от некомпетентных сотрудников. Но вы серьезно думаете, что разработчик с десятилетним стажем, работавший хотя бы по 1.5 года на каждом месте, успешно в течении десяти лет обманывал всех, что он не умеет писать код? А если это так, почему вы уверены, что ну вот ваше техническое интервью его раскусит?
Для чего нужны все эти алгоритмы обхода деревьев на собеседовании? Он что, каждый день будет писать эти деревья или алгоритмы сортировки в прод? Да у нас же пиццерия, у нас заказы в 23.59 превращаются в тыкву, мы тут не в Бостон Динамикс собеседуемся.
Тут, на мой взгляд, гораздо полезнее было бы просто пообщаться с кандидатом за жизнь, оценив степень его погружения в проблему. Одно дело сказать, ну я использовал технологию X на проекте, и совсем другое, узнать у кандидата, что были такие-то такие проблемы, котрые они решали так-то и так. Это позволяет оценить опыт человека гораздо больше, чем повторение стандартных алгоритмов перед собеседованием. Также необходимо учитывать, что все люди разные и для некоторых собеседование – большой стресс. Когда что-то начинают выпытывать несколько детективов, то обычно получается даже хуже, чем когда один (если цель состоит в том, чтобы взять адекватного человека). В процессе разговора необходимо честно рассказать реальное положение дел в компании, кто ставит задачи, есть ли стандарты разработки, CI/CD и прочее.
Собственно, и все. Этих двух пунктов вполне достаточно, чтобы нанимать отличных сотрудников, в чем я и мои коллеги убеждались на своем опыте ни один раз. Если ваш процесс растягивается на 5 шагов, если у вас десятки разрабов, а собеседует CTO, если вы собеседуете очно, а вам нужен тестовый день – то что-то поломано. Значит тут где-то скрыты чьи-то амбиции или комплексы, кто-то пытается копировать «лучшие» западные образцы не особо вдумываясь, зачем это делается. Сюда же можно отнести тот маркетинговый булшит про культуру и ценности. Я не знаю, действует ли это на джунов и мидлов, но поверьте, синьоры отлично понимают, что это булшит. И если работодатель пытается вешать много лапши на уши, то в какой-то момент внутренний булшитометр срабатывает и кандидат отваливается.
Так что, на мой взгляд, секрет успешных собеседований простой.
- Цените чужое время
- Говорите правду
- Не спрашивайте ничего, не относящегося к непосредственной трудовой деятельности
- Умейте слушать кандидата
И будет вам успех.
Комментариев нет:
Отправить комментарий