Как я нанимаю людей — meamka.me

Как я нанимаю людей

written by Andrey Maksimov on 2022-06-13

За последние 6 лет моя работа во многом состояла в том, чтобы найти подходящих людей в свою команду и за это время я выработал набор вопросов и маркеров, которые помогают мне довольно просто определить подойдёт ли кандидат либо нет. Условно эти маркеры можно разделить на несколько пунктов:

  • Работа с командой: я не создаю команды одиночек, я собираю эффективные команды, которые могут решать поставленные задачи. Каждый участник команды должен уметь общаться и при этом не переходить на конфликты, разногласия случаются у всех, но их нужно решать мирно;
  • Умение доносить свои мысли: работа в команде над одним проектом подразумевает много общения и умение объяснять свои идеи, задавать правильные вопросы является критичным;
  • Умение доводить дела до конца: любая задача несёт ценность только будучи завершённой, читай “доступна пользователям”;
  • Вовлечённость, заинтересованность: я не хочу воспитывать каждого, мне в команде нужны люди которым интересно то, чем они занимаются, они сами изучают язык/фреймворк/базу данных/иные смежные технологии, чтобы сделать свои проекты лучшими на рынке;

Работа с командой

Коммуникативность — является обязательным навыком при работе в команде, так как хорошая команда сама решает вопросы внутри и при этом обсуждения не переходят в конфликт. Но чем хорошая команда отличается от отличной? Как минимум она открыта к обсуждения не только внутри, но и с внешними заказчикамии/исполнителями. Неважно, будь то новая продуктовая функция, которая кажется переусложнённой и это нужно объяснить заказчику, или API который реализовала команда бэкенда кажется вам примитивным и не учитывает нужды вашей мобильной команды. (Команды это выдумка, %username%). Все участники такой команды открыты к обсуждениям, они умеют дискутировать и сами расскажут другим участникам о том, что им кажется важным.

Чтобы узнать об этом качестве, попробуйте расспросить кандидата о том, какова была его роль в команде? Кто ставил ему задачи? Участвовал ли он в оценке задач, приходилось ли ему объяснять заказчикам или исполнителям, что и почему нужно сделать, или наоборот, сделать нельзя?

Умение доносить свои мысли

Вам может показаться, что этот пункт буквально повторяет предыдущий, но позвольте мне развеять ваши сомнения. Несмотря на явную связь — невозможно объяснить что-то, если вы сразу переходите на крик — здесь важно понять, насколько кандидат может донести до собеседника свои идеи, работает ли он с обратной связью, убеждается ли, что его собеседник понял мысль максимально близко. Например, перед сотрудником стоит задача для решения которой ему нужно поставить задачу другому разработчику. Он описывает её в JIRA, назначает исполнителя и… всё. Считает, что задача сделана. Он даже может попытаться объяснить её в чате или созвонившись, но он забывает ключевой момент: убедиться в том, действительно ли задача понята так, как она стоит? Или же, понимание далеко от изначальной цели.

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

Если же мы говорим про разработчиков начального уровня, то они, как правило, не ставят задачи, а являются конечными исполнителями, однако, даже они должны доносить свои мысли до коллег и тимлидов. Можно расспросить их о том, что они делали в случае, если задачи были непонятны? Успешно ли уточняли требования?

Умение доводить дела до конца

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

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

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

Как узнать об этом на собеседовании? Задавайте вопросы связанные с любыми завершёнными задачами. Узнайте, есть ли у человека свои pet-проекты? Возможно, он развивал какой-то внутренний проект в компании где работал? Может быть проект друзей, где он помогал с какой-то частью? Это не обязательно должна быть разработка, ведь здесь вам важны не качества программиста, а целеустремлённость.

Вовлечённость, заинтересованность

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

Как узнать об этом? Расспросите о том, что нового изучил кандидат в течение полугода/года; почему он это изучал? Как он узнаёт о новинках в своей области? Спросите, что он изменил в работе своей предыдущей компании, в рамках своей работы или отдела?

Вопросы

Это лишь примеры вопросов, вы можете корректировать их под вашу команду.

Работа с командой

  • Какова была ваша роль в работе команды?
  • Приходилось ли вам объяснять, почему задача потребует больше времени?
  • Ставили ли вы задачи другим людям в компании?

Умение доносить свои мысли

  • Были ли моменты, которые вам не нравились? Как вы пытались их решить?

Умение доводить дела до конца

  • Есть ли у вас открытые проекты на GitHub/Gitlab? Какие проблемы они решают?
  • Какие продукты вы создали или хотели бы создать? Это может быт все что угодно: приложение, книга, блог, музыка и др.

Вовлечённость

  • Что из недавнего вы изучили или прочитали?
  • Как узнаёте о новинках технологий?

Как этим пользоваться

Что ж, у вас есть два варианта:

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