Составление вакансии на junior позиции более тонкое дело, чем может показаться на первый взгляд. Связано это с тем, что у ребят без соответствующего опыта работы есть особые тараканы, которые могут повлиять на их решение откликаться или нет.
Как часто выглядит подобная вакансия:
Требования:
- уверенное знание Python 2.7 и Django 1.8+
- опыт работы с MySQL
- знание основ HTML, JavaScript, CSS
- опыт использования Git
- понимание MVC-архитектуры веб-приложений
- понимание ФП и ООП, знание базовых алгоритмов и структур данных
- понимание реляционных СУБД и умение писать SQL-запросы
- знание английского языка, достаточное для чтения технической документации
Плюсом будет:
- знание Flask, SQLAlchemy
- опыт работы с PostgreSQL
- знания Linux на уровне администрирования LAMP-сервера
- опыт проектирования баз данных
- опыт проектирования приложений
- знание Bootstrap/Angular/ReactJS
Этот текст я взял из публичной вакансии размещенной на hh.ru, потратив на гуглинг 3 минуты.
Прежде чем анализировать его, я расскажу о том, что пугает начинающих особенно сильно. Через Хекслет проходит много людей, и мы постоянно с ними держим контакт. Их самый большой таракан это “я слишком мало знаю, мне рано на собеседование”. Поняв эту проблему, я написал статью с описанием алгоритма поиска работы. Первый тезис в ней “не надо ждать”. Но в реальности это не работает. Практически приходится общаться с каждым индивидуально и объяснять, почему надо идти собеседоваться прямо сейчас.
Подписывайтесь на канал Кирилла Мокевнина в Telegram — чтобы узнать больше о программировании и профессиональном пути разработчика
С другой стороны, дополнительную сложность для таких ребят создают работодатели составляя вакансии подобно тому, что я привел выше. Главная проблема в том, что новички любую запись в требованиях воспринимают как “должен знать”. Обилие новых слов пугает их невероятно. С одной стороны, это может быть неплохо, если у вас большой поток и вам нужна селекция по принципу “возьмем наиболее уверенных”, с другой, если такого потока нет, то будет много потерь.
Главная рекомендация, которую мне хочется дать, — перестать требовать от джуниоров то, чем они по определению обладать не могут. Превратите требования в рассказ о том, чем занимается ваша компания, какие задачи решают люди, работающие по тому же направлению, и какие инструменты они используют в работе. А в разделе “требования” оставьте только ту базу, которая не связана с production опытом: алгоритмы, структуры данных, наличие учебных проектов на гитхабе, умение пользоваться linux, и тому подобное. Этот принцип мы стараемся максимально соблюдать на Хекслете.
Инструмент vs Концепция
Эту рекомендацию я посвящаю всем компаниям, которые пишут в требованиях обязательное знание JQuery, но, при этом, не упоминают, что нужно понимать DOM. Человек, понимающий, как устроена объектная модель браузера, выучит тот минимум JQuery, необходимый для работы, в течение пары часов во время решения задачи. При необходимости воспользуется браузерными возможностями напрямую или выберет для решения своей задачи какой-то другой инструмент. Человек, который целенаправленно учит JQuery, но даже не имеет представления о DOM (а таких немало, и все это благодаря тому, как мы составляем вакансии), будет любую задачу решать через JQuery, и самое страшное, что он не будет понимать что делает. Ситуация с JQuery просто катастрофическая.
Все это относится и к большинству других инструментов. Исключение составляют ситуации, когда вам нужен эксперт в какой-то конкретной технологии, но надо понимать, что эта технология будет явно на несколько порядков сложнее JQuery и даже фреймворков.
Неправильно
Требуется знание JQuery
Правильно
Требуется понимание DOM.
В своей работе мы используем JQuery. (написать не в требованиях)
Тестовое задание
Тестовое задание — это хорошо, публичное — еще лучше. Во-первых, хорошие тестовые задания делают вам рекламу, их решают просто так, потому что прикольно, и делятся ими. Во-вторых, тестовое задание может помочь начинающему разработчику преодолеть страх. Он может подумать “хм, а не так уж и сложно, возможно, я уже знаю достаточно чтобы его выполнить”. Не говоря уже о том, что спокойное решение такого задания в домашней обстановке гораздо более комфортно и не требует лишних коммуникаций. На гитхабе мы собираем коллекцию заданий от разных компаний.
Вопросы в вакансиях
Этот прием я встречаю не часто, но он мне нравится. Иногда в вакансиях (особенно если они расположены на своем сайте) сразу идут вопросы, которые позволяют не оценить знания (это важно!), а дать понять какой минимальный уровень знаний требуется и отсеять тех кто точно не подойдет. Например, вопрос может звучать так: “Какая алгоритмическая сложность у алгоритма, реализуемого этой функцией?”. Вопрос дан просто как пример, большинству не нужна такая академичность, но как иллюстрация подойдет.
Бриф после контакта
Если вы все-таки не можете себя остановить и хотите засунуть в вакансию что-то пожестче, то попробуйте вариант с брифом. После того как человек откликается, попросите его ответить на небольшой опросник, в котором, в идеале, только базовая оценка (шкалы или выбор) без необходимости писать свободный текст. Используйте его как способ отсеять неподходящих кандидатов, потому что определить глубину уровня таким способом крайне сложно (я не умею этого делать и не знаю тех, кто умеет).
Личные качества
Уже много говорилось про то, что писать “ответственный и целеустремленный” в требованиях не стоит. Добавить здесь нечего. Если у вас нет аналитики по тому, как оно влияет, то просто не добавляйте этих пунктов.
С другой стороны, мне симпатизируют компании, которые пишут в таком стиле:
Что мы хотим увидеть от кандидата:
- умение вовремя задать правильные вопросы к задачам;
- любовь к прекрасному в коде и понимание, когда необходимо идти на компромисс;
- не бояться ревью кода, комментариев к коду, пулл-реквестов, мердж-коммитов;
- здоровый пессимизм в оценке объёма и сроков работ, и бодрый оптимизм в реализации задач;
- привычка уделять небольшое время на разбор задачи, прежде чем бросаться в работу;
- интерес к новым инструментам и умение объяснить, почему их нужно срочно внедрить в рабочий проект.
