Знание библиотек работы с состоянием приложения flux, redux (желательно).
Опыт тестирования компонентов.
Опыт работы с TypeScript.
Знание принципов работы сборщиков Webpack, Gulp.
Итак, давайте приблизительно переведем на более понятный язык то, что мы сейчас прочитали:
● JavaScript (JS) — один из наиболее популярных языков программирования, на котором чаще всего делается пользовательский интерфейс (фронтенд-разработка).
● React.js — JavaScript-библиотека с открытым исходным кодом для разработки пользовательских интерфейсов, облегчает программирование на JS (в следующих главах мы подробно поговорим про то, что это такое).
● REST — это стиль архитектуры программного обеспечения для распределенных систем, отвечает за правила работы с URL-адресами страниц.
● HTTP — это протокол, с помощью которого клиент и сервер обмениваются данными. Например, когда мы нажимаем на кнопку «каталог» на сайте интернет-магазина, с клиентской части в серверную идет запрос, который просит показать необходимые данные.
● css3 — язык описания стилей: с его помощью создатель веб-страницы задает цвета, шрифты, расположение блоков и т. д.
● LESS, SASS — языки, созданные на основе css для реализации тех же целей — оформления веб-страницы.
● Flux, redux — это библиотека для управления состоянием приложений.
● TypeScript — расширенная версия JavaScript, которая позволяет упрощать и ускорять разработку крупных JS-приложений за счет добавления типизации, классов и модулей.
● Webpack, Gulp — инструменты, которые собирают разбросанные по модулям файлы проекта, объединяют в единые файлы в правильном порядке и ужимают их в размере.
Казалось бы, описание достаточно детальное. Но все равно вопросы остаются. Вот только некоторые из них:
● Какой новый функционал нужно будет разрабатывать конкретно? В обязанности входит только новый функционал или поддержка старого? В каком соотношении?
● Какого опыта разработки на JS будет достаточно? Задачи какого уровня кандидат должен уметь решать?
● Насколько критичен опыт с React? Готовы ли смотреть с другими фреймворками? А с нативным JS (то есть без использования фреймворков)?
● Насколько хорошо нужно понимать REST? Кажется, если кандидат с опытом, он априори понимает REST. Какого уровня тогда нам нужен специалист?
● Сам ли он будет верстать или есть верстальщики? Какой процент задач по верстке, какой — по разработке?
● Правильно ли понимаю, что flux — обязательное требование, а redux — опциональное? Готовы ли смотреть кандидатов без redux?
● Надо тестами код покрывать или целиком процесс тестирования проводить? Есть ли тестировщик в команде?
● Насколько критичен опыт с TypeScript? В сравнении с остальными технологиями, что из них важнее, без какой точно не будете смотреть кандидатов?
● Опять-таки возникает вопрос о требуемом уровне специалиста. Кажется, что большинство фронтов с Webpack работали.
На самом деле я просто показал вам, что по каждой строчке вакансии у нас могут быть вопросы — и это нормально. В этом нет ничего страшного, для многих заказчиков такой бриф — хороший знак. Хотя, конечно, в этой вакансии самая большая проблема — в тексте самой вакансии: он пустой и неинформативный. Как видите, я неспроста задавал все эти вопросы. По факту ответы на них помогут мне переписать довольно стандартный и пустой текст во что-то более информативное.
Чем больше опыта у вас будет, тем меньше понадобится приставать к каждому пункту вакансии и появится больше возможностей построить беседу так, чтобы одним вопросом охватить сразу несколько тем. Так, например, в данной вакансии основной вопрос — какого уровня специалиста мы ищем, потому что в тексте много базовых требований, а дальше мы уже могли бы переключиться на вопросы о задачах, команде и четче понять, кто нам нужен.
Очень важным шагом в завершении этих (да и любых) переговоров является закрепление договоренностей, то есть согласование профиля кандидата. После того как вы пообщались с заказчиком, можно прямо на месте уточнить: «Давай резюмируем. Правильно ли я понимаю, что нам нужен такой-то и такой-то кандидат, в идеале обладающий тем-то и тем-то. Но мы готовы также смотреть и тех, кто обладает только несколькими из вышеперечисленных пунктов, верно?»
После того как вы обсудите это устно, очень важно письменно закрепить договоренности и написать в мессенджере или письмом всё, что вы обсудили. И если впоследствии у вас возникнут сложности в работе и заказчик решит «переобуться», как это делают некоторые политики и общественные деятели, вы сможете сказать ему, что договаривались о другом и у вас «все ходы записаны». Делать это нужно не для того, чтобы «становиться в позу» и кому-то что-то доказывать, а для того, чтобы в случае возникновения прений вы могли отстоять свои границы, показать заказчику, что требования меняются и, вероятно, вакансия не закрывается не потому, что вы не сумели кого-то найти, а потому, что требования были не до конца сформулированы. (Если, конечно, это действительно было так.)