Охота на Python-разработчика: воронка найма, фильтры и тестовые задания

За последние годы Python закрепился в числе самых популярных языков программирования, а спрос на «питонистов» стремительно растет. По оценкам одного IT-агентства, дефицит Python-разработчиков увеличивается на 15–20% в год (источник devsandcats.com). Однако найти подходящего кандидата непросто: на одну позицию может откликнуться множество людей, и лишь единицы дойдут до финиша – получения оффера. Процесс найма всё больше напоминает прохождение кандидатов через воронку, где на каждом этапе срезаются лишние. Как выстроить эту воронку эффективно – используя фильтры и тестовые задания, но не отпугнув сильных специалистов?

Воронка найма: от 68 резюме до 1 оффера

Цикл подбора персонала действительно работает как воронка продаж (источник vc.ru). Сначала мы привлекаем или собираем широкий пул кандидатов, затем шаг за шагом отсеиваем тех, кто не подходит, пока на выходе не останется один победитель. На каждом этапе есть целевое действие – выбрать тех, кто пройдет дальше. Воронка наполняется новыми кандидатами, пока компания не найдет нужного человека и не закроет вакансию.

Как выглядит такая воронка на практике? По данным рекрутингового агентства devs&cats, типичный найм Python-разработчика начинается примерно с 68 резюме в базе. После первичного контакта остается 32 потенциально заинтересованных кандидата. Затем рекрутер проводит порядка 10 предварительных интервью (например, собеседования в агентстве), и лишь около 5 человек доходят до финальных интервью у заказчика.

В итоге из этих пятерых, как правило, выбирается только один специалист, которому делают оффер. Выходит, эффективность такой воронки – менее 2% от первоначального числа откликнувшихся. Для работодателя это означает необходимость переварить большой поток резюме и собеседований, прежде чем найти «того самого».

Интересно, что опытные тимлиды стараются делать процесс найма максимально эффективным. Предприниматель и айти-лидер Андрей Мкртчян делится правилом: «По внутреннему барометру я провожу до трех собеседований, чтобы закрыть одну позицию. Если больше – значит, где-то в процессе мы сильно накосячили», – отмечает он. Иными словами, затягивание найма и слишком широкая воронка могут сигнализировать о проблемах: неправильно настроены фильтры или невнятно сформулированы требования, из-за чего много лишних кандидатов проходит лишние этапы.

Фильтры на старте: где искать и кого звать

Первый уровень воронки – это поиск и отбор резюме. Здесь важно правильно заложить фундамент: где разместить вакансию, как описать требования и как отсеять заведомо несоответствующих кандидатов. Казалось бы, Python-разработчиков очень много – на популярных сайтах резюме их «over 9000» штук. Но это обманчивое впечатление. Во-первых, не все они активно ищут работу (многие уже заняты).

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

На этом этапе многое зависит от правильного выбора канала поиска. Общие сайты вроде HeadHunter или Work.ua генерируют слишком большой поток случайных откликов, среди которых тонут подходящие специалисты. HR-ы шутят, что на таких площадках приходится разгребать горы мусора. Куда эффективнее специализированные ресурсы для айтишников.

«Джинни и Хабр отлично работают, так что лучше добавляйтесь туда» – советует автор на vc.ru. Действительно, платформы вроде Djinni, Habr Career, профильные Telegram-чаты или узкотематические форумы притягивают более целевую аудиторию Python-разработчиков. Потратив время на грамотное описание вакансии и размещение ее в правильных местах, вы обеспечите более качественный «вход» воронки.

Критически важна и формулировка требований. Прежде чем звать людей, стоит точно определить, кто вам нужен: технологии (Python, Django, Flask или maybe data science stack?), опыт (junior/middle/senior), soft skills, знание языков, формат работы и предлагаемая зарплата. Эта ясность убережет от ситуации, когда вы сами не до конца понимаете портрет кандидата, копируете чужой шаблон вакансии – и получаете поток нерелевантных откликов. Чем четче портрет, тем тоньше сито на входе.

После публикации вакансии (или параллельно с активным поиском по резюме в базе) начинается первичный отсев. К счастью или к сожалению, значительная часть кандидатов отсеется уже на этой стадии. Много резюме отсеиваются автоматически или при беглом просмотре по очевидным причинам. Андрей Мкртчян делится наблюдением: около 60% резюме отпадают из-за того, что профайл заполнен кое-как (не указаны важные данные, кривое оформление), еще 20% — просто люди не по профилю, и еще 20% отпугивают каким-нибудь странным «романом о себе» в сопроводительном тексте.

Нередко встречаются пустые профили без описания опыта – или наоборот, простыни текста, где много лишнего. Словом, кандидат может сам себя зарубить на этапе резюме, не проявив должного внимания к его содержанию. Поэтому соискателям совет: составляйте резюме аккуратно и по стандартному шаблону. Никого уже не впечатляют вычурные дизайнерские PDFки – HR скорее оценит структурированный профиль на том же Habr Career или LinkedIn, где нужные факты на своих местах.

Рекрутер же на этом этапе применяет свои негласные фильтры. Кто-то может «неполиткорректно» отсеивать кандидатов из определенных регионов – например, если компания не сможет юридически оформить удаленщика в той стране. Другие фильтры – явное несоответствие опыта заявленной роли (например, человек весь путь был системным администратором, а откликнулся на позицию Python-программиста без опыта кодинга), либо наличие тревожных сигналов. Порой в разделе «О себе» можно вычитать и обиды на бывших работодателей, и чрезмерное бахвальство, и даже странные tirades вроде «ваша технология устарела, я сделаю лучше». Такие вещи – красные флажки, часто служащие поводом прекратить общение с кандидатом на корню.

Звонок и собеседование: проверяем мотивацию и навыки

После отбора перспективных резюме наступает этап личного общения. Обычно сначала звонит рекрутер или HR-специалист – короткий разговор 5–15 минут. Несмотря на непринужденный формат, это тоже важный фильтр. «Даже 5 минут узнать, как дела – это уже фильтр», отмечает Мкртчян.

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

На первичном звонке важно прояснить и мотиваторы/демотиваторы кандидата. Различные детали могут стать решающими: индустрия проекта (кто-то ни за что не пойдет делать финтех или, скажем, игры для казино), размер компании (не все любят стартапы, и наоборот, не всем по душе корпорации), график и часовые пояса, возможность работать из офиса или строго удаленно. Бывает, именно на этапе скрининга всплывают такие нюансы. Опытный рекрутер сразу «считает» настроение: если человек отвечает неохотно, путается в своем опыте или, скажем, откровенно забыл, что откликался к вам – тревожный сигнал. Зато заинтересованный кандидат задает встречные вопросы, уточняет детали – это хороший знак мотивации.

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

Например, есть известный сборник «150 вопросов для Python-разработчиков» – своеобразный FAQ по ключевым темам, от базового синтаксиса до тонкостей GIL и фреймворков. Некоторые руководители признаются, что провели сотни технических интервью за карьеру, и со временем отточили свои любимые вопросы. Однако лучший результат дает не формальный допрос по списку, а живое обсуждение реальных задач. Хороший интервьюер стремится понять ход мыслей кандидата: как тот подходил к решению проблем на прошлых проектах, почему принимал те или иные технические решения.

Важно отметить: технические навыки – не всё. Часто решающее значение имеют личные качества и умение вписаться в команду. “В целом, софты > хардов”, – утверждает Андрей Мкртчян. Он предпочитает брать в проект эмоционально зрелых, ответственных людей, даже если им не хватает знания какого-то фреймворка – ведь технологии можно быстро подтянуть, а вот взрослый подход к работе не обучишь за неделю. Действительно, ИТ-сфера так динамична, что конкретный техстек вторичен: через полгода всё может измениться.

Куда ценнее способность кандидата учиться и адаптироваться. Поэтому на собеседованиях всё чаще уделяют внимание вопросам про прошлый опыт (чему научился, как выходил из сложных ситуаций), про ошибки и выводы, про командное взаимодействие. Если человек с пеной у рта спорит, что “только React спасет мир, а всё остальное от лукавого”, велика вероятность, что перед вами узкий максималист, которому будет тяжело принять иной подход. Для зрелого разработчика же характерно уважение к чужому мнению и разнообразию инструментов. Такого легче встроить в любую команду.

В процессе основных интервью воронка сужается до финалистов – обычно 1–3 человек, из которых предстоит выбрать. Иногда компании назначают дополнительное интервью с руководителем или фаундером, либо командное собеседование, чтобы понять культурный фит. Если позиция критичная, могут даже пригласить кандидата на день-другой поработать с командой (trial day) или дать тестовое задание, о котором подробно далее. В небольших компаниях лишних этапов стараются избегать, понимая, что каждый новый шаг – это трение, шанс упустить человека к конкурентам. Чем длиннее процесс найма, тем больше риска, что сильный кандидат уйдет на другую оффер – об этом напоминают все HR-специалисты (источник habr.com).

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

Бывают люди отказывают по своим причинам – пришел другой оффер или изменились условия на текущем месте работы», – рассказывает Мкртчян. Такие ситуации особенно обидны, когда до финиша дошел один фаворит: компания теряет время и остается ни с чем. Чтобы не ставить всё на одну карту, опытные HR стараются держать в запасе нескольких финалистов или хотя бы продолжать воронку, пока оффер не подписан.

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

Дать ли задачу соискателю, чтобы проверить его навыки в деле? Или полагаться на собеседование и портфолио? Мнения профессионалов разошлись.

Тестовые задания: сокращают воронку или отпугивают кандидатов?

Тестовое задание – классический инструмент в IT-рекрутменте, но вокруг него не утихают споры. По свежей статистике, примерно две трети соискателей сталкивались с необходимостью выполнить тестовое при приеме на работу (источник habr.com). Большинство кандидатов в принципе готовы взяться за задачу: в опросе 89% респондентов ответили, что согласны сделать бесплатное тестовое, и лишь 11% отказываются категорически. На практике же, когда речь доходит до реальной вакансии, оказывается, что почти все – 92% – таки выполняют предложенное задание.

Казалось бы, отличная новость для работодателей: кандидатам не впервой, они не против. Но дьявол кроется в деталях. У многих есть критичные условия, при которых энтузиазм мгновенно испаряется.

Вот самые важные «нет» для соискателей, связанные с тестовыми (данные того же опроса): если задача занимает больше 8 часов – это неприемлемо для 90% опрошенных! Более половины (56%) против, когда тестовое представляет собой фактически законченный проект (то есть по объему близко к боевой задаче). Даже 4–8 часов бесплатной работы уже вызывают протест у значительной части кандидатов.

Среди прочих факторов отказа называются: несоответствие задания заявленным навыкам вакансии, выдача тестового до любого общения (когда тебя сразу «на домашку», не познакомившись), и откровенно слабое описание задачи. Интересно, что даже оплата тестового не снимает всех вопросов: 45% респондентов все равно откажутся, если им предложат делать полноценный проект на много часов. Иными словами, кандидаты готовы писать код за ваши деньги, но не хотят быть бесплатными сотрудниками на две недели.

Зачем вообще компании дают тестовые задания? В идеале – проверить навыки претендента, увидеть, как он справляется с типичной работой. Хорошее тестовое действительно способно лучше любых фильтров отсеять неподходящих людей. Лид-разработчик Макс (IdaProjects) отмечает: это мощный инструмент найма, который при грамотном использовании экономит кучу сил и времени команды.

Представьте, вы получили сотню откликов. Вместо того чтобы созваниваться со всеми и часами разговаривать, вы разослали задачу – и получили обратно лишь десяток решений. Остальные отсеялись сами: кто-то не захотел делать, а кто сделал плохо – тоже сразу видно. Таким образом, воронка кандидатов резко сужается без активного участия HR-ов.

Однако у тестовых есть и обратная сторона. Во-первых, их надо проверять. Каждое решение требует внимания экспертов, а ресурсы команды не бесконечны. Во-вторых, тестовые растягивают процесс найма. Пока кандидат делает задачу (обычно дают несколько дней), пока вы ее оцениваете – время идет. Если желающих много и у каждого своя "домашка", вакансия может подвиснуть на недели.

Как уже говорилось, лишняя длительность чревата потерей мотивации у соискателя или его уходом в другой проект. Наконец, есть риск отпугнуть сильных кандидатов. Пока новичку куда ни шло – ему порой без тестового никуда, – то классный middle или senior, особенно с работой на руках, может попросту не согласиться тратить выходные на вашу задачу. «Вероятность отказа от теста пропорциональна уровню специалиста», шутят рекрутеры. Действительно, чем ценнее профи, тем больше у него предложений – и тем меньше желание заниматься бесплатным трудом ради абстрактной вакансии.

Мнение самих разработчиков по этому поводу выразил, например, Константин Кислейко, дизайн-директор и бывший соискатель: «Тестовое почти никогда не покажет ничего такого, чего не видно по портфолио. Может, только мотивацию проверить, но проверять мотивацию у сеньора, заставляя его бесплатно работать, – это глупо». По его словам, если у кандидата приличный track-record, все хард-скиллы уже видны в его прошлых проектах, а решать головоломки «на скорость» – занятие сомнительной пользы. Он также подмечает, что soft skills коротким тестовым не проверить: как человек общается, воспринимает критику и стресс – это вскроется только в реальной работе, ради чего и существует испытательный срок.

Несмотря на критику, многие компании продолжают использовать тестовые. Как быть? Здесь важно найти баланс и уметь готовить «домашки» правильно. Эксперты сходятся на том, что если уж давать задание, то оно должно быть коротким и по делу. Алексей Илларионов, фронтенд тимлид, советует: «ТЗ должно быть таким, чтобы его можно было сделать за 2–3 часа».

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

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

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

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

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

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

В целом, тестовое задание – это инструмент, а не догма. Цель ведь не в том, чтобы заставить всех непременно писать код «на конкурсной основе». Цель – найти подходящего Python-разработчика, затратив разумные усилия. Поэтому самые прозорливые нанимающие менеджеры всегда держат в голове альтернативные пути.

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

Вместо заключения: как не потерять лучших в процессе найма

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

Что этому способствует? Во-первых, четкое планирование этапов: от качественного описания вакансии до оперативного фидбэка после интервью. Прозрачность для кандидата тоже важна – люди ценят, когда им сразу сообщают, сколько будет стадий, будет ли тестовое, какие сроки рассмотрения. Во-вторых, постоянная оптимизация фильтров: анализируйте свою воронку, смотрите, где отваливается слишком много народу. Может, критерии на первом шаге слишком строгие и отсеивают даже подходящих? Или, наоборот, недостаточно строгие – и вы тратите часы на созвоны с заведомо не тех кандидатами.

Метрики конверсии по этапам и честный разбор случаев найма помогут улучшить процесс (источник top-career.ru). В-третьих, уважение ко времени кандидатов. Это и корректное использование тестовых заданий (только по делу и в разумных пределах), и грамотная коммуникация. К слову, многие компании практикуют обратную связь отказникам – например, коротко объясняют, чего не хватило. Мкртчян, правда, скептичен к такой практике, считая, что неудачно подобранные слова могут только демотивировать человека. Но хотя бы шаблонное «Спасибо, вы нам не подошли» – уже лучше, чем тишина.

И наконец, сохраняйте гибкость. Универсальных рецептов, как быстро нанять идеального Python-программиста, нет – если только не переманивать их за золотые горы. Где-то сработает широкий пост в соцсетях, а где-то – точечный поиск по LinkedIn. Одного привлечет формат удаленной работы, другого – технология проекта или имя бренда.

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

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