Кросс ревью что это
«Подношу эксели и клепаю дашборды»: за что действительно должна отвечать команда аналитики
Рассказываю, как не похоронить свой дата-отдел под таблицами с кучей цифр.
Привет, меня зовут Дима Зборовский, я вице-президент по аналитике и эффективности платформы в СберМаркете (экс-Instamart). Три года назад я пришел сюда из Яндекс.Go — чтобы собрать дата-отдел.
Мне всегда хотелось, чтобы аналитика перестала быть сервисной функцией, которая просто обслуживает бизнес. Ни одна из компаний, где я работал или к которым присматривался, не делала свой дата-отдел фронт-офисом или полноправным бизнес-юнитом. Ребята отвечали за какие-то метрики, снабжали бизнес инсайтами, помогали проверять гипотезы, но конечные решения все равно принимали другие люди. Все лавры тоже доставались им.
Один топ-менеджер крупной почтовой IT-компании в личном разговоре вздохнул, грустно покачивая головой: «У нас, к сожалению, не отдел аналитики, а отдел статистики. Ребята умные, но не получается качественно вовлечь в развитие бизнеса».
Здесь важно сразу договориться о парадигме. Аналитик — не тот, кто просто владеет инструментами Python и SQL. А тот, кто может взять лидерство над какой-то проблемой или процессом, структурировать дерево решений, накидать гипотезы, собрать данные для подтверждения или опровержения, а потом еще и презентовать результат. Ну не круто ли? К сожалению, чаще всего аналитиков привлекают лишь на этапе подготовки данных. Это неправильно.
Когда команда аналитики в Instamart только создавалась, мы сразу обсудили с СЕО, что будем отвечать за бизнесовые показатели. Вплоть до ответственности перед советом директоров. В один момент мы даже стали называть вакансии как «Аналитик/PM».
Если нажать fast forward >> на 3 года, то сейчас наша команда Data&Growth, помимо стандартных вещей вроде DWH, BI и так далее, отвечает за:
Лидировать важные куски бизнеса — круто. Но сервисность тоже никуда не уходит: важно поддерживать компанию аналитической инфраструктурой и распространять data-driven культуру. Дашборды действительно упрощают ежедневную жизнь, а чистота данных для бизнеса — та гигиена, без которой ничего не построить.
Что нужно дата-сайентистам, чтобы превратиться в ценный отдел:
Команда должна быть построена по типу гильдии. Со своим процессом планирования, кросс-ревью, опылением мудростью, обучением друг друга, общими правилами использования инфраструктуры, принципами и ценностями. Тут важен баланс. Команда не должна быть полностью централизована и иметь только одно окно для входящих запросов. Это убивает скорость: ребятам не удаётся наработать бизнес-экспертизу. Полностью децентрализовать тоже нельзя: без общего руководителя не будет консистентности в метриках и данных.
Вместо того, чтобы ловить «рыбу» за других, стоит раздать всем «удочки». Чтобы дать себе время на развитие бизнеса и поиск точек роста, убедитесь, что хотя бы 80% аналитических вопросов люди из других отделов могут решить самостоятельно — через интерфейсы.
Правильное позиционирование. Аналитики — это проджект- и бизнес-лидеры, у которых, ко всему прочему, есть крутой технический инструментарий. Которые позволяют ребятам быть практически полностью автономными.
Мы не знаем, что будет через десять лет, но точно знаем, чего не будет — не будет меньше данных. Роль аналитиков растет каждый год. И очень быстро. Пришла пора менять порядки: дата-отдел может и должен стать основой любого бизнеса.
Будь строже к себе: как ограничения помогают сделать код лучше
Если вам приходилось задумываться о построении эффективной экосистемы проекта и определении ролей тимлида и разработчика — статья Артема Прозорова из ZeBrains для вас.
Предлагаю вам задуматься над одним вопросом. Но не спешите с ответом, потому что он не так очевиден, как может показаться:
Какая из команд может реализовать более технически стабильный продукт?
Команда №1: Проектный менеджер, аналитик, тестировщик и несколько разработчиков, у каждого из которых за плечами минимум три года опыта. Все работают в одном офисе, посвящая свое время одному проекту в режиме fulltime.
Команда №2: Один сильный разработчик. Ему помогают множество не знакомых между собой людей из разных часовых поясов. У каждого — свой набор компетенций и уровень опыта. Работой над проектом участники занимаются в свободном режиме, по несколько часов в неделю.
Ответ на этот вопрос мы получим к концу статьи, а сейчас — немного скучной, но важной теории.
Разработка программного обеспечения — процесс творческий. Программисты реализуют один и тот же функционал по-разному. Но есть определенные правила, соблюдение которых придает коду стабильность, читаемость и простоту поддержки. Давайте взглянем на историю развития программирования и выявим эти правила.
Парадигмы программирования
В 1968 году Эдсгер Вибе Дейкстра показал, что безудержное использование переходов (инструкций goto) вредно для структуры программы. Он предложил заменить переходы более понятными конструкциями if/then/else и do/while/until. Это дало основу парадигме структурного программирования.
Можно сказать, что структурное программирование накладывает ограничение на прямую передачу управления.
Второй парадигмой, получившей широкое распространение, стала парадигма объектно-ориентированного программирования. Она поднимает структурирование кода на более высокий уровень, вводит понятия наследование, инкапсуляция и полиморфизм.
ООП устанавливает ограничение на косвенную передачу управления.
Третьей парадигмой является парадигма функционального программирования. В ее основе которой лежит неизменяемость или, иными словами, — невозможность изменения значений символов. Идеологически это означает, что в функциональном языке не должно быть инструкции присваивания. На практике большинство функциональных языков обладает средствами, позволяющими изменять значение переменной, но в очень ограниченных случаях.
Функциональное программирование накладывает ограничение на присваиваемость значений.
Получается, каждая парадигма привносит свои ограничения, при этом ни одна не добавляет новые сущности.
Принципы проектирования и шаблоны
Эстафету парадигм подхватывают принципы проектирования, которые добавляют свои ограничения:
SOLID — на построение абстракции.
DRY — на повторяемость кода.
KISS — на сложность логики.
Не отстают и шаблоны проектирования. Например, MVC ограничивает разделение логики. А различные линтеры и стандарты определяют правила оформления кода, что тоже является ограничением.
Неформальное определение качества кода
Каждая парадигма, каждый архитектурный принцип, каждый шаблон проектирования и каждый линтер говорят нам больше не о том, что делать, а о том, чего делать нельзя. Чем точнее разработчик следует установленным ограничениям, тем более качественным становится его код.
Код настолько качественен, насколько разработчик соблюдает установленные ограничения.
Пример из мира свободного ПО
Давайте вернемся к вопросу, который был обозначен в самом начале статьи. Первый вариант — типичная команда, собранная коммерческой организацией для коммерческого проекта. Второй — часто встречается в проектах с открытым исходным кодом.
Не бросая камни в сторону коммерческой разработки, все же надо отметить, что весьма часто ПО с открытым исходным кодом забирает себе львиную долю рынка, оставляя свои коммерческие аналоги далеко позади. Достаточно взглянуть на ОС Linux, ОС Android, веб-сервера Apache и Nginx, СУБД PostgreSQL, MySQL. Все они являются стандартами де-факто в своей отрасли.
Более того, часто ПО, разработанное командой, напоминающей вторую из примера в начале статьи, написано намного более качественно, чем ПО, разработанное InHouse.
Почему же проекты добиваются успеха, хотя их команда на первый взгляд не внушает доверия? Давайте разбираться.
Успех свободного ПО
Команда успешного проекта с открытым исходным кодом зачастую состоит из ключевого разработчика или инициативной группы и сообщества контрибьюторов. Роль ключевого разработчика заключается в том, чтобы сформировать идею и заложить такую архитектуру, в которой огромное количество разработчиков с абсолютно разными компетенциями будет эффективно работать. Под архитектурой здесь имеется в виду набор интерфейсов (контрактов, протоколов), оперирующих описанными структурами данных. Как правило, архитектура сопровождается спецификацией — она описывает, как именно система должна функционировать. Реализация же этих интерфейсов лежит на плечах всего сообщества. При этом каждый контрибьютор может быть погружен в проект ровно настолько, насколько это позволяют его компетенции, желание или возможности.
Главное качество ключевого разработчика — это способность разбить функционал приложения на мало связанные друг с другом компоненты, реализация каждого из которых не требует глубокого знания о системе вне пределов этого компонента.
Разбивая логику приложения на мало связанные компоненты, покрытые интерфейсами, ключевой разработчик одновременно накладывает архитектурные ограничения на разработчиков и обеспечивает их эффективную совместную работу. В таких условиях контрибьютор, работающий над реализацией интерфейса, не должен обладать знаниями о системе ВНЕ этого интерфейса. Это обеспечивает максимально быстрое погружение новых разработчиков в проект. С другой стороны, риски сломать что-то внутри проекта сведены к минимуму, потому что свобода действий ограничена интерфейсом.
Эта тема перекликается с принципом предметно-ориентированного проектирования (Domain Driven Design, DDD). Среди разработчиков бытует мнение, что основное предназначение DDD — обеспечение легкого переключения между фреймворками. Это не так. Главная задача DDD — это отделение логики приложения от логики фреймворка. Это дает возможность работать с высокоуровневой логикой приложения, не залезая в дебри фреймворка, и наоборот. Но это тема для отдельной статьи.
Ограничения, наложенные на свободное ПО
Условия, в которых происходит работа над проектами с открытым исходным кодом, также задают определенные правила для разработчиков. Вряд ли вы можете встретить успешный проект с открытым исходным кодом, который не будет на каждый Pull Request требовать как минимум двух апрувов, выполнять линтеры, прогонять тесты и статические анализаторы кода.
Для проекта с открытым исходным кодом строгое соблюдение ограничений — это залог выживания проекта в целом.
На коммерческих проектах зачастую контроль за соблюдением ограничений проходит весьма слабо. Даже тесты пишутся далеко не на каждом — по моей субъективной оценке, разработчики стараются избегать написания тестов, ошибочно аргументируя это отсутствием времени.
Второе отличие разработки проектов с открытым исходным кодом от коммерческих заключается в ограничениях на коммуникацию. Так как команда проекта может постоянно меняться, структурирование и сохранение информации для таких проектов — это не только вынужденная мера, но и единственный способ выжить и развиваться. Поэтому вся коммуникация тесно связана с кодом и фиксируется в обсуждениях внутри Pull Request-ов, в todo-шках и комментариях прямо в коде, в issues, страницах с документацией и так далее.
В коммерческой InHouse команде ничего не мешает подойти к коллеге в течение дня и обсудить важные архитектурные вопросы в личной беседе, игнорируя письменную фиксацию принятых решений. В итоге последующие разработчики могут потратить огромное количество времени на выяснение подробностей таких решений.
Секрет качественного кода — в управлении ограничениями
Чтобы максимально точно донести тезис, используем предельно жесткую и даже провокационную формулировку:
Для эффективной работы команды на проекте старайтесь накладывать на свою команду как можно больше ограничений.
Ограничьте роль тимлида
Роль тимлида предполагает, что такой специалист обладает видением всей системы в целом, всех ее компонентов, понимает, как именно компоненты взаимодействуют между собой.
Ограничения тимлида заключаются в том, что он не должен отвечать за реализацию компонентов. Конечно, тимлид может брать на себя разработку определенных блоков функционала, но его основная задача — отвечать за общую картину, решать архитектурные вопросы.
Ограничьте роль разработчика
В отличие от тимлида, разработчик на проекте должен быть погружен только в те компоненты, разработкой которых он занимается, и детально понимать их реализацию. То есть ограничения разработчика заключаются в том, что он действует строго внутри установленных интерфейсов и не имеет права их менять без согласования с тимлидом.
Используйте линтеры и статические анализаторы кода
И чем больше, тем лучше.
Используйте код ревью и кросс ревью
Код ревью — мощный инструмент повышения качества кода. Но не забывайте и про кросс ревью — взаимное ревью разработчиков, работающих над разными частями системы или даже на разных проектах.
Пишите тесты
Причем — модульные (юнит), потому что написание именно таких тестов накладывает на разработчиков архитектурные ограничения: вы не сможете написать модульный тест без использования таких паттернов, как Dependency Injection, DI Container, и так далее.
Вместо резюме
Следите за миром свободного ПО, изучайте архитектуру проектов с открытым исходным кодом. Перенимайте их практики. Установите ограничения на рабочую коммуникацию внутри команды. Следуйте правилам работы с системой контроля версий, правилам ветвления и создания Pull Request-ов.
Ограничения способствуют повышению качества кода, что, в свою очередь, приводит к созданию более жизнеспособного продукта.
Постскриптум: Формализация коммуникаций и «портирование» InHouse правил разработки, присущих OpenSource проектам, ни в коем случае не отменяет необходимость живого общения, выращивания командной культуры и здоровой атмосферы в коллективе. В противном случае — любой, даже самый отлаженный процесс сведут на нет холивары и бодания в Pull Request-ах.
Код ревью, как внедрить и не испытывать боль
Если вы работаете в продуктовой компании, то жизненный цикл почти каждого продукта будет соответствовать принципу Парето:
20% времени мы пишем новый код.
80% времени поддерживаем старый. Поддержка в себя включает фиксы багов, обновление кодовой базы (переезд на новые библиотеки например).
Во время поддержки мы хотим чтобы все разработчики как можно быстрее вникали в то, что написано. Для этого есть много способов, все они прекрасны и хорошо работают вместе.
Способы иметь хорошо поддерживаемый код:
Все эти способы нужно уметь готовить. Есть тесты, которые только мешают, бесполезная документация и бессмысленный код ревью.
Что же такое код ревью?
Что нам даёт код ревью:
Проверку кода по многим критериям.
Автор не всегда видит неочевидные места в его коде (по разным причинам).
В результате написания и переписывания может быть потеряна композиция.
Автор, находясь в контексте задачи может недостаточно оставить комментариев.
Эти и многие другие проблемы может решить код ревью.
Шаринг знаний о проекте.Не только автор знает, что там пишется в другом проекте или части проекта, а все.
Шаринг знаний о технологиях.Вы можете заметить, что кто-то напилил своих костылей, а похожая проблема в проекте уже решалась. В таком случае ревьюер может подсказать что уже использовалось и избежать ненужного кода
Сотрудники быстрее онбордятся. Новые сотрудники, проводя код ревью, быстрее узнают и понимают традиции команды, а проходя его, имеют возможность исправить ошибки, узнать больше о продукте и меньше испытывать стресс.
Способов поддерживать код «качественным» есть много, но все их нужно правильно готовить. Нужно уметь писать тесты, нужно уметь писать документацию и нужно правильно организовать код ревью.
Советы по организации процесса
Условные обозначения:
— Как делать не нужно
+ Как делать нужно
- Ревьюить только джунов и новых коллег
+ Проводить ревью для всех и всеми
Если ревью проходят не все, то в вашей команде это будет восприниматься как источник недоверия и неравенства. Такую атмосферу следует избегать.
- Обсуждать на код ревью стиль
+ Настроить у себя на проекте инструменты, которые автоматически будут исправлять стиль перед коммитом
В JS это eslint и prettier. Не тратьте время своё и коллег на споры о вкусах. Договоритесь заранее и пропишите правила. В случае разногласий голосуйте.
Не обсуждайте стиль на ревью
- Ревьюер запускает руками билд или проверяет код на баги.
+ Автор сам несет ответственность за поставленный код.
Автор тщательно проверил свой код на работоспособность и залил в удаленный git репозиторий
На сервере CI/CD проверяет тесты, сборку, работоспособность в целом.
Проверка со стороны ревьюера.
- Ревьюер не читает код
+ Обращать внимание на композицию, магические переменные, оптимизацию (там где это имеет смысл)
Обращайте внимание на код ревью.
- Агрессия, негатив, «токсичное» поведение в комментах
+ Старайтесь отмечать не только негативные стороны, но и хвалить за позитивные.
Агрессия, негатив и токсичное поведение в принципе стоит избегать во всех областях жизни. Грубое поведение во время код ревью может привести к:
Стрессу и страху совершить ошибку
Примеры плохих комментов:
Примеры хороших комментов:
«Давай попробуем сделать …» «Может попробуем вынести…»
То же самое касается и ответов на комменты автором. Если автор не согласен, то необходимо объяснять с помощью аргументов, а не фраз в духе «я так делать не буду». Если не получается текстом, иногда проще подойти или сделать короткий созвон, чтобы понять друг друга.
Чаще хвалите код в ревью
- Все комментарии обязательны к исправлению
+ Помечать необязательные комментарии
Пытаться объяснить алгоритмы на словах
Написать пример псевдокода
Особенно актуально, если автор не совсем понимает что от него хочет ревьюер. Не нужно полностью писать реализацию. Напишите небольшой пример псевдокода. Gitlab, github и bitbucket позволяют вставлять в комментарии разметку markdown. Ваш код будет хорошо отформатирован и более понятен, чем длинная цепочка комментов.
- Оставлять больше 50 комментариев
+ Оставлять до 50 комментариев
Если комментариев накапливается очень много, то у вас:
Или не настроены линтеры, и вы не определились со стилем, поэтому комменты о вкусовщине
Или переделать в коде нужно многое
Во втором случае оставьте 1 комментарий с рекомендациями как и что нужно переписать. В таком случае лучше закрыть мердж реквест, переписать код и открыть новый.
Если код будет переписан полностью, отследить изменение по комментариям практически невозможно и они не имеют смысла. Авторы тоже должны это понимать и следить, чтобы всем было комфортно.
- Отправлять огромные фрагменты кода на ревью
+ Дробить большие участки кода на несколько реквестов и вливать постепенно
Задачи бывают разными по объему. Может быть задача исправить 1 строчку кода, а может быть задача отрефакторить весь проект. Во втором случае не отправляйте реквест в котором исправлены 500 файлов и 4000 изменений. Никто в здравом уме не сможет это нормально проверить, и желания такое проверять вы тоже не найдете.
Сделайте ветку feature/epic-name
Изменения делайте в ветке feature/epic-name-implement
Pull реквесты делайте в ветку feature/epic-name. Порционно.
В конце реализации фичи подлейте feature/epic-name в мастер. Да, в этом случае пулл реквест тоже будет огромный, но всё уже будет заранее проверено
Другой вариант как этого избежать: feature flags. Вы вливаете изменения на прод, но не даете им пользоваться. Нормально это реализовано мало у кого. Поэтому с этим подходом нужно быть осторожнее.
Уважайте тех, кто будет проверять ваш PR
- Pull Request висит без ревью трое суток
+ Выработать расписание
Среди аргументов против код ревью вы услышите, что с ним у вас увеличивается время «доставки» фич. Чтобы этого не происходило, выработайте у ревьюеров расписание. Например, новые реквесты проверять до работы и перед уходом домой, а исправленные в перерывах в течении дня (например пока проект собирается или тесты гоняются).
В заключении
В этой статье я хотел рассказать и показать плюсы проведения код ревью. Будучи старшим разработчиком я всегда за то, чтобы мой код проходил code review. Лично для меня это отличный способ “увидеть” свой код чужими глазами. еще до того как ветка отправляется на ревью. Не говоря уже о том, что для команд это недорогой и эффективный способ иметь кодовую базу, с которой можно будет эффективно работать.
Если в вашей команде нет код ревью, то самое время его внедрить .
Ссылки и благодарности
По теме рекомендую почитать:Статья How to Do Code Reviews Like a Human
Спасибо лису и kirjs из @learnInPublic за ревью статьи про ревью.
23 ошибки IT-рекрутера на собеседовании: как не облажаться перед кандидатом. Часть 1
Профессия IT-рекрутер все сильнее востребована, при этом сложна и многогранна. Хороший рекрутер — это немного работник отдела продаж, психолог, а еще менеджер продукта и аналитик.
Это работа с большим количеством информации, на пересечении нескольких областей профессиональных навыков: IT-рекрутер разбирается во многом. Даже опытный специалист может легко совершить оплошность, а фейл — стать поводом для мемов.
Давайте рассмотрим типичные ошибки рекрутеров и то, как их можно избежать. Рассказывает Татьяна Аква из «Hi, Rockits!»
Ошибка 1. Не готовиться к интервью и читать резюме на встрече
Знакомиться с резюме прямо вовремя собеседования — крайне неуважительно. Кандидаты считают, что раз уж вы пригласили на интервью, то изучили опыт и считаете релевантным для позиции. Соискатели ждут, что разговор будет предметным.
Решение
Готовиться к интервью заранее и задавать вопросы, исходя из пунктов резюме. Это показывает, что вы с ним внимательно ознакомились и хотите узнать подробности.
Например: «Вижу, что в компании Яндекс занимались разработкой мобильного приложения на Swift. Какая была версия? А какой блок писали вы?»
Ошибка 2. Делать большие паузы между вопросами
Паузы и промедления — бич многих рекрутеров. Есть и другое проявление этого «бага» — анкетирование на собеседовании: вопрос за вопросом, как на допросе. В таких случаях каждая фраза начинается однообразно: «скажите, пожалуйста» или «следующий вопрос».
Решение
Готовиться к собеседованию заранее, планировать ход разговора и брать подсказки на интервью. Лучше всего приходить со списком конкретных вопросов.
Например: «Какие были подходы к качеству кода в прошлом месте работы? Руководствовались ли SOLID? Какой был процент покрытия кода тестами? Как проходил код-ревью: делали кросс-ревью или проверял руководитель?»
Ошибка 3. Делать вывод в первые минуты собеседования (и проявлять незаинтересованность)
Во-первых, это неуважительно по отношению кандидату, который тоже тратит свое время. Во-вторых, есть верная поговорка: «Не суди о книге по обложке». Вы можете банально ошибиться в своей поспешной оценке, отказавшись копать глубже.
Решение
Помните об эффекте Даннинга-Крюгера — появлении завышенных представлений о своих умениях. Даже гуру рекрутмента с многолетним опытом могут ошибаться. Что уж говорить о молодом специалисте.
Если мотивация человека при смене места работы очевидно не подходит компании (например, человека интересует только финансовый вопрос), не стоит строить дальнейший диалог негативно.
Важно не показаться грубым — это минус репутации компании, которую вы представляете. Если кандидат на данном этапе неинтересен по другой причине, собирайте максимальное количество информации: возможно, он подойдет для другой вакансии.
Ошибка 4. Бояться копать глубже и показаться навязчивым
В большинстве случаев не стоит довольствоваться односложными ответами. Так, услышав расплывчатую формулировку о причинах ухода с прошлого места работы, не стесняйтесь уточнить: «Почему именно не сложились? Какие шаги предпринимали стороны для решения ситуации? Можете рассказать об этом подробнее?»
Нужно понимать, что о причине смены работы спрашивают практически все, и у кандидатов заготовлены стандартные ответы. Как правило, они довольно минималистичны, но нам же нужно узнать настоящую причину.
Решение
Основной вопрос для понимания истинных причин начинается с «почему». Обычно уже только с его помощью можно получить развернутую информацию, но можно и вызнать все подробности.
Например:
К: Ушел, потому что были разногласия с начальством.
Р: А в чем именно они заключались? Какая у вас была позиция? Как пытались ее отстоять?
К: Были некомфортные условия.
Р: Расскажите, пожалуйста, в чем именно. Неудобное место, плохая аппаратура, низкая зарплата? Могли бы рассказать подробнее?
К: Не совпадало видение на развитие продукта.
Р: А в чем конкретно? Говорили ли руководителю об этом? Что он ответил?
Ошибка 5. Проводить невнимательный скрининг резюме
При изучении резюме рекрутеры довольно часто обращают внимание на краткосрочные периоды работы кандидата, но забывают оценить временные промежутки между ними. И очень зря, ведь это может быть критичным моментом.
Не заметить у кандидата гражданство другой страны — тоже частая проблема, когда в компании есть ограничение на трудоустройство иностранных граждан. Начинающие айти-рекрутеры часто упускают этот момент, если эта информация не указана в явном виде.
Решение
Сделать чек-лист «сложных» моментов и следовать ему при скрининге. Если не указано гражданство, определить его можно по образованию или первым местам работы (часто указан город). Также этот процесс можно автоматизировать, используя инструменты ит-рекрутера.
Ошибка 6. Не уметь отвечать на вопросы кандидата
Чаще всего такая ошибка встречаются у рекрутеров из кадровых агентств. Она обычно связана с тем, что рекрутер заранее не продумывает, какие вопросы могут быть интересны кандидату. И, соответственно, не собирают информацию, чтобы на них ответить.
Честно, это не очень хорошо, если рекрутер говорит: «А вот это уточните на собеседовании с руководителем» или «Вот это, к сожалению, не подскажу». Опять же, все учесть невозможно, да и кандидаты разные, с разными вопросам. Но, если так вышло, то стоит записать вопрос и собрать информацию, чтобы ответить в следующий раз. Это важная обязанность IT-рекрутера.
Вопрос не только в вежливости и помощи кандидату. Важно еще и то, что это поможет рекрутеру «погрузиться» в вакансию, посмотреть на нее глазами соискателя. Если каждый вопрос уточнять у компании, то через несколько собеседований в вашем распоряжении будете все необходимое — для полной картины вакансии.
Решение
Если ответить в моменте нет возможности, ничего не придумывайте. Договоритесь, что добудете всю нужную соискателю информацию и вернетесь с ответом в ближайшее время. Записывайте вопросы, на которые не смогли ответить, чтобы позже все разузнать (не стоит рассчитывать на память — она подводит). Так, кандидат увидит, что вы реально заинтересованы в нем.
Ошибка 7. Задавать расплывчатые вопросы
Например, классическое: «Расскажите про свой опыт». С какого конца кандидату на него отвечать: рождения, института, первой или последней работы? Непонятно, что рекрутер хочет услышать: биографию за 30 секунд или верхнеуровневый набор обязанностей на предыдущих местах работы.
Не ждите, что кандидат выдаст выверенный и релевантный рассказ о себе и своем профессиональном опыте. Время ограничено, и нужно действовать самостоятельно, чтобы обсудить именно то, что требуется.
Решение
Определитесь, что вас интересует и волнует в истории кандидата. Затем сформируйте набор вопросов. Они должны быть понятными и конкретными.
Например: «Сколько лет пишите на Java? Какая целевая аудитория софта? Какой функционал? Чем именно вы занимались? Из кого состояла команда? Какие были библиотеки, базы?»
Ошибка 8. Обрушить на кандидата слишком много информации о компании и вакансии
Если не хотите «потерять» кандидата во время разговора, не пытайтесь вывалить на него максимум информации. Разбивайте ее на логические блоки и поощряйте уточняющие вопросы.
Устраивая «лекцию», вы упускаете возможность прощупать мотивацию кандидата. Ведь он спросит о компании и вакансии то, что ему реально важно. Это прекрасная точка синхронизации декларируемых ценностей кандидата и реальных интересов.
Решение
В начале собеседования изложите основную информацию кратко, чтобы напомнить предмет разговора. Предложите кандидату задавать вам вопросы в ходе интервью.
Выделите в середине собеседования еще один блок для вопросов кандидата — предложить ему задать их. Если оставлять время только в самом конце, вы рискуете столкнуться с усталостью: кандидат попросту захочет скорее закончить интервью.
Выдавайте информацию о компании и вакансии дозировано. Отвечайте на вопросы кандидата — по мере поступления. Если вопросы закончились, а информация еще осталась, и вы считаете важным поделиться, дополнить свой рассказ.
Ошибка 9. Стесняться запрашивать документы и проверять ПД
Работа ит-рекрутера состоит в предоставлении достоверной информацию клиенту (или внутреннему заказчику). Проще потратить две минуты и сверить паспортные данные. Бывают случаи, когда в резюме и паспорте не совпадают: ФИО, возраст или даже пол.
Не всегда это тревожный звонок, и совсем не обязательно является поводом для отказа — сначала разберите ситуацию. Рекрутер должен обладать информацией о персональных данных и передавать ее заказчику в полном объеме, оставляя решение на его усмотрение.
Решение
Запрашивать паспортные данные на проверку. Если есть какие-то нюансы, сам кандидат может об этом и не упомянуть. Конечно, если только его об этом прямо не спросить.
Например: «Давайте уточним сразу, если в компанию понадобиться заказывать пропуск. Ваши ФИО и дата рождения в резюме указаны корректно, верно? Или есть какие-то изменения?»
Ошибка 10. Бояться уточнять информацию, которую (возможно) обсуждали ранее
Такое случается у начинающих из-за опасения вызвать негатив у кандидата, задавая вопросы, которые уже звучали ранее (например, в переписке). Рекрутер пытается вспомнить, обсуждали ли тему ранее (но не может). В результате вопрос он задать не решается, а существенный момент так и остается непознанным.
Решение
Использовать все данные в подготовке к собеседованию, не только резюме. Стоит захватить переписку или лог телефонного разговора. И не бойтесь повториться — кандидат с большой вероятностью отнесется с пониманием.
Например: «Я помню, мы, кажется, обсуждали это по телефону ранее, но давайте проговорим подробнее».
Ошибка 11. Не разобраться в прошлых проектах кандидата
Кандидат априори больше погружен в свою работу, является специалистом. Но то, что очевидно ему, может быть совсем не очевидно рекрутеру. Бывает, что на интервью соискатель уходит в тонкости профессии/проекта, говорит сложными терминами.
Рекрутер в это время теряется, стесняется продолжать расспросы и узнавать подробности. Нежелание ит-рекрутера разобраться с моментами, которые критичны на предлагаемой позиции, может обернуться пробелом в сборе критичной для заказчика информации.
Решение
О прошлом опыте стоит уточнять до тех пор, пока не разберетесь хотя бы на уровне пользователя в том, что из себя представляет проект/продукт/приложение.
СТО может затем спросить рекрутера: «Я не знаю эту систему. Вы спрашивали у кандидата, что это?». Вы, конечно, спрашивали, но не разобрались до конца — ответить сложно. Не нужно стесняться разбираться в проекте до полного понимания.
Ошибка 12. Не знать важных и «очевидных» вещей (для совсем начинающих)
Речь не о том, чтобы знать, какая актуальная версия Android сейчас используется в мобильной разработке (хотя, если ищете мобильного разработчика, то знать обязаны). А о таких вещах, как задавать кандидату из Яндекс, Крок, Evrone вопрос о том, чем компания занимается.
Незнание очевидных фактов о сфере и компании настраивает кандидата на недоверчивое отношение к рекрутеру ит-специалистов. Кто-то даже может усомниться в вашем профессионализме или попросту обидеться.
Решение
На первых порах нужно готовиться к собеседованиям IT-рекрутеру особенно тщательно: изучать деятельность компаний, разбираться в рынке, погрузиться в предметную область. Вам будет гораздо легче, когда вы проделаете такую ресерч-работу.
Мы не ошиблись с заголовком: ошибок и правда двадцать три — продолжение в следующей части. Будем и дальше разбирать типичные фейлы и предлагать решения.
Жаль, что единого пособия IT-рекрутера не существует. Но еще больше советов и лайфхаков для рекрутеров — в Telegram-канале “Hi, Rockits!”