Pull to refresh

Записки юного TeamLead: Собеседования

Reading time6 min
Views23K

Предисловие

Каждому TL хочется показывать высокие результаты в своей работе. Это нужно не только для карьерного роста, каких-то преференций от компании, но и для собственного эго, для понимания того, что ты не стоишь на месте. К сожалению, насколько я знаю, нет специальных “тимлидских” метрик эффективности. Есть общие - время закрытия задачи, закрытие спринта, выполнение целей, сдача функционала / проекта / продукта в срок так далее.

В предыдущем посте я говорил про важность людей, с которыми вы работаете, про их развитие и результаты, а закончил я следующим тезисом: “Ваш результат зависит от команды”. Но вопрос следующий - как набрать команду так, чтобы эффективность TL даже в “попугаях” была высокой? Как понять на этапе собеседования, которое ограничено по времени, уровень компетенций сотрудника, будет ли он частью коллектива, сможет ли ужиться с коллегами и с вами?

За время работы в двух больших компаниях TL, я пообщался с огромным количеством других лидов, people partner’ов, HR и Senior’ов, которые специализируются на технических собеседованиях. Эта статья - грубый чертеж процесса собеседований, который мы собирали с этими людьми в разных компаниях, к которому можно стремиться.

Обзор

В компаниях часто следующая система собеседований:
- Беседа с HR
- Техническое собеседование (1 час - 3 часа)
- Собеседование с TL (1 час)

Мы не будем рассматривать подробно первый этап, так как он чаще всего мало касается TL.

Больше всего меня интересует два последних этапа - техническое и собеседование собеседование (знакомство) с TL. Многие могут сказать, что последний этап не так важен, но на самом деле на этом этапе решается подходите ли ВЫ кандидату. Я выделил это неслучайно и рассмотрю этот тезис ниже.

С техническим тоже все не так просто, как хотелось бы. В сети постоянно идут споры о необходимости livecode сессии, о методиках оценивания и вопросах на собеседованиях. Уровень неопределенности достаточно высок, поэтому одного кандидата могут оценить в трех компаниях на три разных уровня. Согласитесь, было же такое?
О прохождении технической части мы сначала и поговорим.

Техническая часть

Три интервьюера или два, или один? По какой матрице спрашивать? А что спрашивать? Давать livecode? А как организовать структуру собеседования, чтобы оценить? А какую оценку дать? И еще 100+ вопросов, на которых нет однозначного ответа. Хотя есть - “Везде по-разному”.

Стиль собеседования

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

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

А как построить диалог, если с TL будет напарник в виде TechLead или Senior? Заранее подготовиться и пройтись по структуре собеседования. Одна такая подготовка - это всего 15 минут времени перед собеседованием, небольшая страничка в Notion со структурой и перечнем тем с проставленным временем и закреплением темы за интервьюером.

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

Матрица компетенций как инструмент оценки

Когда мы выбираем темы, мы примерно должны прикинуть какие вопросы мы будем задавать. Ведь время ограничено, а кандидата нужно спросить желательно “все”. Конечно спросить все не удается, но мы же должны стремиться к идеалу.

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

Матрица - это всего лишь договоренность о том, как мы будем оценивать, что мы будем оценивать и посредством чего мы будем оценивать. Она может иметь любой вид, но ключевое в ней:

  • Темы

  • Уровни (junior, middle, senior)

  • Вопросы

  • Критерии оценивания

Livecode

Часто многие говорят, что livecode давать - изжило себя. Да и это большой стресс для кандидата - не каждый может при всех в открытую писать код. И в целом заставлять Senior разработчика писать код иногда странно, соглашусь.

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

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

Во время livecode я всегда обращал внимание на:

  • На стилистику написания

  • На скорость решения задачи

  • На сложность решения

  • На количество и уместность предложенных решений

Конечная оценка

После прохождения секции, выставляется оценка. Оценка, естественно, выставляется на основе ответов кандидата, результата livecode. Дается краткая характеристика, пишется обратная связь.

Интересный факт
Если матрица компетенций хорошо работает и достаточно “отлажена”, то два интервьюера дают независимо друг от друга одинаковую оценку

Итог

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

Ведущий: Nick
16:00 Приветствие, план собеседования — ведущий
16:15 Вопросы по проектам с предыдущего места работы — помощник ведущего
16:30 Общие вопросы (CI/CD, архитектурные принципы) — помощник ведущего и ведущий
16:45 livecode-сессия — Ведущий
.....

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

Стоит обратить внимание на фиксацию ответов. Иначе оценку в дальнейшем выставить будет очень сложно (вы можете все что угодно забыть)

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

Беседа с TL

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

Кандидат ищет для себя комфортное место работы, где его нервная система будет в покое, где он сможет получать адекватную обратную связь, развиваться и быть частью команды. Все что я перечислил - зависит от TL команды. И задача кандидата определить не токсик ли TL, а задача TL определить сможет ли кандидат взаимодействовать с командой и с ним.

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

Обычно здесь принимается решение о возможности сотрудничества с кандидатом.

Обратная связь

Самая спорная часть статьи.

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

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

Я часто прикрепляю нужные статьи по темам, какие-то источники информации, общие рекомендации, которые помогут соискателю подтянуть уровень знаний. Кто знает, может через несколько месяцев (или лет) мы снова встретимся на собеседовании.

Заключение

О чем все это?

О том, что даже такой “конвейерный” процесс, как собеседования может иметь человеческое лицо, где каждому соискателю дают трезвую оценку без надменности (которая иногда встречается на собеседованиях в некоторых компаниях). И процесс выставления этой оценки - это не просто мнение одного человека, а целая система.

В свою очередь, система должна быть отлажена. С матрицей компетенций, с критериями оценивания, с нетиповыми вопросами и доброжелательным отношением к соискателю.

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

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

Благодарности

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

Хочу поблагодарить:
Senior Frontend - разработчика Дмитрия Тусаева,
PM Андрея Пономаренко,
TL Юрия Секина,
L&D специалиста Нелли Лакосину,
HR Елизавету Лагиреву,
TL Станислава Шурупина,
TechLead Backend Дмитрия Яковлева

Tags:
Hubs:
Total votes 13: ↑4 and ↓9-3
Comments13

Articles