В резюме не должно быть частой смены работы, или О требованиях тимлида к разработчикам. Интервью с Дмитрием Матвеевым, Evrone

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

Дмитрий Дементий: Расскажите, пожалуйста, о себе. Кто вы и чем занимаетесь?

Дмитрий Матвеев: В разработке с 2008 года. Преподавал в университете прикладную информатику, программирование на C++ и C#. Потом ушел в коммерческую веб-разработку. Начал с PHP, а в 2008 году перешел на Ruby On Rails.

С 2012 года работаю тимлидом. Делал проекты на аутсорсе. Собрал команду, в которой есть как опытные разработчики, так и джуниоры. В том числе есть опыт привлечения в проект студентов.

С 2015 года сотрудничаю с Evrone. Летом преподаю в IT Лаборатории (проект пензенского IT сообщества).

Д.Д.: Какой стек технологий использует в работе ваша команда?

Д.М.: Разрабатываем на Ruby on Rails.

Кто такой тимлид и как он работает

Д.Д.: Вопрос, ответ на который нужен начинающим специалистам: кто такой тимлид, чем он занимается?

Д.М.: В команде может быть тимлид и проектный менеджер (проджект-менеджер). Роль этих специалистов варьирует в зависимости от организации процессов в конкретной компании.

Если обобщить, тимлид — человек, который может сам написать код, сделать что-то в проекте руками. Но при этом он еще и занимается менеджментом. Проджект не пишет код, эта позиция — чистый менеджмент.

Тимлид — драйвер команды. Он склеивает коллектив, контактирует с внешним миром, например, с заказчиками. То есть этот специалист должен быть хорошо подготовлен технически, иметь сильные хард-скиллы. Также для тимлида важны софт-скиллы, которые нужны для эффективного взаимодействия с членами команды и внешним миром.

Д.Д.: Как тимлид взаимодействует с командой в целом и отдельными участниками в процессе разработки? Можно буквально несколько зарисовок рабочего процесса сделать, это очень интересно людям без опыта.

Д.М.: Попробую описать процесс на примере рабочего дня. С моей точки зрения, краеугольный камень эффективности тимлида и команды в целом — daily meeting или ежедневный созвон. Во время митинга тимлид и участники команды синхронизируются. Это элемент организации процессов.

Следующий важный этап работы тимлида в течение дня — анализ задач. Он общается по каждой задаче с business owner. Это может быть заказчик или представитель заказчика. на этом этапе тимлиду нужно проработать путь решения задачи с учётом интересов бизнеса.

Тимлид видит картину в целом, интегрирует процессы, смотрит на задачи и пути их решения с точки зрения бизнеса.

В течение дня тимлид помогает разработчикам решать их текущие задачи. Речь идёт о рабочих вопросах по коду. Условно говоря, когда джуниор не может что-то сделать, в игру вступает лидер команды. Он помогает новичку сделать так, чтобы тесты позеленели (и чтобы тесты в принципе появились :). Можно сказать, что тимлид играет роль той самой уточки, после общения с которой разработчик находит способы решения задачи.

Если обобщить, лидер планирует работу команды на несколько шагов вперёд, отвечает на вопросы «почему сделать» и «как сделать».

Какую роль играет тимлид в найме и адаптации сотрудников

Д.Д.: Какова роль тимлида в найме сотрудников? Чем он занимается: рекрутинг, собеседования, онбординг новичков? Если в компании есть HR, как тимлид с ним взаимодействует?

Д.М.: Роль в найме зависит от конкретной компании. В идеале тимлид активно участвует в поиске, отборе и адаптации новичков. Более того, он планирует усиление команды, даёт заказ на поиск новых специалистов, когда понимает, что новички нужны для решения задач.

Если в компании есть HR, он проводит первичную фильтрацию кандидатов. Если эйчара нет, первичный отбор берёт на себя тимлид. Кандидат встречается с тимлидом на втором или даже на первом собеседовании.

Интеграция новичков в команду — прямая обязанность лидера команды. Но тимлид может частично делегировать эту задачу кому-то из опытных сотрудников. В этом случае он следит за процессом и при необходимости подключается.

Д.Д.: Как тимлид планирует работу команды? Планирование происходит сверху (вы говорите, что Джон на этой неделе делает то и это, а Джек это и то) или снизу (Джон и Джек предлагают план, а вы контролируете)?

Д.М.: Иногда тимлид распределяет роли и задачи, хоть это и противоречит scrum. Это происходит, когда такое распределение очевидно и не вызывает значимых конфликтов в коллективе. Но в основном участники команды, включая начинающих разработчиков, сами определяют приоритетные задачи и распределяют роли.

Д.Д.: О контроле: как тимлид контролирует рядовых разработчиков? Выполненные задачи, качество кода, другие аспекты.

Д.М.: Сразу выскажу свою позицию: контроль рабочего стола считаю нонсенсом, деструктивной практикой. Это стресс для сотрудников и иллюзия контроля для руководителей. Такой контроль расслабляет работодателя, а сообразительные люди быстро находят способы его обходить. А программисты — сообразительные люди.

Тимлиду важен результат. То есть сотрудник может сидеть в соцсетях во время обеденного перерыва, если он выполняет поставленные задачи.

Если нет результата, нужно думать. Как я уже отмечал, важную роль в работе тимлида, в том числе с точки зрения контроля разработчиков, играет ежедневный созвон. Предпочитаю созваниваться с видео, это позволяет понять, всё ли в порядке с человеком, как он выглядит.

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

В исключительных случаях можно идти навстречу сотруднику. Например, если разработчик живёт во Владивостоке, разницу во времени можно и нужно учитывать.

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

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

Д.Д.: Должен ли тимлид заботиться о росте сотрудников? Например, есть в команде джуниоры. Они должны учиться и прогрессировать. Этот процесс должен идти снизу (от джунов) или сверху (от тимлида)?

Д.М.: Если сотрудник не прогрессирует, виноват тимлид. Это аксиома. Развитие разработчиков — зона прямой ответственности лидера команды. Важно понимать, что необходимо обоюдной желание развиваться. Если у сотрудника такого желания нет, тимлид не поможет.

Что тимлид хочет от кандидатов на позицию джуниора

Д.Д.: Вернёмся к найму. Вам нужны разработчики. Какие требования вы предъявляете к кандидатам? Понятно, что это сильно зависит от проекта, но можно попробовать обобщить.

Д.М.: Сначала отвлекусь, чтобы объяснить свою позицию. Я считаю, что реализованные проекты делают человека разработчиком уровня middle. У миддлов есть баланс качеств. С одной стороны, это самостоятельные разработчики. Они могут решать задачи сами. Разработчик уровня junior пока не стал самостоятельной рабочей единицей.

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

И о разработчиков уровня senior. Я их определяю так: если человек умнее меня, он senior :)

Теперь о требованиях. В резюме не должно быть частой смены работы, это настораживает. Когда человек адаптируется в команде, компания инвестирует в него. Только спустя несколько недель или месяцев специалист приносит компании реальную пользу. Поэтому работодатель всегда заинтересован в долгосрочном сотрудничестве.

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

Резюме должно быть понятным и логичным, но при этом в нём должны быть технические детали.

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

1. беседы на технические темы;
2. тестового задания;
3. совместного написание кода (live coding).

Несколько лет назад я проводил собеседование и потом просил выполнить тестовое задание. Если у кандидата есть коммиты в open source проект, код из которого он может показать — это облегчает задачу с обеих сторон, и тогда в тестовом задании нет необходимости. Если человек нужен срочно, и на длительный формальный процесс найма нет времени, тогда я просто беседую и пытаюсь понять, какие задачи решал и может решить человек. Как пример золотой середины могу привести пример, как это сделано у нас в Evrone: на собеседовании дают небольшое и интересное задание, которое можно сделать за 15 минут, а уже по нему удобно смотреть, как человек мыслит и как привык писать код.

Д.Д.: Какие хард-скиллы должны быть у специалиста, чтобы он мог всерьёз претендовать на позицию джуниора? Что нужно уметь?

Д.М.: Нужны базовые знания языка и фреймворка, понимание общих принципов DRY и SOLID. Хотя сейчас и принято ругать ООП, но такой такой подход я считаю несколько инфантильным. На практике знание ООП очень важно. А если добавить к нему понимание функционального программирования, то, наверное, мы говорим уже не о джуниоре, а о состоявшемся и крутом специалисте.

Очень важно уметь и, главное, любить писать тесты. Хорошо, если есть минимальные знания менеджмента. И, особенно для веб-программирования, нужно знать принципы работы баз данных, понимать, как работают индексы. Перечисленного достаточно, чтобы начать работать джуниор разработчиком.

Д.Д.: Аналогичный вопрос по софт-скиллз. Какие нужны софт-скиллы и как их оцениваете?

Д.М.: Человек должен быть адекватным в целом, иметь здравый смысл, не делать фигню. Предполагается, что успешный джун должен понимать и оценивать задачи. Важно, чтобы человек умел задавать вопросы, выбирать приоритеты.

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

Полезно читать книги, в том числе художественную литературу.

Важный софт-скилл — умение слушать. Ещё человек должен уметь адекватно конфликтовать и договариваться. Под способностью адекватно конфликтовать подразумевается умение отстаивать свою позицию, аргументированно доказывать что-то другим разработчикам и руководителю.

Д.Д.: Важные вопросы: пол и возраст. Я слышал, что на Западе есть мода не указывать пол и возраст, чтобы не было дискриминации по этим параметрам. И работодатели, и кандидаты к этому пришли. Как у нас обстоит дело? Есть ли шанс у кандидата 30, 35, 45 лет попасть на позицию джуниора? Есть ли красная черта возрастная? Например, в 34 берём человека, а в 34 и 6 месяцев не берём?

Д.М.: Барьеров по полу и возрасту нет. По полу ответ короткий — здесь никаких проблем нет. О возрасте можно порассуждать.

У молодых и возрастных сотрудников есть преимущества и недостатки. Плюсы молодого специалиста: он готов к сверхурочной работе, энергичен. В то же время уже к условным 23 годам у него может быть солидный опыт за плечами. Например, человек с первого или второго курса университета где-то работает, получает опыт в реальном проекте.

Недостаток молодого специалиста — низкая стрессоустойчивость, эмоциональность. С ним приходится аккуратно общаться.

Преимущества возрастных специалистов: у них за плечами есть жизненный и профессиональный опыт. Эти люди стрессоустойчивы, они знают, чего хотят. Возрастные специалисты надежны, обычно они работают в компании долго.

Недостатком можно назвать меньшую по сравнению с молодежью энергичность, отсутствие желания и возможности совершать «подвиги» на работе. Хотя я считаю, что необходимость в подвигах — это всегда неудача менеджера.

И самое главное — у возрастных людей меньше времени остается на учёбу и профессиональное развитие. После работы им нужно провести время с семьей, пообщаться с детьми, а не изучать новый модный JS-фреймворк. Поэтому здесь на первый план выходит эффективный тайм-менеджмент.

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

Д.Д.: Практикуете ли вы испытательный срок? Если да, на что обращаете внимание во время испытательного срока новичка?

Д.М.: Испытательный срок — очень важный инструмент. Это как вопрос гигиены, без него нельзя. Во время испытательного периода обычно выявляются нюансы, которые невозможно отследить и понять ни на одном собеседовании. Бывает так, что люди просто не могут работать вместе в одной команде.

Нормальная продолжительность испытательного срока — от месяца до трёх. Простой критерий: если человек приносит команде (то есть бизнесу) пользу, то можно брать взаимную ответственность и договариваться на длительные рабочие отношения.

Д.Д.: Что должен сделать джун, чтобы наверняка не пройти испытательный срок? Здесь не о крайностях типа прогулов или пьяных дебошей на работе, а о рабочих ситуациях. Как вы понимаете, что этот человек не подходит, хоть и старается? И как это понять человеку?

Д.М.: Человек не проходит испытательный срок, если регулярно не выполняет поставленные задачи. Если такая ситуация происходит один раз, это нормально. В крайнем случае передаю задачу другому специалисту. Но если ситуация систематически повторяется, то такой боец пока не готов к длительному сотрудничеству с нами.

Заключение: об идеальной системе обучения и профессиональном росте

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

Д.М.: Идеальной системы обучения нет. В работе и в обучении важна самостоятельность. Специалист должен понимать, что его код будет поддерживать он сам или другие разработчики. Важно читать книги, например, Фаулера. Не бояться код-ревью, учиться читать чужой код.

Д.Д.: Что нужно делать новичку, чтобы профессионально расти и продвигаться по карьерной лестнице? Стать тимлидом, например? Что учить, как и где работать?

Д.М.: Важно понимать, зачем нужен рост. Позиция тимлида подходит не всем. Если обобщить, разработчик может идти по пути развития хард-скиллз. Тогда он растёт в сторону senior и «архитектора». Второе направление — развитие софт-скиллз. Это развитие в сторону тимлида, менеджера.

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

Д.Д.: Дмитрий, спасибо за интересную беседу!

Д.М.: Читателям всего хорошего!

Оригинал интервью опубликован в блоге «Хекслета».