Наем как один из самых важных этапов построения эффективных команд/IT-компаний
Я привык говорить “найм”, но по-русски правильно именно “наём”. Так что сегодня поговорим про наём и я действительно считаю это крайне важный этап в разработке чего бы-то ни было коммерческого про IT.
Если у вас хорошая команда инженеров, менеджеров, дизайнеров и всех остальных у вас всё получится и наоборот, если команда плохая, то никакие процессы, системы мотивации и пр. не спасут вас от проблем. А наем правильных, подходящих друг другу людей это самый простой способ собрать хорошую команду. Считаю, что растить специалистов внутри еще более прекрасная идея, но это не так просто поставить на поток. И это тема для отдельной статьи.
Казалось бы, никто и не спорит что нанимать хороших сотрудников это важно, но мне кажется в IT далеко не все понимают насколько это важно. Про развитие сотрудников и команд, мотивацию, метрики и процессы много материалов и зачастую они выглядят как описание способа лечения болезни, но не как не заболеть. А вот ответ на вопрос: «Как сделать так чтобы ваша компания “не заболела”?» это именно: “Нанимать правильных людей”. Конечно это очень романтическое упрощение, так как процессы, мотивационные программы и т. п. в любом случае нужны, но кмк тема найма незаслуженно пребывает в относительном забвении.
И так, почему это так важно? Потому что если вы наняли раздолбаев, то вам мало что поможет. Процессы могут сгладить и замаскировать ситуацию, как и программы мотивации, планы развития, вероятно, смогут слегка ситуацию улучшить. Но вы всё равно будете иметь сильный перекос в сторону неэффективности работы и хорошо если бизнес-модель вашей компании пока позволяем иметь такую неэффективность.
В IT хватает проблем с набором людей: прохождение интервью возведено в культ: про это пишутся статьи, книги, записываются многочисленные видеоуроки, даже курсы есть, а уровень некомпетентности и равнодушия довольно высок.
И всё это вполне объяснимо, так как:
- разогнан миф о легких деньгах в IT (или это не миф?);
- зарплаты действительно высокие и растут;
- порог входа действительно не слишком высокий;
- работа не пыльная, зачастую можно работать по полдня (удаленно);
- довольно быстро можно научиться прятать свою некомпетентность;
- руководство зачастую не знает как сотрудника оценить и если себя “красиво” преподносить и позиционировать, то можно быстро расти по карьерной лестнице и/или откровенно забивать на работу.
Так вот, если у вас много слабых сотрудников, то ваша разработка будет крайне неэффективна. Поймите правильно, при командной работе всегда есть потеря ресурсов: процессы не будут на 100% эффективны + потери на коммуникацию, недопонимание и пр., но если у вас половине коллектива на всё плевать, а вторая половина не умеет работать, то…ну вы понимаете, вы экстремально неэффективны. И что бы вы с этим не делали это слабо поможет, так как у вас есть фундаментальная проблема, которую можно решить только сменой исполнителей. Однако заменить плохих сотрудников хорошими не просто и что важнее в контексте этой статьи, это сложнее чем сразу нанять хороших людей.
Вообще рынок IT довольно долго, в большинстве своём, “съедал” эту неэффективность — делать новые онлайн-сервисы было до того выгодно, что даже даже наличие половины штата…не самых профессиональных людей не мешало рубить бабло и растить капитализацию, но эти времена заканчиваются, во первых, так как конкуренция обострилась настолько что неэффективные компании просто начинают выживать с привычных рынков, а новых ниш-то уже и не осталось почти, а, во-вторых, с нами теперь ИИ…но об этом попозже.
Кого надо нанимать?
Вовлеченных ребят.
Про вовлеченность писал тут. Это самое важное. Пробелы в хардах можно прокачать. Проблемы с коммуникацией сложнее, но тоже можно качать или использовать человека по-другому. А вот если человеку работать не хочется и на цели и результат похер, то…можно попробовать разжечь огонь в глазах, но, по опыту, вероятность успеха невелика.
Как выбирать?
Лично я обращаю внимание на достижения кандидата, т. е. резюме в стиле “я просто работал работу” не впечатляют, но с другой стороны, во-первых, писать про достижения это уже известный паттерн и кандидаты уже начали иногда приписывать себе чужие и общие достижения, и высасывать из пальца эти самые достижения, а, во-вторых, полно хороших ребят, которые просто не очень поднаторели в составлении резюме.
Хорошо когда люди отмечают профит для пользователя и бизнеса от их стараний, а не просто сложность и объем задачи.
Если есть возможность не отказывайте сразу людям, у которых не очень впечатляющее резюме — пусть сходят на скрининг.
Интервьюирование
Этапы
Думаю, в индустрии уже есть некоторая траектория, вдоль которой все двигаются с небольшими отклонениями, это что-то вроде:
- скрининг;
- 1-3 (иногда больше) техинтервью;
- финал с нанимающим менеджером и, возможно, HR.
Я только напомню что собес это, чаще всего, раздражающая сущность для всех участников процесса, так что чем меньше этапов тем лучше.
Что спрашивать?
Часть кандидатов уже заучили ответы на устоявшиеся вопросы, и хардовые и софтовые, даже если не понимают сути — давайте больше практических задач и вопросов без правильного ответа, на рассуждение, где важен ход мыслей, а не результат. Используйте ИИ как помощника и справочную систему. Не копируйте задания и вопросы у больших компаний, даже лучших — удивитесь насколько быстро они растекаются по интернету. Не используйте пул вопросов и задач как часть вашего процесса — все утечет (допустимо для скрининга), хоть и не сразу — юзайте ИИ для подготовки, можно использовать стандартные промпты для того, чтобы генерировать наборы вопросов и задач нужной сложности.
Интервью в эпоху ИИ
Начнём с того, что у разработчиков всегда был этап, на котором нужно было писать код. Постепенно этот этап теряет актуальность, как и в целом необходимость писать код самому, разбираться всё равно нужно, но код все больше пишет ИИ, а инженер этот код проверяет. И вот навык писать правильные промпты для ИИ и навык ревью теперь выглядят более важными.
Эффективный способ решить задачу на разработку какого либо функционала теперь скорее такой:
- придумать решение с точки зрения логики работы функциональности, спроектировать архитектурно, описать всё это;
- доописать что ещё нужно добавить (тесты, фикстуры и т. п.);
- превратить описание в промпт и скормить ИИ;
- контролировать работу ИИ и проверить результат.
Имея ввиду такой сценарий, можно и интервью совсем по другому спроектировать и провести.
Для других инженерных профессий, вроде, DevOps-инженера, вероятно, это плюс-минус тоже актуально, но я не пробовал.
Для менеджеров сложнее — их работу ИИ пока не делает, но выступает помощником-консультантом. Пока предлагаю просто проверять навыки взаимодействия с ИИ именно в сценарии “руководитель — помощник”, в остальном оставить всё как и раньше было.
А нужны ли разработчики уровня джуна и мидла, если у нас есть ИИ?
Да, если они вовлечённые. Основной боевой единицей становятся сеньоры, но нужно же растить новых. Свои доморощенные чаще всего оказываются лучше вновь нанятых.
ИИ заменит рекрутеров?
Думаю, да. Постепенно, но на 100%. При всём уважении к этим специалистам.
Пример процесса найма (без деталей)
1. Формирование вакансии
Силами нанимающего менеджера (далее НМ) с помощью ИИ-помощника, публикация на всяких hh и прочих linkedin, хоть руками, хоть при помощи агента.
2. Поиск
Рекрутер — ИИ агент. Находит подходящих кандидатов и предлагает их НМ, показывает НМ откликнувшихся.
3. Скрининг
Только ИИ, задаёт вопросы из пула, сохраняет ответы, делает саммари, отправляет всё НМ.
4. Техничка
Я бы пока ИИ сюда не пускал. Один большой этап: решение большой задачи, для инженеров и тимлидов — с кодом, для ЕМ и выше — без кода, при помощи ИИ.
5. Финал с НМ
6. Если всё ок, то наём человека в штат и закрытие вакансии
Немного итогов
ИИ сильно меняет работу современных IT-компаний. Но в сущности пока всё остаётся как и было. Индустрию двигают умные мотивированные люди, используя всю мощь современных технологий. Не забывайте об этом.
