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

Кому предложат ЗП 200-, а кому 400+? Собеседование расставит всё на свои места.

Знакомство и остальные компоненты собеседования описаны в первой части. Сегодня говорим про харды. Итак, сразу к делу.

Форматы проверки знаний

Формат собеседования может быть разным. У одного интервьюера это план и задачи наготове, а у другого — импровизация.

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

Хотя формат целиком и полностью зависит от интервьюера, структура собеседований в более чем 90% случаев стандартная. Рассмотрим её основные части.

Теория

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

И: С какими интеграциями вы сталкивались?
К: Много работала с REST и интеграцией через очереди.
И: Давайте поговорим про REST. Расскажите про выбор методов, заголовки, тело запроса.
К: … (рассказываю)
И: Как реализовать асинхронное взаимодействие через http?
К: Вебхуки, более древний способ — long/short polling.
И: Расскажите про вебхуки? Какое отличие long от short polling? В чём минус polling?
К: …(рассказываю)
И: Хорошо, какие ещё инструменты для асинхронного взаимодействия знаете?
К: Веб-сокеты, очереди сообщений.
…И так далее. Ну вы поняли.

Задачи и кейсы

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

Стандартный набор задач:

1. Написание SQL-запроса.

2. Проектирование БД.

3. Проектирование API.

4. Проектирование системы (несколько микросервисов).

5. Описание процесса с помощью sequence-диаграммы.

Оценивают несколько качеств:

• Способность практически применять теоретические знания и опыт.
  Что такое саги в теории — это хорошо. А задачу, где логичным будет спроектировать оркестратор, например, каким образом решите? Про БД рассказали многое, теперь нужно спроектировать несколько таблиц и связи грамотно выстроить.

• Линию рассуждений и мыслительную траекторию.
  Человек, может, никогда не сталкивался с определённой технологией или паттерном (использование которых подразумевается в задаче). Но рассуждает, предлагает разные варианты и движется в нужном направлении. Самостоятельно изобретает велосипед. 

• Работа в напряжённой обстановке (задача +незнакомые люди +оценка +камера). Иногда градус поднимают, предлагая включить демонстрацию экрана при решении. Есть ли инициатива, активное участие. Или это односложные неуверенные ответы. Кандидат рассуждает, пробует или сказал «не знаю» и руки сложил на груди.

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

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

Темы

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

Собран список с оговоркой, что я исключила вакансии, где упор на документацию по ГОСТам, бо́льшая часть интеграции SOAP, команды из 3х человек, аналитик-разнорабочий (шеринг на смежные роли — менеджерские, инженерские).

Процесс разработки ПО

Понимание того, как организована деятельность людей и процессы так, чтобы делать ПО.

• Подходы. Этапы. Роли.

• Водопад. Один длинный цикл. Цена ошибки высока.

• Agile принципы. Ориентация на потребности бизнеса, которые рождаются по мере использования продукта и обстановки на рынке. Гибко. Управляется легче, чем большой неповоротливый водопад. Что приносит пользу — развиваем, что не подошло — изменяем. Риски ниже.

• Скрам и Канбан.

• Роль СА в процессе разработки.

• Артефакты и церемонии.

Требования

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

• БТ — Пользовательские — ФТ — НФТ.

• Примеры требований каждого типа с трассировкой от БТ до постановки задачи разработчику. 

• Управление требованиями, работа с противоречиями, актуализация.

По НФТ — без сухой теории (производительность, надёжность, поддерживаемость). Делаем как хорошо, как нехорошо — не делаем. Приведение реальных примеров рабочих требований:

• Кол-во пользователей обычно/пиковое.

• Показатель LCP.

• Обязательный 2ой фактор при аутентификации. Срок годности токенов.

• Автогенерация описания API с помощью Swagger.

• Столько-то девяток по доступности.

• Работа с перс данным.

• Использование UI-kit.

Способы выявления требований

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

• Беседа с представителями бизнеса. Погружение в контекст, понимание бизнес-потребности. На чём будет строиться заработок или сокращение расходов.

• Беседа (1-1) или с группой пользователей. Пользователи будут предлагать решения. Задача аналитика — выяснить, чего хотят пользователи на самом деле (не кнопку покрасить в синий цвет, а изменений в UI-UX, потому что он кривой-косой, например).

• Обсуждение в чате или почте. На основании драфтов документации и схем. 

• Метод 5 почему/зачем.

• Использование или построение CJM.

Способы документирования требований

• Контекст, термины, ограничения, цели. Структура, оформление. Ориентация на ЦА. 

• US, UC (DoR, DoD).

• Диаграммы и схемы (sequence, диаграмма состояний, ER, BPMN, кубики-стрелочки).

• Технические спецификации (API, структуры сообщений для очередей).

• Прототипирование дизайна. Работа с макетами в figma.

Нарезка задач и оценка требований

• User story mapping. Выделение набора задач на MVP, v1, v2 и т. д. Приоритизация.

• Нарезка задач (эпики-стори-задачки).

• Оценка — кто и как (стори пойнты, числа Фибоначчи, майки).

Интеграции

Аналитик, который не умеет работать с API, не понимает, как устроены интеграции и очереди — слабое звено в команде.

Даже если:

• Проектирование API полностью на плечах разработчиков.

• Выбор технологии для взаимодействий — на архитекторах и тех лидах.

• Кафку выбрали уже давно, а разделение на партиции происходит без участия аналитика.

Обилие способов, стилей, технологий, протоколов может сбивать с толку.

Темы из категории «удалённые вызовы» и «обмен сообщениями» обсуждают на собеседовании с разных сторон. Сначала отдельно рассказать, потом сравнить между собой (REST — очереди, rabbit — kafka, REST — SOAP).

Ниже темы, которые в основном сводятся к схеме.

Общие вопросы

• Определение. Виды.

• Форматы данных (текст, json, xml, бинарный).

• Взаимодействие клиент-сервер, сервер-сервер.

• (А)синхронность.

REST

• Методы (основные, дополнительные). Структура запроса (строка запроса, заголовки, тело). Статус-коды (200—201, 3хх, 400—404, 5хх). Идемпотентность.

• Использование кеша (как и для чего).

• Минусы и возможные проблемы REST.

• Postman. Инструменты разработчика в браузере.

• Способы документирования API (OpenAPI).

• Polling и Вебхуки.

• HTTP, TLS.

 Очереди

• Сравнение Kafka и Rabbit.

• Модели push-pull.

• Консьюмер, продюсер. Топики, партиции, offset.

• Гарантии доставки.

• Минусы и возможные проблемы очередей.

• Сравнить REST и очереди. Отличия. Когда что использовать.

Остальное

Раздел «Остальное» есть смысл разбирать, только когда в разделах REST и очереди будет ясность и «всё по полочкам». Иначе зря потратите время и себя запутайте.

• Веб-сокеты.

• gRPC (в последнее время стали спрашивать) — HTTP/2, бинарный формат, стили взаимодействия. На моих проектах не использовали. О чём честно говорю, рассказывая теоретический минимум.

• GraphQL — на паре собеседований уточняли, как это работает. Мой ответ — аналогично gRPC. Пару статей из интернета + глянуть источники.

• Протоколы прикладного уровня помимо http — FTP, DNS, SSH, почтовые.

• Общее представление о работе TCP/IP.

Если вы уверенно знаете REST, то вас научат и направят. Если нет, то пожелаем им удачи найти аналитика, который хорошо разбирается в веб-сокетах, gRPC и GraphQL.

БД

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

Реляционные

Необходимо не просто знать основные понятия, но и разбираться в деталях.

• Принципы, определение реляционности.

• PK, FK.

• Типы (целые, с плавающей точкой, дата-время, булево, строковые, бинарные).

• Удаление (мягкое, каскадное).

• Нормальные формы до 3ей.

• Методы масштабирования (шардирование, партиционирование, репликации — мастер и slaves).

• Ускорение поиска по БД. Индексы (b-tree, хеш).

• Транзакции. ACID (с точки зрения понимания принципов). 

NoSQL 

Трудно представить современное приложение без использования Redis, MongoDB, Elasticsearch и прочих noSQL баз данных. Ориентироваться в теме очень желательно.

• Виды.

• Примеры использования.

• Основные отличия от реляционных БД.

SQL

Базовые операторы для извлечения данных.

• SELECT — FROM — WHERE.

• JOIN, UNION, GROUP, HAVING, ORDER, DISTINCT, LIMIT.

Архитектура

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

Монолит vs микросервисы

Монолит, микросервисы + и -. Сравнить по паре параметров. Примеры, когда лучше использовать монолит.

Паттерны

• API-gateway.

• Саги (оркестрация и хореография).

Общее представление о SOA, EDA, event sourcing, DDD.

Безопасность

Углублённые знания:

• Идентификация, аутентификация, авторизация.

• Refresh, access токены. JWT.

• Ролевая модель. 

Общее представление (основные определения и концепции):

• SSO

• OAuth 2.0

• AD и LDAP

• Keycloak

ЯП (язык программирования)

Есть вакансии, где в описании присутствует «умение читать код». Сомнительное требование, так как следом за синтаксисом нужно изучать фреймворк. А это уже слишком в сторону от функциональности системного аналитика. Но справедливости ради перечислю, что спрашивают.

• Синтаксис.

• Используемые библиотеки.

Про предметную область

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

Системный аналитик — автоматизирует, а не улучшает бизнес-процессы. Поэтому экспертиза в этой области не так важна. Плюс, если человек погружен в контекст, но это некритично.

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

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

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

Вывод такой: если вы неуверенный мидл и ниже, то над предметной областью есть смысл задуматься. Если нет — то нет. 

Да и Нет на собесе

ДА

Говорить честно, с чем не работали или что имеете мало практического опыта. Но показывать осведомлённость и теоретическую базу. 

НЕТ

Если не работали с технологией (особенно если это было в требованиях на позицию или стандартный вопрос) — не читать и даже не пытаться разобраться. Достаточно минимальных знаний — что это, когда применяется. Если кандидат говорит «нет, не работал, ничего не знаю», то это говорит:

• о неподготовленности к стандартным вопросам (не системно);

• об узком кругозоре (дальше носа не смотрит);

• о низкой мотивации пройти собеседование хорошо (лени).

Всё это минусы кандидату. Интересно, по рабочим вопросам такое же отношение будет?

ДА

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

НЕТ

Вау-эффект или попытка выпендриваться.

Если вы сами делаете на чём-то акцент, щеголяете модными подходами/технологиями, вы должны разбираться в теме. Не может рассказать простыми словами, провести понятные аналогии, путаетесь в деталях, ещё хуже — не понимаете сути. Неизбежно попадёте в категорию поверхностных кандидатов. 

Достаточно показать прочную базу. Сильное показать, раскрыть. Слабое — дотянуть до минимума (осведомлённость, теория). Хороший интервьюер стремится найти тему, в которой вы сильны и сможете проявить себя. 

Заключение

Собеседование — это всегда вызов и стресс. Я предпочитаю относиться к собеседованию как к возможности найти направления для развития. Это может быть как теория и практические задачи, так и работа с тревогой и напряжением (которые мешают полноценно продемонстрировать знания и навыки). 

Результат собеса — не истина и не вердикт. Это субъективное мнение, которое сильно зависит от интервьюера. У опытных интервьюеров субъективность стремится к объективности, но никогда её не достигает.

Расскажите, что думаете. Что должен знать аналитик, а какие знания мусор в голове? Какие неожиданные вопросы вам задавали на собеседованиях? Или, может, вы задаёте вопросы, которые ставят в тупик кандидатов?