Компания IT-One специализируется на решении задач для госсектора и российского бизнеса. Например, моя команда занимается созданием распределенного высоконагруженного сервиса. Цепочка интервью (с рекрутером, с техническим специалистом, с менеджером проекта) нацелена на оценку и хард, и софт скиллов. В нашей сфере оба этих аспекта крайне важны. Как мы ищем сильных технических специалистов и при этом командных игроков, для работы госпроекте?

Техническая оценка

Мы набираем в команду как backend-разработчиков (самые востребованные — пишущие на Java), так и фронтендеров — в основном владеющих фреймворками React и Angular.

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

Первый блок параметров для оценки backend-специалистов посвящен знанию основ объектно-ориентированного программирования. Второй – непосредственно Java. Мы анализируем базовые знания, владение современными версиями языка, понимание внутреннего устройства памяти JVM и основ многопоточного программирования. В третьем блоке — Spring — идёт разговор про один из популярных фреймворков в промышленной разработке.

Четвёртый блок касается работы с базами данных: реляционными и NoSQL. Мы выясняем, как разработчик взаимодействовует с базами данных и насколько в этой теме ориентируется. Предлагаем решать конкретные задачи, чтобы посмотреть, какого уровня запросы к базам он может написать. А также оценить его опыт работы с транзакционными системами.

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

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

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

Что касается frontend-специалистов?

При проведении технического интервью мы ждём от кандидатов наработаю в госпроекте отличных знаний Javascript и браузерного API, а также понимания работы событийного цикла. Это помимо базовых навыков верстки.

Практические задачи на техническом интервью стараемся приблизить к реальным жизненным ситуациям. Это даёт возможность специалистам проявить себя с лучшей стороны. В качестве основных фреймворков мы выбираем React или Angular в связке с TypeScript. Предпочтение отдаем людям с опытом проектирования и разработки высоконагруженных систем и навыками оптимизации frontend-приложений.

Наши приоритеты

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

1. Умение работать с проектным решением и архитектурной схемой развёртывания. Архитектор создаёт проектное решение, по которому потом будет строиться вся работа. Хорошо, когда у разработчика уже есть опыт в проектах с подобной организацией. Тогда, как показывает наша практика, ему легче «влиться» в процесс.

2. Работа с высоконагруженными сервисами. Мы узнаём, с какими технологиями человек работал, понимает ли он, что такое высоконагруженный сервис, в чём архитектурные отличия между высоконагруженным сервисом, выдерживающим постоянную нагрузку 10 000 запросов в секунду, и тем, который обрабатывает 100 запросов в день.

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

Профессиональный портрет

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

«Расскажите о проектах, в которых работали. Какие сложные или интересные задачи приходилось решать?»

Задавая этот вопрос, я оцениваю навыки самопрезентации. Если человек начинает говорить: «Я не знаю. Спросите лучше что-то конкретное» — это уже будет минусом, потому что если он не умеет/не хочет формулировать главное, то как потом будет отстаивать свою позицию по принятому решению или защищать предложенную оценку при работе над задачами?

«Что конкретно вы делали в проекте? Какого рода задачи выполняли?»

Этот вопрос помогает оценить реальный опыт. Бывает, что в резюме разработчик указал много разных навыков, и нужно подтверждение. Я также спрашиваю про стек технологий и по каким методологиям разработки он работал. В государственных проектах происходит сдвиг в сторону гибких методологий на Agile-принципах. Их знание будет большим преимуществом.

«Откуда вы получали задачи?»

Если в рассказе о себе это не прозвучало, то задаются уточняющие вопросы. Понимает ли он иерархию работы над проектом? Приходили ли ему в предыдущих проектах задачи от его более опытного коллеги, от тимлида, от руководителя проекта либо от аналитика? В зависимости от ответа на этот вопрос, я понимаю, в команде какого уровня он работал.

«Из каких специалистов состояла ваша команда? Кто за что отвечал?»

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

«Как представляете себе идеальный процесс разработки в проекте?»

Это важная информация для нас. Если мы возьмем человека в команду, я буду знать профессиональные задачи, которые он сам ставит перед собой и смогу встраивать их в план его личного развития. Проектам в госсекторе нужны лидеры и проактивные сотрудники — профессиональный рост на нашем рынке может бы очень быстрым. Поэтому, если специалист понимает, что хочет и может расти, то заявлять об этом лучше сразу. Скромность в нашем случае не уместна.

«Чего бы не хотелось видеть в процессе работы?»

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

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

Профессиональный портрет

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

«Расскажите о проектах, в которых работали. Какие сложные или интересные задачи приходилось решать?»

Задавая этот вопрос, я оцениваю навыки самопрезентации. Если человек начинает говорить: «Я не знаю. Спросите лучше что-то конкретное» — это уже будет минусом, потому что если он не умеет/не хочет формулировать главное, то как потом будет отстаивать свою позицию по принятому решению или защищать предложенную оценку при работе над задачами?

«Что конкретно вы делали в проекте? Какого рода задачи выполняли?»

Этот вопрос помогает оценить реальный опыт. Бывает, что в резюме разработчик указал много разных навыков, и нужно подтверждение. Я также спрашиваю про стек технологий и по каким методологиям разработки он работал. В государственных проектах происходит сдвиг в сторону гибких методологий на Agile-принципах. Их знание будет большим преимуществом.

«Откуда вы получали задачи?»

Если в рассказе о себе это не прозвучало, то задаются уточняющие вопросы. Понимает ли он иерархию работы над проектом? Приходили ли ему в предыдущих проектах задачи от его более опытного коллеги, от тимлида, от руководителя проекта либо от аналитика? В зависимости от ответа на этот вопрос, я понимаю, в команде какого уровня он работал.

«Из каких специалистов состояла ваша команда? Кто за что отвечал?»

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

«Как представляете себе идеальный процесс разработки в проекте?»

Это важная информация для нас. Если мы возьмем человека в команду, я буду знать профессиональные задачи, которые он сам ставит перед собой и смогу встраивать их в план его личного развития. Проектам в госсекторе нужны лидеры и проактивные сотрудники — профессиональный рост на нашем рынке может бы очень быстрым. Поэтому, если специалист понимает, что хочет и может расти, то заявлять об этом лучше сразу. Скромность в нашем случае не уместна.

«Чего бы не хотелось видеть в процессе работы?»

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

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

Широта кругозора

Работа над сложным госпроектом одновременно логическая и творческая и требует решения нестандартных задач. Считаю важным наличие высшего технического образования, оно подразумевает, что человек разносторонне развит. Он может чего-то не знать, но главное — он уже научился учиться и сможет добрать необходимые скиллы в процессе. Также интересуюсь профессиональными курсами, которые он закончил, лекциями/мероприятиями, которые посещал, например, онлайн, профессиональной литературой, прочитанной за последний год. Узнаю, что нового он хотел бы изучить, или в какой области углубить свои знания в ближайший период.

Проактивность

Проактивный разработчик, столкнувшись со сложной задачей, не теряет время, не ждет, пока руководители спросят, как у него дела. В идеале, он сам приходит за советом к более опытным коллегам, причем не только с «проблемой», но и с вариантами её решения. И получив совет от них, сам выбирает лучший вариант из возможных. Нам нужны инициативные люди, готовые, если нужно, взять на себя чуть больше ответственности, продвинуть новую идею или решение. Чем больше будет таких людей в команде, тем легче будет реализовывать масштабные проекты, где все быстро меняется и постоянно появляются новые требования, которые нужно оперативно брать в работу.

Умение работать в команде

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

Соответствие корпоративному командному духу, гибкость, открытость к новому и желание развиваться в масштабных ИТ-проектах — вот что для нас приоритетно, и именно таких людей мы ждем в нашу команду!

Источник: Tproger