В поисках Нео
В продолжение первой части нашей эпопеи о поиске и интеграции джунов в команду.
В этой статье я хочу поделиться опытом формирования вакансии, вернее её внешнего вида. Я постараюсь рассказать как сделать вашу карточку вакансии максимально привлекательной, честной, и, что немаловажно, информативной.
Как и в первой части, я напомню, что лишь делюсь опытом и высказываю своё мнение. Не более того.
Составляем карточку вакансии
Один из самых важных критериев успешности ваших поисков — выбор правильной HR площадки.
Так как мы всё-таки работаем с IT сегментом, то я бы рекомендовал использовать Хабр Карьеру
В качестве дополнительных источников трафика можно рассматривать HH, LinkedIn (в РФ заблокирован), тематические тележные IT каналы, например хороший канал по поиску джавистов, мобайл разрабы, ну и личные ресурсы, если таковые имеются.
Название вакансии
Довольно важная вещь, я всегда рекомендую писать максимально коротко и по делу.
Если мы ищем фронтендера, то так и нужно писать — Frontend developer, однако, если вам хочется покрыть всевозможные кейсы, то у вас возникнут с этим проблемы, т.к. кейсов тут немало:
Ключи «developer» || «разработчик»
- Frontend
- Front-end
- Front end
- Фронтенд
- Фронт-енд
- Фронт енд
Тут либо тратить много денег (зачем?), либо пихать всё в один заголовок. Правда, потом прилетит НЛО и заберёт к себе в поликлинику, на опыты.
Квалификация
Тут всё зависит от того кого (а главное для чего) вы ищите. Если мы следуем теме нашей пасты, то это Intern/Junior. Не знаю зачем Хабр разделяет их и даёт возможность схалявить на интернах, но пусть так.
Я беру Intern когда ищу джунов для полного цикла обучения, так как по моим критериям Intern это тот, кто знает языковые азы, но ещё ничего не знает о технологической составляющей. Согласитесь, что таких куда проще и эффективнее получается учить, нежели начитанных ребят которые уже успели впитать в себя предрассудки и легаси прошлых поколений.
К Junior'ам я отношу ребят которые знают язык уже более продвинуто и знакомы с кухней современного веб-строя: ну там, React, Vue, Angular, хоть что-то из основной тройки; и которые уже в состоянии писать что-то похожее на веб-приложения. А в последнее время я в обязательном порядке ставлю в требования знание хуков, так как без них сейчас вообще никуда.
Вознаграждение
Считаю справедливым — стажёрам платить не менее ₽30к, а если ребята смышлёные и не боятся овертаймов и проявляют инициативу, да и вообще смышлёные не по возрасту — можно поднять и до ₽50к.
Для джунов считаю справедливым выставлять от ₽50к и до ₽70-80к, в зависимости от личных навыков. Всё в динамике, каких-то жёстких прайсов у меня не было никогда.
Поведаю об одном случае из практики: был у меня один джун, Сашей звали, верстал вроде неплохо, но, как дело доходило до работы со стором, логикой и «вот этим вот всем» — начинались тупняки, пропадания. Короче, парень просто сгорел и «исчез», написал спустя аж месяц с гаком, ну, т.е — таким вот ₽40к потолок,
Описание вакансии
Считаю важным описывать вакансию блоками, с разбиением на секции через заголовки, — улучшает читабельность вашей вакансии.
Тут каждый для себя решает, что важно, а что нет. У меня к примеру есть свой любимый шаблон:
О компании
Я стараюсь преподносить команду в максимально дружелюбном и неформальном стиле (насколько это возможно). Правда, раскрыть всю идею в одном абзаце не выходит, так как первый абзац (интро) не должно быть длинным, в противном случае ваша ЦА просто не увидит основные блоки в первые секунды (они самые важные) в которые вы должны «зацепить» человека.
Кого ищем?
В данном блоке я составляю примерный портрет человека, которого бы я хотел увидеть в команде. Кстати, о навыках и знании инструментов — об этом я также стараюсь упомянуть в этом блоке: к примеру, я пишу о том, что мы активно пользуемся фишками Github'a и надеемся, что наш новоиспечённый член команды тоже неравнодушен к нему.
В то же время, я стараюсь затронуть тему социальной активности. Например, человек может что-то писать в соц. сетях (это крайне редкое явление в наших кругах) и быть подписанным на топовых веб-дизайнеров на Behance и так далее. Ну, то есть — тут нужно максимально донести своё: «мне бы хотелось, чтобы ты это вот всё умел, да, а если бы не умел, то очень хотел».
Что делаем?
Тут нужно постараться рассказать про основной вид деятельности команды. Обычно я пишу обобщённо, стараясь донести в каких сферах мы работаем и какие направления предпочитаем. Ну, то есть, я пишу, что мы любим пилить различные *aaS, eCommerce, B2B, Digital проекты, ну и парочку примеров из того, что мы уже запустили или над чем работаем в паблике; для наглядности, так сказать.
Также, немаловажным является указание текущих проектов, на которых будет происходить «обкатка» джуна. Это важно ещё по той причине, что кому-то может быть не по душе Digital сфера, или кто-то так яро ненавидит реп, что ни при каких обстоятельствах не согласится работать над подобным проектом.
Что не любим?
Считаю важным писать про вещи типа: «что любим»/«что не любим». Так вы сможете отсеять людей не подходящих вам по духу. Например, я так отсеивал людей которые задавали вопросы в духе: «Мы же отдыхаем в День России?», «У вас ведь 8-и часовой рабочий день?» или людей которые явно (или не очень) котируют тот или иной инструмент, который мы предпочитаем обходить стороной.
С чем работаем
Обычно тут расписываю текущий используемый стэк технологий и инструментов с которым предстоит познакомиться и начать работать.
Отдельное внимание я уделяю Github и Octokit
Смысл в том, что у гитхаба отличный поиск, есть экшены и собственное API и знание этих вещей необходимо для нашей работы, а потому об умении, или наоборот — неумении работать с Github лучше всегда знать заранее, так как от этого будет напрямую зависеть дальнейший флоу работы с джуном
Бонусы
Не знаю кто какие бонусы ставит, но я всегда топлю за использование яблочной техники на работе, и для тех, кто смог продержаться чуть больше испытательного срока, я предоставляю конфиг на выбор; в рассрочку, без процентов и сроков, на любой удобный срок.
Кстати, на днях я всё же решил начать поощрять здоровый образ жизни, так как рассказы моих ребят: о непрекращающихся головных болях, потере концентрации, усидчивости, хреновом сне и прочих издержках нашего ремесла меня порядком поддостали.
Я и раньше об этом думал. Правда, вопрос был в целесообразности и ресурсах. Ресурсы появились, а целесообразность никуда не пропала — парни всё также болеют, филонят в метеокритические дни и т.д.
Поэтому в бонусы (особенно для разработчиков и прочих «седоков») я бы включил оплату расходов на ведение здорового образа жизни. Само собой, всё обсуждаться будет индивидуально, так как кто-то не может плавать, а кто-то бегать, а кому-то поднимать тяжести нельзя ну и т.д.
Короче, заботьтесь о своих падаванах, иначе у вас будет постоянная текучка.
Дополнительные инструкции или CTA
В первую очередь хочу обратиться к товарищам рекрутёрам и владельцам подобных компаний.
Всегда! Нет… Никогда! Не пишите в своих вакансиях, чтобы соискатели что-то там писали вам на почту, да ещё и с примерами кода, последними проектами и прочей чушью! Почему? Да потому, что это всё есть (по крайней мере должно быть) на ресурсе, на котором, собственно, и размещена вакансия. Ну, то есть — подобные ресурсы создаются, чтобы избежать вот этих вот избыточных, промежуточных, нахрен не сдавшихся, звеньев, а некоторые, «особо-одарённые» рекрутёры нивелируют все старания подобными требованиями.
Живой пример был сегодня: написала мне некая Katlyn из компании BlueReceipt — очередные горе-интеграторы Shopify.
Предложила «скипнуть» 1 этап и перейти сразу к «30-и минутному тесту по JavaScript», дабы убедиться в моей компетенции. Мало того, что сайт кривой: линки не пашут, а в некоторых местах тупые грамматические ошибки, так ещё и кадры тупые.
……
Нет. Ок. Приемлемо. Но, не когда человек приходит ко мне через профайл на CodersRank
Вот так делать не надо. Если вы используете средства для автоматизации рутинных задач — используйте и не задалбывайте людей своим ретроградством и тупизной.
В дополнительных инструкциях я строго наказываю в отклике оставлять ссылку на решённое вводное задание, остальное по желанию.
Все отклики без ссылок на форки с решённым вводным я просто удалял. Итого на последней вакансии было 90 человек, которые оставили отклики.
Из них 35 мусорные, остальные — решившие вводное, но, либо не прошедшие интервью, — да, бывают и такие, кто хочет, вопреки рейту, вакансии больше или начинают торговаться, — таких сразу гоню в шею, либо не решившие тестовое, прискорбно, но НЕ решивших вводное оказалось, если верить статистике гитхаба — почти 1000 человек! Это те, кто форкнул и удалил/закрыл репу.
Если вы асилили и дошли до этой части — поздравляю, так как, пожалуй, это самое интересное место в этой статье.
Вводное и тестовое задание — не одно и то же
Последние 4 года хантинга научили меня «не принимать поток» на себя. Я проанализировал эти годы: подсчитал сколько месяцев я просрал на собесы, тестовые и прочее дерьмо и пришёл к выводу, что так делать нельзя, так как эти месяцы — убытки в миллионы (из расчёта моей ставки).
Было принято решение сделать с ребятами репу с полноценным бэкенд и фронтенд сервисами…и сломать.
Тут вероятно стоит немного прояснить.
Тест было принято разбить на вводное и тестовое.
Я применяю подход monorepo для большинства наших проектов.
Поломав рабочую монорепу, я создал вводное задание.
Поломав местами redux и кое-какие куски кода, было придумано тестовое для фронтендеров, ну и, само собой, таким же образом появилось тестовое для бэкендеров.
При том, для фронтендеров условия были куда лучше, нежели для бэкендеров, так как для фронтендеров я поднял на нашем техническом домене полноценное, работающее GraphQL API, чтобы они могли нормально работать.
Бэкендерам повезло меньше: на тот момент я не смог придумать как отдать им рабочий фронт без подключения нашего штатного devops окружения, и не спалив при этом рабочий фронт для проходивших тестовое в соседней папке.
Решение появилось, но уже после старта.
Отдельно про бэкенд могу сказать следующее: задание было очень сложным, однако, нашлись те, кто его осилил, а на таких и была сделана ставка. То есть, ребята, которым интересен подобный стек: Typescript, NestJS, GraphQL, CQRS, Protobuff, gRPC, *DD… таких оказалось всего двое.
Подытожим
В завершении второй части могу сказать лишь следующее:
- старайтесь оптимизировать траты вашего времени за счёт подобных решений, это не только сэкономит вам время, но и проверит некоторые личные качества кандидатов, которые собираются у вас учиться, а софт скиллы не менее важны в нашем деле
- если хотите собрать дружную команду на долгосрок — делайте так, чтобы люди были счастливы, и дело тут даже не в высокой ставке, так как зачастую народ просто просирает деньги неизвестно куда, а потом жалуется, что сидит на дошиках — это не дело, скажу я вам! Поощряйте здоровый образ жизни, занятия спортом, закупайте раз в полгода-год нужную и полезную для работы технику, или какие-то плюшки на ДР ваших «маленьких помощников» которые просто сделают работу более комфортной
- не тупите! и не заставляйте людей заниматься ненужной рутинной, отправлять вам какие-то письма на какие-то там ящики, высылать инфу о последних проектах. Если вас заинтересовал какой-то человек и вам так нужно — соберите инфу о нём сами, благо в 2020 живём
- следите за развитием своих людей, это очень важно, ведь ни сегодня так завтра вы окажетесь на грани кадровой пропасти из-за того, что ваши парни не развиваются
В третьей части я расскажу как правильно интегрировать джунов в командный процесс и помочь им освоиться в новой (а может и первой) команде.