Идеальная вакансия для разработчика

09ea9dbb27372f28c4369b962cb5e15e.png

Привет! Хочу поделиться своим мнением об оформлении вакансий по поиску разработчиков. Я сам разработчик, руководитель команд в разных компаниях, составлял вакансии и нанимал. Часто вижу вакансии, которые никогда не будут успешны.

Плохая вакансия

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

Чем это чревато:

  • Часть потенциальных кандидатов просто-напросто игнорируют такие вакансии, хотя их ценности и желания могут совпадать с тем, что предлагает компания. Компания теряет кандидатов.

  • Если ценности и желания не совпадают с тем, что предлагает компания, кандидат должен узнать об этом как можно раньше, желательно, на этапе отклика. Если кандидат отсеется на этапе собеседования, компания потратила время рекрутеров и разработчиков.

  • Плохая вакансия размещена на платных ресурсах на потенциально больший срок. Компания тратит больше денег.

Примеры плохих вакансий: DOU, HH, Djinni, LinkedIn. Если вы смотрите ссылки, а вакансии внутри не доступны, значит, прошло уже много времени с момента публикации статьи.

Хорошая вакансия

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

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

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

Плохо: молодой международный быстроразвивающийся проект, лидер на рынке доставки продуктов питания.

Хорошо: EasyFood — это мобильное приложение, где можно заказать доставку продуктов из магазинов на дом. Покупатель выбирает продукты, заказ берет один из курьеров, едет в магазин, набирает продукты и привозит по адресу. Наши пользователи — покупатели и курьеры. Мы сотрудничаем с магазинами типа Ашан, Магнит, Билла. Наша цель — сделать доставку продуктов доступной и быстрой для каждого.

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

Плохо: не указывается.

Хорошо: 2 миллиона пользователей, 15 миллионов доставок в месяц. К концу года мы планируем уменьшить time to house на 20 процентов, до 40 минут и делать 20 миллионов доставок в месяц.

Команда. Расскажите про работников компании.

Плохо: талантливый и дружный коллектив.

Хорошо: над продуктом трудится несколько команд (в сумме больше 50 инженеров): фронт-энд, бэк-энд, бизнес-аналитики, дата-сайентисты, тестировщики, мобильные разработчики на iOS и Android, product и project менеджеры, фаундеры активно принимают участие в процессах. Ты будешь работать в команде из 4 дата-сайентистов, будешь активно взаимодействовать с вышеперечисленными командами каждый день.

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

Плохо: не указывается.

Хорошо: покрываем 100% кода тестами на pytest; поддерживаем 25 микросервисов, написанных на Go, Python, и Java, в GCP c Kubernetes; для хранения кода используем Github.

Требования. Указывайте четко сформулированные и реальные требования к кандидату.

Плохо: Python, Django, PostgreSQL, знание микросервисов, самостоятельность.

Хорошо: знает Python не только в контексте фреймворков; был опыт написания веб-приложений и RESTful API; знает и умеет масштабировать базы данных; знает как мониторить и оптимизировать запросы к базе данных; понимает преимущества и недостатки микросервисной архитектуры; может собрать и прояснить требования, написать код и покрыть тестами, развернуть на продакшене.

Будет плюсом. Указывайте, что вы еще цените в кандидатах, на случай, если он не подходит по некоторым основным требованиям.

Плохо: не указывается.

Хорошо: опыт работы в продуктовых компаниях; свои open source проекты либо вклад в чужие; английский на уровне Advanced (C1).

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

Плохо: интересные проекты.

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

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

Плохо: команда профессионалов, нет бюрократии.

Хорошо: выбор технологий и методологий управления проектам на свой вкус, у нас нет менеджмента между разработчиками и бизнесом, плоская структура.

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

Плохо: не указывается, либо указывается с большим разбросом типа $1500–4500, что, зачастую, сигнал для кандидата о недобросовестности компании.

Хорошо: указывается, с маленьким разбросом $2500–3300, или вообще без.

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

Плохо: не указывается.

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

Ссылки. Познакомьте кандидата с вашей компанией, продуктом, командами, культурой заранее.

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

Хорошо: кратко и понятно о самой компании от фаундера можно найти здесь (ссылка); наши ребята из команды бэк-энд активно выступают на конференциях, посмотреть можно здесь (ссылка).

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

Заключение

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

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

© Habrahabr.ru