Первая версия статьи вышла в блоге GeekBrains.

Мы в HFLabs делаем большие проекты с данными. Заказчики — крупный и очень крупный бизнес: «Сбер», МТС, «Росгосстрах», «Икея». Работы много, и нам постоянно нужны сильные IT-специалисты: разработчики, аналитики, QА.

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

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

Поехали.

Отклик на вакансию — это первое тестовое

На площадках вроде hh.ru привлекательные вакансии собирают десятки и сотни откликов в день. Поэтому на первом этапе мы не изучаем кандидатов подробно — не хватит никаких ресурсов. 

Здесь прекрасно работают тестовые задания. Только не те, которые hh.ru встраивает прямо в вакансию. На такие объявления нельзя откликнуться, не решив задачу. Поэтому, прикрепляя такое тестовое, работодатель только повышает порог и сужает воронку.

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

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

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

Чтобы понять, осознанно или нет откликнулся кандидат, достаточно одного признака: прочитал ли человек текст вакансии. Проверить это легко, задав простой вопрос в конце объявления. Например, «Что вам понравилось в вакансии?». Дальше мы смотрим, ответил кандидат в сопроводительном на вопрос или нет.

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

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

Я всегда начинаю текст со слов: «Привет, меня зовут Миша Берёзин». Угадаете, сколько человек отвечают взаимностью в сопроводительном письме? Один из ста пишет что-то вроде «Привет, Миша». Всего один из ста! 

По этому критерию мы не отсеиваем, но за теплый отклик накидываем очков эмпатии.

Второе задание — еще до интервью

Если с откликом всё хорошо, мы даем кандидату несложную задачу. При этом сообщая, что человек успешно прошел отбор по резюме. Это важная деталь: кандидат понимает, что им заинтересовались и дела идут как надо. Он доволен, мотивирован и с большей вероятностью найдет время на тестовое.

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

Одно из классических тестовых заданий HFLabs: посчитать количество букв «а» в текстовом файле. Размер файла — 5 Гб, обычными редакторами его не открыть. (Раскрываю задачу с тяжелым сердцем, мы годами даем его кандидатам).

У такого упражнения десятки решений: можно нагуглить редактор, который таки откроет файл; использовать терминал; написать программу с потоковой обработкой.

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

С помощью тестового задания мы одновременно проверяем внимательность и дотошность человека.

Мы намеренно не говорим, какую именно «а» считать в текстовом файле: латинскую, кириллическую, прописную, строчную. Или все сразу. Некоторые кандидаты совсем не обращают на это внимания. Некоторые обращают, но не уточняют задание и делают как бог на душу положит.

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

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

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

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

При этом особенно важно, учтет ли кандидат комментарии к первому решению.

Допустим, человек был невнимателен и посчитал в тексте только кириллические «а». В следующее задание мы обязательно вкрутим похожий крючок. И посмотрим, скорректировал ли кандидат подход. Применил ли новые знания. Так мы проверяем, умеет ли человек слушать.

Умение общаться едва ли не важнее технических навыков

HFLabs ставит не на количество ресурсов, а на эффективность их использования. Поэтому наши команды горизонтальные, гибкие и небольшие — максимум по 8 человек. Штука в том, что иерархия и руководители дороги в обслуживании. А команды, построенные на горизонтальном прямом взаимодействии, — эффективнее и рентабельнее. Но только при условии, что специалисты взаимодействуют как надо, поэтому софт скиллс очень важны.

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

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

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

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

У таких игр нет единого рецепта победы. Зато есть рассуждения и цепочка решений, которые раскрывают личность кандидата. С их помощью мы понимаем, комфортно ли взаимодействовать с новичком. Совпадают ли наши взгляды и ценности.

Мы ищем проактивных людей, потому что с ними команды растут

Еще одно качество, которое важно в кандидатах — проактивность. Без нее не собрать команду, склонную к самоулучшению: с четкой обратной связью между коллегами, итеративной оптимизацией процессов, «взрослением» отношений. Команду, которая со временем сама по себе становится эффективнее.

Проактивность мы проверяем мотивационными вопросами.

Работают как прямые вопросы: «Зачем ты идешь на работу утром?», так и косвенные: «Что самого крутого ты сделал за последний год?».

Спрашиваем об этом примерно через полчаса после начала интервью, когда человек привыкнет и расслабится. Из-за этого, кстати, собеседования длятся не меньше часа.

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

Чтобы еще лучше узнать софт скиллс кандидата, мы проводим несколько интервью. Обычно два. От HFLabs участвуют в сумме 4-6 интервьюеров, на каждом собеседовании — разные. Если с нашей стороны поступит хоть одно «нет», человек получает отказ.

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

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

Никакого buddy при онбординге, мы за открытую среду

О процессе онбординга мы уже подробно писали на «Хабре».

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

Квест снижает нагрузку на команду, потому что новичок по сути онбордит себя сам. Ветераны только помогают. Задания формализованы в Confluence, вот несколько примеров:

• «Разверни приложение с нуля и воспользуйся API для создания клиента»;

• «Найди Пашу и задай ему три вопроса о прослушанной лекции»;

• «Выбери заказчика и найди у него две особенности в модели данных».

При этом мы не используем популярную практику buddy — коллеги, которого «прикрепляют» к новому сотруднику для помощи и поддержки. Наоборот, предоставляем открытую среду: задавать вопросы можно всем и у всех можно просить помощи. При этом новичок уверен, что никто из коллег его не отфутболит — это важная часть культуры HFLabs. Стесняться и опасаться нечего.

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

KPI — это вспомогательные метрики, а не мера успешности

Когда соберешь горизонтальную команду из проактивных ребят, уже не получится давать им задачи «потому что надо». Они будут кайфовать, только если каждый заинтересован в проекте. Если понимает, для чего выполняет каждое задание.

Такой подход нравится не всем работодателям. Кто-то удивится: «Это что же, я наберу людей, а потом буду еще придумывать для них интересные задачи, уговаривать работать? Да зачем это надо». В этом случае годится классика: набрать дисциплинированных исполнителей, четко следующих регламентам, и ставить задачи как удобно. Такое тоже работает, просто нам хотелось по-другому.

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

Мы учитываем характер сотрудников: некоторым нужно четкое описание, другие любят открытые формулировки.

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

А еще мы работаем без KPI. Ключевые показатели всегда можно хакнуть так, чтобы по метрикам выглядеть гигантом, а реально заниматься невесть чем. Чтобы нащупать стратегию, нужно только время. А потом вся система подстраивается под достижение показателей: команда стремится не к лучшему продукту или счастью заказчиков, а к наибольшим KPI. Мы так не хотим.

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

Коллеги — обычные люди, а не супергерои

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

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

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

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

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

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

Главный шаг — доверие на всех уровнях

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

Из практик наши менеджеры используют «Выход в гембу» или «Управление через случайные прогулки по офису». Для нас такой контроль работает лучше жестких отчетов и KPI.

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

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

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

Чтобы понять вектор, сравнивают поставленные в прошлый раз цели с фактом. Например, специалист думал так: «Буду крутым саппортером, прокачаю нужные скиллы. Не хочу быть лидером и строить процессы». Смотрим через год: по факту человек — полноценный лидер, мотивирует коллег и тащит на себе изменения в процессах. Обсуждаем это и меняем вектор: новая цель — прокачивать лидерство. Конечно, если сотрудник согласен.

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

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

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

Открытость компании драматически повышает качество работы. Ребята работают на максимуме в пределах зоны комфорта. Плюс мы очень стабильны, из HFLabs уходят, по большому счету, только в big names. Обычно зарубежные. Мы неплохо чувствуем себя даже во время пандемии. Так что пока не меняем принципы, какие бы модные книги ни выходили и что бы ни проповедовал Netflix.