Найм
Sergei Ermolaev
Продолжаем серию статей про работу TeamLead
Почему я могу высказывать свое мнение на эту тему? Суммарно за свою карьеру я провел около 200 технических собеседований на android/iOS native позиции и около 50 финалов на все позиции (QA, BE, Mobile, Design, System Analyst etc). Я пробовал разные вариации собесов: алгоритмические задачки, проверка теоретических знаний, system design, решение типовых задач, рефакторинг кода и просто разговоры по душам. Так же я пробовал разные вариации финальных собесов: culture fit, проверка софтов, проверка общей насмотренности и так далее. Поэтому у меня сформировалось некое мнение, что работает недостаточно хорошо, а что работает лучше
Итак, начнем. Любой руководитель рано или поздно сталкивается с тем, что ему нужно нанимать новых людей к себе в команду и сталкивается с рядом проблем.
1. Как проверить технический уровень инженера
2. Как проверить перфоманс инженера
3. Как проверить, что человек хорошо вольется в коллектив и будет командным игроком
4. Как убедиться что этот синьор не придет, поразит всех своими знаниями и отнимет у Тим Лида работу (шутка)
Технический уровень
Каждый team lead должен быть экспертом в своей доменной области, по крайней мере в какой-то момент времени. По мере роста, как менеджер вы будете терять технический скилл, потому что будете уделять коду меньше времени, для того чтобы быть в курсе последних трендов нужно просить ваших инженеров вам все объяснять, делать доклады и т.д. Это позволит вам получать выжимку актуальных знаний в сжатые сроки
Сейчас существует множество сообществ, которые помогают хакнуть собесы, заучить основные вопросы и ответы на них. Вы должны уметь отличить синьора, от вчерашнего выпускника курсов. Здесь нет никаких универсальных советов, только опыт в своей доменной области и опыт проведения собеседований.
Существуют разные типы собеседований, мне больше нравится, когда вы с человеком решаете практические задачки, например:
1. как сделать сервис, который будет синхронизировать данные, с какими проблемами мы столкнемся, как мы будем проектировать дата слой
2. Построение навигации экранов и синхронизация данных между ними: как будем пробрасывать данные между экранами, как синхронизировать Стейты при навигации назад
3. Приложение падает, не запускается, как будем исследовать проблему?
Это общие вопросы, с которых легко завязать разговор, инженеру будет комфортно с вами общаться, при этом вы можете копать на столько глубоко, на сколько хватит знаний вашему кандидату
Существуют другие типы собесов, как по мне они чаще работают хуже
1. Теоретический собес: тут мы проверяем, на сколько хорошо человек заучил ответы и такие собесы, чаще всего Джуны после курсов проходят лучше, чем синьоры с 10 годами опыта, потому что у джунов есть мотивация, все это заучить, у синьоров — нет, им нужно решать проблемы бизнеса
2. Алгоритмический собес: проверяем только то, сколько времени кандидат потратил на практику по этой теме. Практической пользы это знание зачастую не несет
3. System design: хорошая секция, но мало людей умеют качественно проводить эту секцию, еще меньше людей умеют ее проходить. Поэтому чаще всего все сводится к тому, насколько человек подготовился к конкретной секции, а не к пониманию его уровню. Кстати, чтобы подготовиться к этой секции, по моему мнению, достаточно просмотреть 5-10 видосов с примерами, что от тебя ожидают. Вот хороший канал, чтобы эти знания получить
4. Рефакторинг кода: хорошая секция, но тут рандом. Секция занимает много времени, если кандидат плох в решении вашего кейса, вы будете час сидеть с ним тупить в код. Но если большая часть вашей работы будет связана именно с подобным, такая секция хорошо позволит найти узкого специалиста, который хорошо будет решать именно ваши задачи
5. Разговор по душам: многие считают это хорошим вариантом, но он работает только на маленьком масштабе, когда у вас команда из 2-5 человек и в ищете себе напарника, с которым вам будет кайфово. Эта история не масштабируется и тут возникает bus factor, что только вы способны нанимать людей.
Такой подход не позволит вам расти по менеджерской ветке
Perfomance
Как проверить, что человек будет, хорошо перфомить? — Никак :)
За час-два технического собеседования невозможно понять, насколько человек будет выкладываться. По мере получения опыта, вы будете с большей долей вероятности угадывать на сколько человек хорошо работает, но с абсолютной уверенностью ни один руководитель не может это определить. Для того, чтобы решить эту проблему, нужно выстраивать вокруг себя community людей, которые уже где-то проявили себя и вы остались с ним в теплых отношениях, чтобы продолжить свою карьеру вместе.
Soft skills, culture fit
Тут тоже нет универсальных советов, но хотел бы отметить пару важных вещей.
1. Начинающие руководители стараются нанимать людей, близких себе по духу — пока вы маленькая банда, это классно, вы все на одной волне, вам нравится работать вместе, но рано или поздно такая команда останавливается в развитии, поскольку не хватает diversity, для того чтобы расшатывать такое уютное болотце
2. За собеседование невозможно проверить на сколько кандидат вам подходит, аналогично перфомансу, вы можете только с определенной вероятностью это предположить. Вообще не зависит, на сколько вы крутой Лид и на сколько вы тонко чувствуете людей — все, даже самые матерые руководители ошибаются, это надо принять и научиться с этим работать
3. При найме кандидата, руководитель должен построить карту навыков текущих его инженеров, понять, каких именно навыков не хватает команде и стараться находить людей именно с недостающими в команде скилами, которые будут способны существенно усилить команду
4. Для того чтобы выявить эти недостающие навыки нужно постараться до автоматизма отработать технику STAR: Situation, task, action, result. Звучит как менеджерский буллшит, но по умолчанию работает лучше и позволяет получать более системные результаты
Например:
Расскажи о неэффективных процессах в своей команде?
Какую задачу ты пытался решить?
Какие действия ты делал для того чтобы решить эту задачу?
Какого результата ты смог добиться?
Если не добился результата, какие выводы сделал?
Это все открытые вопросы, которые позволяют раскрыться кандидату и проявить себя. При таком подходе вы даете возможность кандидату открыто рассказать о своем опыте, а не просто чек-лист умеет/не умеет. При всем этом, интерпретировать ответы кандидата, по началу бывает сложным: «ну вроде что-то рассказал, не понимаю норм это или не норм» — по мере повышения опыта проведения финальных собесов, у вас будет накапливаться база ответов и того, как человек в последствии у вас хорошо работает и в будущем вы сможете с большей точностью выявлять крутых ребят
На этом краткий экскурс по найму закончен, давайте подведем итоги
1. Вы должны уметь точно определять технический уровень кандидата. Для этого надо всегда оставаться в тонусе
2. Для того, чтобы оставаться в тонусе, надо выстраивать у себя в команде шаринг знаний
3. Performance и soft skills точно оценить тяжело. Для того чтобы делать это лучше нужно
- повышать насмотренность
- развивать свое окружение, кого вы сможете зарефералить к себе
- развивать эмоциональный интеллект, учиться задавать открытые вопросы и слушать кандидата