Привет Хабр! Мы в SSP SOFT разрабатываем заказное ПО для ведущих российских банков и финтех-проектов. Системный аналитик (СА) — одна из ключевых фигур в проектных командах, и такие вакансии с грейдами сеньор, мидл и джун регулярно появляются в компании. Для технического интервью мы привлекаем внешних экспертов с компетенциями, которые максимально близки к предметной области проекта. Эта статья — наша версия на тему проверки опыта и навыков СА на собеседовании. Читайте и комментируйте ✍️.

Круг вопросов по задачам, навыкам и опыту системного аналитика (СА) на техническом интервью по известной индийской притче похож на слона, описываемого 4-мя слепыми. Тут дело в том, что трактовка должностных обязанностей, и соответственно, требований по скиллам СА в разных компаниях настолько разнится, что любое описание «типового интервью СА» будет попыткой из индийской притчи. Тем не менее, мы ведь не зря тут собрались, поэтому вот эти 4 наиболее важных пунктов скиллов по вакансии СА:

1. Умение декомпозировать бизнес-требования из ТЗ в список функциональных и нефункциональных требований, атрибутов входных и выходных данных, и далее в набор «кубиков» будущего ПО;

2. Умение использовать нотации моделирования, т.е. построения логики движения данных в проектируемой системе, в том числе с использованием диаграмм BPMN
   и/или UML Sequence;

3. Знание REST API для определения того, как ПО будет взаимодействовать с другими модулями внутри приложения и с внешними системами, или другие способы взаимодействия, если вам не довелось работать с REST;

4. Знание SQL для умения строить и модифицировать таблицы данных, оптимизировать запросы к базе данных для улучшения производительности, извлекать данные для отчетов и анализа в интересах бизнеса.

 Но, в начале любого интервью — рассказ кандидата о себе, и наши советы об этом ниже.

Начало интервью — про прежний опыт и проактивность 

Надо сразу признать, что по практике множества проведенных интервью, СА даже с большим опытом, поработавших в компаниях разного размера и в разных отраслях, могут встретить затруднения при ответах на некоторые вопросы технического собеседования. Изречение Сократа «Чем больше я знаю, тем больше я понимаю, что ничего не знаю» — это и про СА тоже.

Чем шире понимание человеческого опыта, тем лучше у нас будут проекты», — Стив Джобс, 1996.

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

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

Типичный прием — подвести кандидата при обсуждении какого-либо вопроса (с точки зрения глубины темы) к моменту, когда он или она отвечает «Не знаю». Тут нет никакого негатива и желания «завалить», — ведь всё знать невозможно, — таким образом оценивается вариативность ответов (сколько вариантов решения кандидат сможет назвать), проактивность в ответах, способность кандидата гибко мыслить и применить прежний опыт.

Мы в SSP SOFT не практикуем для СА отдельного этапа тестового задания вне интервью. Это удлинило бы сроки найма, и нет гарантии самостоятельно выполнения. Поэтому техническое интервью в SSP SOFT уже включает несколько практических задач, которые можно успеть выполнить в рамках отведенного на интервью времени, т.е. до одного часа.    

В техническое интервью с внешним экспертом у нас также не входит проверка софт-скилз. Хотя, конечно, в отчете эксперт указывает, был ли кандидат активен, контактен, находчив, или ответы приходилось буквально «вытаскивать». Подробнее софт-скилз оцениваются на повторном интервью уже с нашим тимлидом и представителем HR.

Как оцениваются результаты технического собеседования в SSP SOFT? Ответы кандидата по каждому вопросу, включая рассказ о прежнем опыте, интервьюер ранжирует по балльной системе. Соответственно, в шорт-лист выходят 2-3 кандидата с наивысшим баллом.

FAQ по вопросам к СА на этапе «рассказа о себе»

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

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

2. Какие методологии и инструменты вы используете при анализе и моделировании бизнес-процессов?Вопрос помогает убедиться, что кандидат знаком с методологиями и инструментами, часто используемыми на позиции СА.

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

4. Как вы взаимодействуете с командой разработки или другими участниками проекта?Вопрос, чтобы удостовериться, что кандидат имеет опыт эффективной командной работы.

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

6. Какие аспекты вашего опыта и навыков вы считаете наиболее ценными для этой роли?Это спрашивают, чтобы не только узнать больше о кандидате, но и посмотреть, как он или она подчеркивает свои сильные стороны, которые могут быть ценными для данной вакансии.

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

Тема интервью #1: Что требуется, чтобы это спроектировать?

После "лирического вступления" про прежний опыт, интервью переходит в практическую плоскость и первым пунктом проверяется умение кандидата выявить потребности заказчика (согласно ТЗ или «с нуля»), формализовать их в виде функциональных блоков и на этой основе набросать примерную архитектуру системы.

Коронный вопрос здесь "А что вам потребуется, чтобы спроектировать вот это?". И далее, отталкиваясь от потребностей проекта, интервьюер называет любой термин: базу данных, микросервис, API, UC (юз-кейс, описание действий пользователя в системе).

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

Пример вопроса (и ответа), который может быть задан по use case

Вопрос: “Опишите разницу между основным сценарием (main flow) и альтернативными сценариями (alternate flows) в структуре use case. Какие критерии вы используете для определения, когда следует создать альтернативный сценарий?”

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

Ответ: В разработке программного обеспечения use case представляет собой инструмент для описания функциональных требований к системе или приложению. Основной сценарий (main flow) в use case — это последовательность шагов по наиболее типичному пути выполнения операции или функции. Этот сценарий описывает действия, которые выполняются в обычных условиях и без каких-либо существенных проблем.

Альтернативные сценарии (alternate flows) описывают пути выполнения операции или функции, которые могут возникнуть в случае невозможности следования по основному пути. Они позволяют учесть нестандартные ситуации.

Критерии для определения, когда следует создать альтернативный сценарий, могут включать:

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

•  Различные варианты входных данных или условий, которые могут влиять на результат.

• Исследование ситуаций "Что произойдет, если...?" или "Что делать, если...?"

• Спецификация действий, которые должны быть предприняты в случае ошибок или отказов в процессе выполнения main flow.

Примером use case может быть "Оформление заказа в интернет-магазине," где основной сценарий описывает успешное оформление заказа, а альтернативные сценарии могут описывать такие ситуации, как отсутствие товара на складе, некорректные данные от пользователя или проблемы с оповещением покупателя о невозможности выполнить заказ.

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

Совет кандидатам. часто в крупных компаниях бизнес-потребности заказчика исследует и формализует бизнес-аналитик. Соответственно, СА получает уже готовое ТЗ для системной реализации. Но также часто, функции бизнес-аналитика могут возлагать на СА, который должен выведать у заказчика все требования к ПО. На собеседовании кандидат должен уточнить у интервьюера, дается ли готовое ТЗ или функциональность продукта надо будет еще уточнять у заказчика. И строить свой ответ соответственно.

Тема интервью #2: Проверка навыков нотации моделирования

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

Простые вопросы — про определенные элементы на диаграммах: «Что означает ромб в BPMN (Business Process Model and Notation), длинный вертикальный прямоугольник в UML (Unified Modeling Language) Sequence»? Интервьюер может спросить про отличия нотаций соответствующих диаграмм: чем отличаются BPMN и UML Activity, ER и UML Class. Более сложные вопросы — о различных типах событий в BPMN или о том, как представляются последовательности взаимодействия в UML Sequence.

Далее интервьюер переходит к практическому заданию по нотации моделирования. Частый пример — интервьюер просит кандидата создать простую диаграмму на основе представленного сценария. Это может быть, например, разработка диаграммы бизнес-процесса с использованием BPMN для описания процесса заказа товара в интернет-магазине.

Интервьюер для себя отмечает, какие инструменты моделирования использовал кандидат и насколько он в них ориентируется. Например, кандидат может использовать Draw.io, Microsoft Visio, Lucidchart или другие инструменты для создания диаграмм BPMN и UML.

Как правило, интервьюер не настаивает на типе диаграммы, будь то BPMN или UML Sequence, кандидат сам придумывает любую диаграмму, — важна не диаграмма по факту, а какими элементами кандидат ее наполнит. Это также говорит о том, насколько широко кандидат использовал данный инструмент в своих прежних проектах.

Еще один способ проверить понимание любой нотации моделирования у кандидата — это разыграть ситуацию, когда СА отправил диаграмму по почте заказчику, а тот перезванивает и спрашивает: "Что это такое и как это читать?". Задача кандидата — на языке, понятном для бизнес-пользователя, рассказать, как разобраться в диаграмме. При этом кандидат может придумать любой практический кейс, который представлен на диаграмме.

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

Совет кандидатам: подготовьте "портфолио" проектов, в которых вы использовали нотации моделирования. Попросите у интервьюера разрешения предоставить примеры диаграмм BPMN и UML Sequence, которые вы создавали. Этим вы можете показать свою проактивную позицию, переведя обсуждение на детали именно своих диаграмм. Соответственно, предоставив интервьюеру возможность задать вопросы о назначении, структуре и содержании ваших диаграмм.

Тема интервью #3: Как у вас со знанием REST API?

Знание REST API (Representational State Transfer Application Programming Interface) является важным активом для системного аналитика, а на портале HH.RU вы даже можете встретить вакансии с заголовком  «Системный аналитик с REST API». К слову, последнее время в вакансиях в дополнение к REST API еще могут спрашивать знание GraphQL, хотя это уже скорее идет бонусом для кандидата.

Примечание: в REST API структура данных и конечные точки определены на сервере, в то время как в GraphQL клиенты определяют, какие данные им нужны, и сервер предоставляет их в соответствии с запросом.

Владение навыком составления запросов REST API помогает системному аналитику проектировать и управлять интеграциями, расширениями, для тестирования и отладки, а также для анализа и моделирования бизнес-процессов.  

Теперь о заданиях по REST API на интервью, — если оно проходит в рамках устного собеседования, — то обычно предполагается, что кандидат расшарит свой экран и начнет прямо на лету писать запрос, попутно комментируя происходящее для интервьюера.

Пример короткого тестового задания по REST API

Вот пример короткого тестового задания по REST API для кандидата, которое можно выполнить буквально за несколько минут:

Задание: «Вы работаете с веб-сервисом, предоставляющим информацию о книгах в онлайн-библиотеке (например, это сервис типа ЛитРес или Альдебаран). Вам нужно получить список всех книг в библиотеке, а затем получить информацию о конкретной книге по ее идентификатору.

Используя REST API, выполните следующие действия:

1. Сделайте HTTP GET запрос для получения списка всех книг. URL для этого запроса: https://example.com/api/books

2. После получения списка книг, выберите одну из книг и получите информацию о ней. Для этого сделайте HTTP GET запрос с указанием идентификатора книги в URL. Например: https://example.com/api/books/123

Ваша задача — предоставить примеры кода (HTTP-запросы) для выполнения этих действий, показать как выглядит примерный ответ сервера и коротко описать словами свои действия».

Посмотрим, как может выглядеть ответ кандидата для такого задания:

1. Запрос для получения списка всех книг (GET):

   GET https://example.com/api/books

   Ответ сервера может выглядеть примерно так:

{
   "books": [
    {
      "id": 123,
      "title": "Война и мир",
      "author": "Лев Толстой"
    },
	{
  	"id": 124,
  	"title": "Преступление и наказание",
  	"author": "Фёдор Достоевский"
	},
    // Другие книги...
  ]
}

2. Запрос для получения информации о книге с идентификатором 123 (GET):

   GET https://example.com/api/books/123  

  Ответ сервера может выглядеть примерно так:

{
 	"id": 123,
 	"title": "Война и мир",
 	"author": "Лев Толстой",
 	"description": "Эпический роман о войне 1812 года и обществе того времени."
}

Как видим, пример простейший, но он помогает интервьюеру быстро понять, владеет ли кандидат навыками запросов HTTP GET для получения списка объектов и информации о конкретном объекте.

Совет кандидатам: изучите HTTP-методы (GET, POST, PUT, DELETE и другие), и как они используются для взаимодействия с сервером. Освойте работу с инструментами для тестирования API, такими как Postman или Insomnia. Попрактикуйтесь в написании запросов к API: поищите открытые API для тренировки, часто они имеют документацию. Важно не только уметь отправлять запросы, но и правильно интерпретировать ответы сервера, понимать структуру данных в формате JSON.

Тема интервью #4: И последнее — проверка знаний по SQL

Знание SQL, наравне с REST API, является еще одним ключевым навыком для СА, поскольку эта технология широко используется для работы с базами данных. Системные аналитики часто сталкиваются с задачами, требующими проектирования или модификации таблиц, извлечения, обновления или удаления данных, и здесь SQL становится неотъемлемым инструментом. Кроме того, SQL позволяет выполнять сложные запросы для анализа данных, что может быть полезно при принятии решений и определении стратегий для бизнес-подразделений компании.

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

Вот пример задания по составлению SQL запроса, которое можно выполнить буквально за 1-2 минуты:
«Представьте, что у вас есть таблица "Пользователи" (Users) с полями "ID", "Имя" (Name), "Email" и "Дата регистрации" (RegistrationDate).

Ваша задача - написать SQL-запрос, который вернет всех пользователей, зарегистрированных за последний месяц».

Правильный ответ кандидата может выглядеть следующим образом:

SELECT *
FROM Users
WHERE RegistrationDate >= DATEADD(month, -1, GETDATE());

В этом запросе мы выбираем все строки из таблицы "Users", где значение поля "RegistrationDate" больше или равно текущей даты минус один месяц. Это позволит выбрать всех пользователей, зарегистрированных за последний месяц.

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

Совет кандидатам: освежите перед интервью ваши навыки и знания по SQL. Вы должны уверенно владеть базовыми запросами SQL, такими как SELECT, INSERT, UPDATE, DELETE и WHERE. Попрактикуйтесь в использовании функций для обработки данных COUNT(), AVG(), SUM(), MAX(), MIN(). Не забудьте про запросы с несколькими таблицами: как соединять таблицы с помощью JOIN и работать с подзапросами для извлечения данных из нескольких связанных таблиц, как использовать GROUP BY и HAVING.

В заключение — слово кандидату

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

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

Что делать, если вам как кандидату не хватило баллов для оффера на должность СА? Часто отказ может приходить со стандартной формулировкой «Спасибо, но …». Наш совет — запросите у рекрутера (с кем вы общаетесь в мессенджере по вакансии) расширенную обратную связь по итогам собеседования. Это поможет вам проанализировать свои слабые стороны в части знаний и подтянуть их к следующему интервью, в том числе и на вакансии СА в других компаниях.

Всех интересующихся вакансиями системного аналитика, разработчиков на Java, React и Python, 1С, инженеров DevOps и QA — приглашаем посетить нашу страницу на hh.ru.

Автор: Сергей Березин