Всем доброго времени суток! На написание данной статьи меня натолкнул процесс найма Системного аналитика к нам в команду, который завершился месяц назад.

Процесс у нас состоял из 3 этапов: скрининг с рекрутером, техническое интервью и интервью с менеджером. Я же хочу рассказать о технической части, которую сам проводил.
Начнем с того, что рассматривали мы кандидатов, проживающих в Западной и Восточной Европе, Балканах, Грузии, Армении и искали мы крепкого синьора. Условия у нас хорошие: и в плане заработной платы и в плане задач и нагрузки, при этом компания не стартап, есть действующие продукты, которые генерируют прибыль, финансовая неустойчивость отсутствует. Всего мы получили чуть больше 100 откликов на вакансию по разным каналам, из этих 100 откликов релевантных резюме было около 20. На позицию системного аналитика присылали резюме разработчики, тестировщики, проджект менеджеры, люди с опытом в тех. поддержке, а иногда и школьные учителя и инженеры электростанций. Отсюда первый вывод:

Если вы видите очень много откликов на вакансии, это не должно вас пугать и наводить на мысль "В такую битву за позицию точно нет смысла влезать".

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

• 4-5 базовых теоретических вопросов;

• Задание нарисовать диаграмму, описывающую простой процесс (нотация и инструмент на усмотрение кандидата);

• Разбор небольшого блока кода на Java, нужно было очень верхнеуровнего рассказать, какую задачу этот код выполняет;

• Задача на написание простого SQL - запроса.

Теоретические вопросы

В данной части обсуждали с кандидатами технологии, с которыми им приходилось работать: языки программирования, фреймворки, интеграции, базы данных и т.д.
Практически все кандидаты заявляли у себя в резюме достаточно большой набор технологий, на по факту оказывалось, что кандидат про них либо просто слышал, либо эти технологии использовались на проектах, но кандидат не имел к ним отношения. Особенно часто это происходило с технологиями вроде Kubernetes, Openshift, AWS, Google Cloud.
Отсюда делаем еще один вывод:

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

Интеграции:

Практически все кандидаты работали с REST - интеграциями и смогли дать очень верхнеуровневое описание, но вот HTTP - протокол упомянули только 3 человека, а это достаточно важный момент в данном контексте. У многих кандидатов имеются достаточные знания, но не хватает систематизации, целостность картиные есть у единиц.
С SOAP на практике сталкивались и смогли рассказать о нем только 2 кандидата, что в целом не удивительно, т.к. SOAP сейчас встречается все реже и реже.
GraphQL и gRPC оказались самыми сложными темами и на практике аналитики сталкиваются с ними крайне редко. Для многих эти типы интеграций что-то совсем скрытое и не знакомое.

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

Базы данных:

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

Реляционные базы данных используются на большом количестве проектов, и с ними было меньше всего вопросов, так как большенство кандидатов знакомы с ними на достаточном уровне для Senior позиции.

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

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

Брокеры сообщений:

Про брокеры сообщений хоть что-то слышали 5 человек из всей выборки, но при этом никто не смог раскрыть, что такое producer, consumer, topic и т.д. Как оказалось, на практике аналитики редко сталкиваются с брокерами сообщений, при том, что используются они повсеместно. Про разницу Kafka и RabbitMQ тоже никто ничего внятного не сказал, ни про концепцию, ни про применение этих брокеров.

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

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

Задача на отображение бизнес-процесса посредством диаграммы

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

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

• Получаем данные от юзера через заполнение формы на фронте;

• Проверяем эти данные во внешнем источнике;

• В зависимости от результа предыдущего этапа либо останавливаем процесс, либо идем далее;

• Проверяем данные во втором источнике;

• В зависимости от результата, присваиваем юзеру определенный статус.

В основном кандидаты выбирали Sequence - диаграмму, что вполне подходило под данную задачу, из инструментов Draw io и PlantUML. В случае использования PlantUML допускалось пользоваться докой и подсматривать синтаксис.

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

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

Задача на чтение кода

Кандидату предлагалось разобрать простой блок кода на Java, в котором осуществлялся API - вызов во внешний сервис, и затем данные из респонса раскладывались в 2 объекта в БД.

Блок кода специально скорректировали, чтобы по ключевым словам можно было сразу понять, для чего нужен данный код. 4 кандидата смогли самостоятельно разобраться и объяснить, какую задачу решает данный код и верхнеуровнего описали, как он работает. (Именно это и требовалось) . Некоторые не смогли разобраться с ходу, но при этом задавали правильные вопросы и получали на них ответы, что в итоге привело их к решению данной задачи (Нас такой подход полностью устраивал, т.к. в ходе решения были продемонстрированы важные качества: желание разобраться и решить задачу, формулирование правильных вопросов, а также упорство).

Часть кандидатов сообщили, что они не умеют работать с кодом на уровне чтения и понимания и сразу сдались (я всячески старался мотивировать их попробовать решить задачу и представить, что я являюсь разработчиком и готов ответить на их вопросы, но они отказывались, что является наихудшим вариантом и таких кандидатов мы не рассматривали далее) Отсюда можно сделать вывод:

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

Задача на написание SQL - запроса

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

Почти все кандидаты в резюме декларировали свое знание SQL, как Advance, и в начале собеседования этот момент уточнялся. Некоторые честно говорили, что есть хорошее понимание, но практического опыта мало на последнем месте работы (что абсолютно нормально).

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

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

Еще один момент, который хочется подсветить:

Многие карьерные консультанты, блогеры и разного рода вещатели на LinkedIn и других платформах активно продвигают идею адаптации резюме под конкретную вакансию, вместо рассылки одной и той же версии в разные компании. В целом, их посыл верный, но только в том случае, если мы просто подсвечиваем свои сильные стороны и навыки для конкретной вакансии. На практике же, мы сталкиваемся с неверной трактовкой этой рекомендации. В некоторых резюме было сильно заметно, что люди адаптировали свое резюме под нашу вакансию, но при этом вместо подсвечивая своих сильных сторон, они либо перефразировали наши требования, либо просто приписали себе опыт и навыки, которого у них нет. Часть таких кандидатов отсеялись на этапе скрининга с HR, но 2 дошли до технического этапа со мной сильно “приукрасив” свой опыт на этапе скрининга.

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

Рекомендации

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

1. Интеграции (базовая теория по REST, SOAP, gRPC, GraphQL, разница между синхронными и асинхронными взаимодействиями, плюсы и минусы различных арх. подходов к проектированию API)

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

3. Брокеры сообщений (базовая теория и терминология, Apache Kafka, RabbitMQ, по каким критериям выбираем, что лучше подходит и под какие задачи, принципиальная разница между двумя брокерами)

4. Системный дизайн (очень рекомендую периодически смотреть примеры интервью по системному дизайну в Big Tech, это хорошо систематизирует знания, а также позволяет ассоциативно запоминать какие технологии и в каких случаях используются, также советую прочитать книгу Alex Xu - System Design Interview)

5. Моделирование (UML, BPMN, вспомнить наиболее популярные нотации, если нечасто отрисовываете диаграммы, потренировать моделирование в самом знакомом и удобном для вас инструменте)

6. SQL (потренироваться на задачах easy категории на степик или Leetcode, они бесплатные и этого будет достаточно для 90% интервью, в которых требуется знание SQL)

7. ЯП (в случае, если вы декларируете знание языков программирования в резюме, нужно быть готовым ответить на базовые теоретические вопросы по этим языкам, а также повторить теорию)

8. Инфраструктура (будет огромным плюсом, если у вас есть представление о том, что такое Docker, Kubernetes, AWS, Google Cloud и как это работает на самом премитивном уровне. Эти необязательные знания сильно выделят вас среди остальных, а также продемонстрируют ваш интерес к тому, что находится за пределами вашей зоны ответственности, т.к. данные технологии очень популярны в разных компаниях.

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