php team lead резюме
В резюме не должно быть частой смены работы, или О требованиях тимлида к разработчикам. Интервью с Дмитрием Матвеевым, 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, он определяет общую адекватность человека и его мотивацию. Если потенциальный новичок проходит первичный отбор, тимлид оценивает его пригодность к работе с реальными задачами. В разных компаниях процесс собеседований может сильно отличаться, но если обобщить, то это будет микс из:
Несколько лет назад я проводил собеседование и потом просил выполнить тестовое задание. Если у кандидата есть коммиты в open source проект, код из которого он может показать — это облегчает задачу с обеих сторон, и тогда в тестовом задании нет необходимости. Если человек нужен срочно, и на длительный формальный процесс найма нет времени, тогда я просто беседую и пытаюсь понять, какие задачи решал и может решить человек. Как пример золотой середины могу привести пример, как это сделано у нас в Evrone: на собеседовании дают небольшое и интересное задание, которое можно сделать за 15 минут, а уже по нему удобно смотреть, как человек мыслит и как привык писать код.
Д.Д.: Какие хард-скиллы должны быть у специалиста, чтобы он мог всерьёз претендовать на позицию джуниора? Что нужно уметь?
Д.М.: Нужны базовые знания языка и фреймворка, понимание общих принципов DRY и SOLID. Хотя сейчас и принято ругать ООП, но такой такой подход я считаю несколько инфантильным. На практике знание ООП очень важно. А если добавить к нему понимание функционального программирования, то, наверное, мы говорим уже не о джуниоре, а о состоявшемся и крутом специалисте.
Очень важно уметь и, главное, любить писать тесты. Хорошо, если есть минимальные знания менеджмента. И, особенно для веб-программирования, нужно знать принципы работы баз данных, понимать, как работают индексы. Перечисленного достаточно, чтобы начать работать джуниор разработчиком.
Д.Д.: Аналогичный вопрос по софт-скиллз. Какие нужны софт-скиллы и как их оцениваете?
Д.М.: Человек должен быть адекватным в целом, иметь здравый смысл, не делать фигню. Предполагается, что успешный джун должен понимать и оценивать задачи. Важно, чтобы человек умел задавать вопросы, выбирать приоритеты.
Начинающий разработчик должен уметь выражать свои мысли. Поэтому всем полезно читать книги, в том числе художественную литературу.
Полезно читать книги, в том числе художественную литературу.
Важный софт-скилл — умение слушать. Ещё человек должен уметь адекватно конфликтовать и договариваться. Под способностью адекватно конфликтовать подразумевается умение отстаивать свою позицию, аргументированно доказывать что-то другим разработчикам и руководителю.
Д.Д.: Важные вопросы: пол и возраст. Я слышал, что на Западе есть мода не указывать пол и возраст, чтобы не было дискриминации по этим параметрам. И работодатели, и кандидаты к этому пришли. Как у нас обстоит дело? Есть ли шанс у кандидата 30, 35, 45 лет попасть на позицию джуниора? Есть ли красная черта возрастная? Например, в 34 берём человека, а в 34 и 6 месяцев не берём?
Д.М.: Барьеров по полу и возрасту нет. По полу ответ короткий — здесь никаких проблем нет. О возрасте можно порассуждать.
У молодых и возрастных сотрудников есть преимущества и недостатки. Плюсы молодого специалиста: он готов к сверхурочной работе, энергичен. В то же время уже к условным 23 годам у него может быть солидный опыт за плечами. Например, человек с первого или второго курса университета где-то работает, получает опыт в реальном проекте.
Недостаток молодого специалиста — низкая стрессоустойчивость, эмоциональность. С ним приходится аккуратно общаться.
Преимущества возрастных специалистов: у них за плечами есть жизненный и профессиональный опыт. Эти люди стрессоустойчивы, они знают, чего хотят. Возрастные специалисты надежны, обычно они работают в компании долго.
Недостатком можно назвать меньшую по сравнению с молодежью энергичность, отсутствие желания и возможности совершать «подвиги» на работе. Хотя я считаю, что необходимость в подвигах — это всегда неудача менеджера.
И самое главное — у возрастных людей меньше времени остается на учёбу и профессиональное развитие. После работы им нужно провести время с семьей, пообщаться с детьми, а не изучать новый модный JS-фреймворк. Поэтому здесь на первый план выходит эффективный тайм-менеджмент.
Однако всё вышеперечисленное достаточно условно. В любом возрасте человек может работать продуктивно и достигать успехов, главное — наличие желания и воли.
Д.Д.: Практикуете ли вы испытательный срок? Если да, на что обращаете внимание во время испытательного срока новичка?
Д.М.: Испытательный срок — очень важный инструмент. Это как вопрос гигиены, без него нельзя. Во время испытательного периода обычно выявляются нюансы, которые невозможно отследить и понять ни на одном собеседовании. Бывает так, что люди просто не могут работать вместе в одной команде.
Нормальная продолжительность испытательного срока — от месяца до трёх. Простой критерий: если человек приносит команде (то есть бизнесу) пользу, то можно брать взаимную ответственность и договариваться на длительные рабочие отношения.
Д.Д.: Что должен сделать джун, чтобы наверняка не пройти испытательный срок? Здесь не о крайностях типа прогулов или пьяных дебошей на работе, а о рабочих ситуациях. Как вы понимаете, что этот человек не подходит, хоть и старается? И как это понять человеку?
Д.М.: Человек не проходит испытательный срок, если регулярно не выполняет поставленные задачи. Если такая ситуация происходит один раз, это нормально. В крайнем случае передаю задачу другому специалисту. Но если ситуация систематически повторяется, то такой боец пока не готов к длительному сотрудничеству с нами.
Заключение: об идеальной системе обучения и профессиональном росте
Д.Д.: По вашему мнению, как выглядит идеальная система обучения программиста? Как и что надо изучать, чтобы стать хорошим специалистом?
Д.М.: Идеальной системы обучения нет. В работе и в обучении важна самостоятельность. Специалист должен понимать, что его код будет поддерживать он сам или другие разработчики. Важно читать книги, например, Фаулера. Не бояться код-ревью, учиться читать чужой код.
Д.Д.: Что нужно делать новичку, чтобы профессионально расти и продвигаться по карьерной лестнице? Стать тимлидом, например? Что учить, как и где работать?
Д.М.: Важно понимать, зачем нужен рост. Позиция тимлида подходит не всем. Если обобщить, разработчик может идти по пути развития хард-скиллз. Тогда он растёт в сторону senior и «архитектора». Второе направление — развитие софт-скиллз. Это развитие в сторону тимлида, менеджера.
Тимлид жертвует программированием в пользу общения. Это экстраверт или интроверт, желающий стать экстравертом. Тимлид отвечает за себя и за того парня. Учитывайте это, когда планируете своё развитие.
Д.Д.: Дмитрий, спасибо за интересную беседу!
Как помочь работодателю выбрать ваше резюме. Советы тимлида
Алекс Кондрашов, Team Lead and Engineering Manager в EY, в своей статье на DOU.UA дал ряд советов, как составить резюме таким образом, чтобы оно привлекло внимание работодателя.
Я работаю программистом и выполняю роль тимлида в своей команде. Также участвую в найме других разработчиков в компании. За последний год я помог нанять 15 специалистов и провел более 45 собеседований. Самое сложное в отборе кандидатов — найти достойные резюме. Из 10 я выбирал только 3. Почему-то специалисты совершают одни и те же ошибки в структуре резюме. Не рассказывают про свои навыки по существу и пишут много ненужного. Рассказываю, что должно быть в резюме, чтобы работодатель обратил на него внимание.
Общие рекомендации
Если вы хорошо знаете Front-end и Data Science, можете подаваться на две позиции. Для этого нужно два резюме, которые будете отправлять в зависимости от желаемой роли. Каждое должно содержать релевантный опыт. Так работодателю будет проще найти резюме и вы увеличите свои шансы в два раза.
Например, Alex Kondrashov хочет работать фронтенд-разработчиком. Одно резюме с нерелевантным опытом для Front-end:
Resume — Alex Kondrashov.pdf
Work Experience:
2020 — Front-end Developer
2019 — Data Scientist & Python Developer
2018 — Full Stack Developer
2017 — Back-end Developer
2016 — Embedded Engineer
2015 — English teacher
2014 — Baywatch lifeguard
Два резюме с релевантным опытом для Front-end Developer и Data Scientist:
Resume — Alex Kondrashov — Front-end Developer.pdf
Work Experience:
2020 — Front-end Developer
2018 — Full Stack Developer
Resume — Alex Kondrashov — Data Scientist.pdf
Work Experience:
2019 — Data Scientist & Python Developer
2018 — Full Stack Developer
2017 — Back-end Developer
Оптимальный размер резюме — 2-3 страницы. По моему опыту, дальше третьей страницы читать тяжело и неинтересно.
Составные блоки
Name and General Info
Здесь обязательно указывайте контакты для связи. Не поверите, 5 из 10 кандидатов забывают это делать. Что включить в секцию:
По желанию можно оставить ссылки на GitHub и Medium.
Хорошо оформленные контакты для связи:
Больше примеров есть на TopResume.
Добавлять фото необязательно. Если нет качественной фотографии, укажите ссылку на ваш LinkedIn. Главное — не добавляйте селфи в плохом освещении. Это только испортит картину.
Summary of Qualifications
В этом блоке коротко расскажите о своем опыте работы, достижениях и навыках. Цель — показать квалификацию, которая относится к вакансии. Пять буллетов, которые максимально выигрышно покажут вашу кандидатуру, будет достаточно.
Плохой неструктурированный пример:
4+ years IT experience in development, Software Architecture, e-commerce and corporate/investment banking.
Хороший структурированный пример:
Work Experience
Самое ценное в резюме — ваш опыт работы. Поэтому важно помочь работодателю увидеть главное. Если мест работы несколько, расположите последнее вверху этого блока, а все остальные — по убыванию.
В каждом описании места работы указывайте:
О последнем месте работы рассказывайте более подробно, чем про все остальные. Так работодатель сразу увидит релевантный опыт. Структурируйте информацию, чтобы было проще читать. Например, используйте bullet points и начинайте их с глаголов. Так проще показать достижения.
Хороший пример опыта работы с bullet points и глаголами (пример взят с Myperfectresume):
Programmer, July 2011 — present
Technologies Used: PHP, Ruby, JavaScript
лаголы, которые можно использовать в описании опыта: Work, Architect, Deliver, Design, Implement, Had experience with, Help, Maintain, Coach, Support.
Если вы фрилансер или контрактник, оформите каждый проект как место работы. Чтобы было понятнее, указывайте длину проекта.
Хороший пример описания проекта (пример взят с Zety):
Project 1: Updating Example Inc.
Backend Developer, Duration: Three months
Technologies Used: Python, PHP, Ruby, JavaScript
Skills
Перечислите через запятую свои хард скилы. Для IT это языки программирования и фреймворки, для других профессий — программы, онлайн-платформы и техники, в которых разбираетесь. Если навыков слишком много, сгруппируйте их по темам.
Хороший пример оформления скилов (пример взят с Quora):
Machine Learning / Artificial Intelligance: Pandas, NumPy, Matplotlib, Keras, Sklearn, TensorFlow, OpenCV, Natural Language Processing, Supervised Learning, Unsupervised Learning
Data Mining: Data Pre-processing, Data Visualization, Market-Basket algorithm
Mathematics: Statistics, Bayesian Inference Network
Education
Всегда указывайте высшее образование в резюме. Даже если у вас образование психолога, а целитесь в IT. Работает это так, что любое образование в университете дает хорошую базу. Также это покажет, что вы способны к обучению и знакомы с дедлайнами (привет дипломной работе).
Далее скажите про дополнительные курсы. Но указывайте только те, которые относятся к специальности. Если хотите быть маркетологом и прошли курсы шитья длиной в два месяца, то, скорее всего, про это писать не нужно (если вы, конечно, не претендуете на позицию маркетолога бренда одежды). Также не забываем, что самое важное в резюме — опыт работы. Чем больше релевантного опыта, тем меньше необходимо курсов.
Additional
Тут не нужно писать про все хобби. Работодателю не особо интересно читать про то, что вы хорошо играете в теннис или катаетесь на лыжах. Укажите дополнительные интересы и активности, которые так или иначе относятся к работе. Это могут быть:
Стоит ли включать опыт, который не связан с ІТ
Если целитесь на Junior-позицию и у вас нет достаточно опыта работы, переработайте существующий и покажите те стороны, которые могут быть полезны в любой области. Что сюда можно включить:
Плохой пример (взят с Zety). Опыт, который привязан к общепиту:
Хороший пример (взят с Zety). Опыт, релевантный для любой области:
Что еще можно добавить, если мало опыта:
Оформите домашние задания к курсам как часть вашего опыта работы. Если задание относится к программированию, смело публикуйте код в репозиторий на GitHub и укажите ссылку на него в шапке резюме.
Вывод
Главные рекомендации по созданию резюме:
Что должен делать тимлид: роли, обязанности и навыки
Тимлид – это снежинка. При детальном рассмотрении в каждой компании тимлид принимает разную форму. Где-то от него ждут только передвижения задач по доске, где-то – наймов и увольнений, а где-то просят одновременно проектировать архитектуру, ставить бизнес-цели и думать о болях пользователей продукта. На самом деле все обстоит еще сложнее. Различия встречаются не только между разными компаниями, но и даже в рамках команд, находящихся в одном офисе.
Это становится особенно заметно, когда компания сталкивается с одним из следующих вопросов: как собеседовать тимлида, как оценивать его работу, как составить ему план развития. Тимлиды тоже довольно много фрустрируют – они не понимают, насколько их текущий опыт работы останется релевантным при переходе в новую компанию, какие пробелы в знаниях и навыках существуют и как их можно заполнить. Короче говоря, куда не посмотришь, везде с тимлидами как-то сложно.
С этой проблемой столкнулись и мы со Стасом Цыгановым. Но в этот раз вместо того, чтобы обойтись простым решением текущих проблем, мы захотели подойти к вопросу фундаментальнее, собрать информацию об ожиданиях от тимлидов в разных компаниях и обобщить ее в единую общую модель. И, кажется, у нас получилось.
Роадмап
Роадмап содержит в себе два раздела:
Эту модель можно использовать как угодно – для составления собственного плана развития, для формирования должностных инструкций в компаниях, для составления вакансий или проведения собеседований. Учтите, что скорее всего вам нужны не все ветви потенциального развития – и это нормально.
Почему роадмапу можно верить
Основная проблема, о которой я уже упоминал – это разница в восприятии роли тимлида в разных компаниях. При составлении общей модели нельзя было опираться только на наш опыт работы в Авито, Туту и Рамблере. Нужно было исследовать больше компаний.
Начали мы со сбора информации, создав рабочую группу из десятка человек, которые поделились информацией о том, кто такой тимлид в их случае. В этой группе приняли участие руководители разработки как из российских, так и зарубежных компаний, как из небольших стартапов, так и очень крупных заведений. Первый брейншторм подтвердил нашу изначальную гипотезу. Несмотря на большое количество различий, все ожидания и обязанности можно было обобщить в несколько отдельных кластеров-ролей.
Дальше мы ушли детально прорабатывать каждую роль, разделяя ее на ветки и листья с непосредственными обязанностями тимлида, стараясь одновременно не перегрузить роадмап и не сделать его слишком абстрактным. Каждая из обязанностей связана с описанием в базе знаний, которое раскрывает следующие секции:
Получившуюся структуру мы валидировали через серию интервью с руководителями разработки из разных компаний. На интервью мы задавали серию вопросов, чтобы узнать все обязанности тимлида в компании, и одновременно отмечали их на своем роадмапе. В конце получившуюся модель мы показывали интервьюируемому и проводили финальную валидацию. Судя по результатам, мы практически ничего не упустили.
Как роадмап использовать
Для компании
Для тимлида
Работа над роадмапом только начинается – мы делаем первый релиз и нам очень важно собрать еще больше фидбэка:
Пишите комментарии к статье, issues на GitHub и предложения в наш чат!