Я работаю руководителем отдела бекенда в Яндекс 360. Мы создаём виртуальный офис, в который входят Почта, Диск, Документы, Телемост, Календарь, Заметки, Мессенджер, Рассылки,Трекер, Вики и Формы. Раньше эти продукты существовали по отдельности (буквально в тихой гавани с размеренным развитием), но в 2020 году их объединили в экосистему Яндекс 360. А крупные компании начали переезжать к нам.

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

Далеко не все старшие разработчики в нашей команде готовы становиться тимлидами, а младшие ещё не доросли, и нужно нанимать с рынка. Но как нанять такого тимлида, который поможет нам развивать команду, растить инженеров и вольётся в нашу культуру? Как понять, что он не поломает нам команду? Что впишется в нашу культуру? Кто такой вообще этот тимлид? Что он должен делать?

Кажется, нам удалось вывести для себя формулу найма тимлидов.

В докладе подробно расскажу:

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

Небольшой дисклэймер:
- В докладе я буду говорить о найме линейных руководителей, т.е. тимлидов, у которых прямом подчинении 5-7 разработчиков или QA. Найм руководителей среднего звена немного отличается, хотя многие подходы могут быть применимы и для этого;
- Доклад не является универсальной методологией найма тимлидов, это просто опыт нашей компании;
- Я буду больше фокусироваться на построении процесса найма, а не найме одного или двух тимлидов.