Привет, этим постом мы хотим вызвать тимлидов на разговор. А точнее, запустить проект “ТимлидПозвонит”, в котором раз в две-три недели наши Петр anotherpit, Кирилл flashhhh и Артем arasskosov будут звонить интересному гостю через Google Meet и общаться на наболевшую тему.
В первом выпуске мы поговорили о трудностях найма с Антоном Губаревым, который пять лет руководит техническими командами на удаленке и ведет свой телеграм-канал о том, каково это. Ниже вы найдете текстовую выжимку, а также полную аудио и ютуб-версию разговора.
1. Я собеседовал вслепую
Антон: Прошло немало времени, прежде чем я стал использовать видео при собеседовании. Общаясь с другими компаниями, знаю, что многие так и продолжают созваниваться без видео, может быть, даже просто по телефону. Видео — это на самом деле очень важно. Общаясь с глазу на глаз, ты лучше видишь эмоции человека, что он думает, — ведь на лице это отображается.
Проводя собеседование, мы обязательно используем видео: естественно, собеседуемый предупреждается об этом, а запись остается только у нас. Ее могут пересматривать другие тимлиды: например, если человек не подошел в одну команду, но может подойти в другую, не нужно будет дергать его еще раз, чтобы он повторил примерно то же. Тимлид другой команды посмотрит видео и решит, звать ли человека на предметный разговор. Например, один из разработчиков, seregazhuk, попал в компанию именно так.
2. (Не)насильственно делегировал
Кому-то нравится не только писать код, а решать всю бизнес-задачу до упора. Что делать с разработчиками, которые реально хотят исключительно программировать, а заниматься продуктом не хотят совсем, если честно, мы не знаем (но будем рады созвониться и обсудить — пишите).
Антон: Основная задача тимлида — cделать команду, которая может “ехать” без него. Без человека, которому можно делегировать, ничего не получится. На первых этапах я, скажем так, учился на своих ошибках. Когда уходил в отпуск или что-то еще случалось, работа практически вставала или производительность опускалась в разы. Поэтому я стал со временем пытаться делать из одного сотрудника того, кто сможет меня заменить: но этот человек был не готов, не имел склонности… Или вот буквально сегодня собеседовал человека. Он очень удивленно на меня смотрел, когда я задавал вопросы про менеджерские функции, про влияние на продукт: “Типа, зачем? Есть же тимлид, который может всем этим заниматься”.
В какой-то степени, в продуктовой компании от разработчиков ждут и желания участвовать в жизни продукта: так человек будет полезнее для своей команды, да и тимлид в случае ЧП может не успеть заниматься всем. Соответственно, в каждом собеседовании мы стараемся обращать внимание на то, как человека относится к менеджерским функциям: какие проблемы решал на прошлом месте, ставил ли сам задачи, общался ли с бизнесом, проводил ли код-ревью и т.д. Из этого можно сделать вывод, кого можно аккуратно подводить к делегированию, но если только он сам будет просить “дай мне”— тогда пожалуйста.
3. Составлял впечатление о полезности человека по visibility (или его отсутствию)
Когда к вам приходит разработчик, возможно, вы увидите его GitHub, на котором два заброшенных проекта от 2015 года — test-task_1 и test-task_2. А, возможно, информации будет так много, что можно будет сидеть и читать статьи, код или доклады человека часами. Но нужно ли все это?
Кирилл: Когда у меня есть пул из нескольких разработчиков, я, в первую очередь, захочу поговорить с кем-то, у кого был секси гитхаб-профайл, либо с тем, кто написал статью, которая не была отвратительной. Потому что подумаю: “Да, наверно, ему интересно то, что он делает”. Хотят я часто работал с людьми, которые вообще не писали статьи, не выступали и о них ничего не было в интернете.
Мы не выявили никакой корреляции между публичностью и качеством работы человека. Он может быть талантливым разработчиком, который просто не любит писать опенсорс, не имеет времени на проект — или “пилит” его, но держит в приватном репозитории (может быть, у него их там даже три).
4. Прогугливал человека
Антон: Когда я занимался фрилансом, то часто нанимал таких же фрилансеров — и там я гуглил, чтобы найти отзывы нехорошие. Это было оправданно и применимо. Когда ты работаешь в компании, то так не делаешь. Я не собираю какие-то персональные данные — не копаюсь, с кем он дружит, куда он ходит, фотки его тоже не разглядываю.
А вот блоги, личные сайты, телеграм-каналы, комментарии или посты на Хабре, если человек приложил их — это часто интересно. Читая, о чем пишет человек, я пойму, как он относится к хайповым технологиями, как относится к легаси-коду. Наконец, пойму, как он вольется в нашу команду. Натыкался на одного человека, у него был блог: там было много политики, мата и всего этого. Понятно, что человек, так скажем, эмоциональный. Соответственно, это нужно учитывать: если у тебя в команде трое спокойные, а кто-то новый на дейликах будет все время поднимать бучу, это скажется на команде.
Количество информации о человеке в интернете никак не повлияет на его найм: по ней нельзя сделать какой-то окончательный вывод. Но она поможет понять, что стоит уточнить на собеседовании. Перед каждым собеседованием тимлид может потратить 20-30 минут, чтобы составить индивидуальные вопросы под каждого кандидата — они дополняют стандартный список того, что его интересует в разработчике. Иногда это просто помогает найти контакт: если человек занимается аквариумными рыбками, можно начать разговор с этого — и через 5 минут человек становится менее напряженным, более открытым, а разговор идет эффективнее.
5. “Так, у нас сегодня один-на-один, давай, садись, будем разговаривать"
У всех есть проблемы. Это нормально. Для этого и придумали 1-to-1. Не все хотят чем-то делиться — но то, что у человека нет предложений или его всегда “все устраивает”, может служить сильным индикатором здоровья. При этом иногда человек может думать «я тут сижу код пишу, сейчас поперло, не хочу говорить непонятно о чем прямо сейчас». Тут формат встреч, прибитых к полу, не подойдет.
Петр: У меня все встречи по календарю, я такой: “Так, встреча по календарю, встречаемся”. У человека есть возможность высказаться про то, что наболело, а он такой: “Да-да-да, всё нормально, слушай, там задачка горит, давай лучше задачку пообсуждаем”. В итоге, один случай из десяти заканчивается полноценным разговором по душам: к ним относятся как к полуобязаловке, но какой-то момент выстреливает, просто потому что ты регулярно опрашиваешь. То есть, разговор десять раз занял пять минут, зато одиннадцатый занял два часа и это было нужно. У меня вопрос: как, если сделать встречи нерегулярными, не пропустить момент, когда человеку надо выговориться — ведь он сам это не инициирует".
Многие команды у на сегодня приходят к плавающим графикам встреч. То есть, у людей есть понимание, по какому циклу они идут — например, это неделя, — конкретная дата и время обсуждаются в Slack. Иногда встреча спонтанна: появляется повод, ты сразу пишешь “давай созвонимся, сейчас наберу”. Это, в частности, помогает не надумывать проблемы по принципу “вроде собрались, давайте что-нибудь обсудим”. Если встречи в команде проводятся раз в пару недель или месяц, то дня за 3-4 тимлид предлагает тайм-слоты: «Давай обсудим все, что за месяц произошло».
p.s. Спасибо всем, кто почитал. Будем рады пообщаться на наболевшие темы — пишите в личку или телеграм, и тимлид позвонит)
p.p.s. В полной версии беседы:
Аудио на Soundcloud
- Кажется, мы наняли всех фуллстеков в мире. Что делать?
- Как жить, если тебе нужно отделить фронтенд от бэкенда, а заказчик хочет задачу вчера?
- «Я попробовал, мне не понравилось» или интересное из резюме
Автор: antaresalex
