Собеседование на системного аналитика — это проверка теоретической базы, гибкости мышления и способности решать сложные задачи на лету.
Кому предложат ЗП 200-, а кому 400+? Собеседование расставит всё на свои места.
Знакомство и остальные компоненты собеседования описаны в первой части. Сегодня говорим про харды. Итак, сразу к делу.
Форматы проверки знаний
Формат собеседования может быть разным. У одного интервьюера это план и задачи наготове, а у другого — импровизация.
Был у меня собес, где интервьюер пришёл с презентацией и вопросами-задачами на слайдах. Весь технический собес мы шли по презентации.
Хотя формат целиком и полностью зависит от интервьюера, структура собеседований в более чем 90% случаев стандартная. Рассмотрим её основные части.
Теория
Стандартная беседа, устное рассуждение по теме, ответы на вопросы. В зависимости от ответа предлагается спуститься глубже или перейти к следующему вопросу. Обычно интервьюер идёт по заготовленным темам, но рихтуется по ответам кандидата.
И: С какими интеграциями вы сталкивались?
К: Много работала с REST и интеграцией через очереди.
И: Давайте поговорим про REST. Расскажите про выбор методов, заголовки, тело запроса.
К: … (рассказываю)
И: Как реализовать асинхронное взаимодействие через http?
К: Вебхуки, более древний способ — long/short polling.
И: Расскажите про вебхуки? Какое отличие long от short polling? В чём минус polling?
К: …(рассказываю)
И: Хорошо, какие ещё инструменты для асинхронного взаимодействия знаете?
К: Веб-сокеты, очереди сообщений.
…И так далее. Ну вы поняли.
Задачи и кейсы
Предложить решение для озвученных условий. Обычно устные задачи, реже присылают условия задачи в чате или другим каналом (например, в тренажёре). Формат имитирует работу над реальными задачами. Интервьюер смотрит, как в этом процессе проявляет себя кандидат.
Стандартный набор задач:
Написание SQL-запроса.
Проектирование БД.
Проектирование API.
Проектирование системы (несколько микросервисов).
Описание процесса с помощью 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 микросервисы
Монолит, микросервисы + и -. Сравнить по паре параметров. Примеры, когда лучше использовать монолит.
Паттерны
Саги (оркестрация и хореография).
Общее представление о SOA, EDA, event sourcing, DDD.
Безопасность
Углублённые знания:
Идентификация, аутентификация, авторизация.
Refresh, access токены. JWT.
Ролевая модель.
Общее представление (основные определения и концепции):
ЯП (язык программирования)
Есть вакансии, где в описании присутствует «умение читать код». Сомнительное требование, так как следом за синтаксисом нужно изучать фреймворк. А это уже слишком в сторону от функциональности системного аналитика. Но справедливости ради перечислю, что спрашивают.
Синтаксис.
Используемые библиотеки.
Про предметную область
Обычно резюме даёт понять, с чем человек работал. Если есть жёсткое ограничение «только с опытом проектирования ракеты», вас отсекут до тех собеса.
Системный аналитик — автоматизирует, а не улучшает бизнес-процессы. Поэтому экспертиза в этой области не так важна. Плюс, если человек погружен в контекст, но это некритично.
Однажды перед тех собесом мне сказали, что без опыта в предметной области не смогут предложить лидовскую позицию. После тех собеса предложи сеньора. В предметной области у меня не было опыта.
Предметная область может быть существенна на джун, мидл- позициях. Как гарантия, что, хотя бы в предметке человек разбирается, есть на что опереться. На мидла и выше, предметка — второстепенная история. Тут опора будет на понимание подходов, технологий, опыт погружения в разного уровня запутанности и сложности бизнес-процессы.
Мой первый и последний серьёзный разговор о предметке был, когда я собеседовалась на стажёрскую позицию. Отчасти обусловлено это было те��, что предметная область была непростая (бу, бюджетирование, мсфо). Но на том собеседовании не было ни одного технического вопроса. Только на логику, мышление и по предметной области.
Вывод такой: если вы неуверенный мидл и ниже, то над предметной областью есть смысл задуматься. Если нет — то нет.
Да и Нет на собесе
ДА
Говорить честно, с чем не работали или что имеете мало практического опыта. Но показывать осведомлённость и теоретическую базу.
НЕТ
Если не работали с технологией (особенно если это было в требованиях на позицию или стандартный вопрос) — не читать и даже не пытаться разобраться. Достаточно минимальных знаний — что это, когда применяется. Если кандидат говорит «нет, не работал, ничего не знаю», то это говорит:
о неподготовленности к стандартным вопросам (не системно);
об узком кругозоре (дальше носа не смотрит);
о низкой мотивации пройти собеседование хорошо (лени).
Всё это минусы кандидату. Интересно, по рабочим вопросам такое же отношение будет?
ДА
Свои пет-проекты и ссылка на гит в резюме. Что-то сделанное руками — всегда вызывает бо́льший интерес. Если использовали технологию, по которой задают вопрос, упоминайте личный опыт использования.
НЕТ
Вау-эффект или попытка выпендриваться.
Если вы сами делаете на чём-то акцент, щеголяете модными подходами/технологиями, вы должны разбираться в теме. Не может рассказать простыми словами, провести понятные аналогии, путаетесь в деталях, ещё хуже — не понимаете сути. Неизбежно попадёте в категорию поверхностных кандидатов.
Достаточно показать прочную базу. Сильное показать, раскрыть. Слабое — дотянуть до минимума (осведомлённость, теория). Хороший интервьюер стремится найти тему, в которой вы сильны и сможете проявить себя.
Заключение
Собеседование — это всегда вызов и стресс. Я предпочитаю относиться к собеседованию как к возможности найти направления для развития. Это может быть как теория и практические задачи, так и работа с тревогой и напряжением (которые мешают полноценно продемонстрировать знания и навыки).
Результат собеса — не истина и не вердикт. Это субъективное мнение, которое сильно зависит от интервьюера. У опытных интервьюеров субъективность стремится к объективности, но никогда её не достигает.
Расскажите, что думаете. Что должен знать аналитик, а какие знания мусор в голове? Какие неожиданные вопросы вам задавали на собеседованиях? Или, может, вы задаёте вопросы, которые ставят в тупик кандидатов?