Представьте, что вам предстоит собеседование на позицию системного аналитика (СА). Что нужно знать для успешного прохождения интервью и какие вопросы могут задать? Эта статья может стать roadmap при подготовке к собеседованию.
Кто такой системный аналитик
Для начала, давайте обозначим границы, чтобы понимать для кого эти темы и вопросы актуальны. Границы роли системного аналитика далеко не всегда четко обозначены. От компании к компании я встречаю совершенно разные интерпретации должностных обязанностей таких специалистов. Однако, большинство компаний, занимающихся веб- и мобильной разработкой близки в своем понимании роли СА и требованиях к кандидатам.
Чаще всего требования к кандидатам следующие (помимо опыта работы в определенном домене):
Основная деятельность: сбор, анализ и документирование требований к ПО на техническом языке. Сопутствующее общение с заказчиками и проектной командой, изучение предметной области, участие в проектировании решений, проверка реализованного функционала на соответствие требованиям, участие в показах.
Требуемые hard skills: навыки разработки технической документации (BRD, SRS), опыт работы с различными СУБД, уверенные знания SQL, проектирование модели данных, знание нотаций UML, BPMN, знание различных методов интеграции систем, понимание принципов проектирования REST API, опыт работы с SOAP, понимание особенностей форматов обмена данными JSON/XML.
Требуемые soft skills: коммуникабельность, способность находить общий язык и с разработкой, и с бизнесом, аналитическое мышление, умение работать в условиях недостатка информации, адаптивность к изменениям, проактивность и ответственность за конечный результат.
Откуда вопросы?
За последний год на позиции тимлида группы системных аналитиков я провела немало собеседований. Но не менее ценным опытом считаю личные собеседования на позицию СА в других компаниях, в ходе которых я выявила для себя ТОП-5 тем с возможными вопросами, которые повторялись практически на каждом интервью. Во избежание читерства я не буду давать ответы, но оставлю ссылки на ресурсы, изучив которые вы с легкостью ответите на все вопросы.
Сразу уточню, что далеко не все вопросы встретятся у вас на собеседовании одновременно. Но если вы претендуете на высокую позицию и пройдете N собеседований, то с большой долей вероятности встретите все эти вопросы на своем пути. Также хочу отметить, что для аналитиков разного уровня требуется разная детализация ответов. Если вы junior/pre-middle, то обычно достаточно поверхностного ответа на приведенные примеры вопросов, чтобы интервьюер понял, что вы сталкивались с темой или хоть чуть-чуть в этом разбирались.
ТОП тем
Требования к ПО
Тема очень важная, я бы даже сказала основополагающая, но при этом достаточно холиварная. Потому что обилие информации провоцирует ее разночтения. Чаще всего интервьюеры ожидают услышать ответы на основании модели, представленной в книге К. Вигерса и Д. Битти "Разработка требований к ПО". Поэтому не лишним будет заранее подготовить примеры по уровням требований (бизнес-требования, пользовательские и функциональные).
Возможные вопросы:
Что такое требование к ПО?
Какие виды требований вы знаете?
Чем отличаются бизнес-требования от функциональных?
Чем отличаются функциональные требования от нефункциональных?
Чем отличаются пользовательские требования от функциональных?
Привести примеры каждого из требований или классифицировать предложенные требования.
Какие критерии качества требований вы знаете?
Для компаний, где роль СА объединена с БА (бизнес-аналитиком). Сюда же могут попасть вопросы про выявление требований: основные техники сбора требований, управление стейкхолдерами (заинтересованными сторонами), выбор стратегии работы со стейкхолдерами и тп.
Ресурсы для изучения:
Ответы на все вопросы есть в замечательной книге К. Вигерса и Д. Битти «Разработка требований к ПО». Книга, на мой взгляд, обязательна к прочтению каждому СА. Но если вам все-таки лень читать 716 страниц достаточно сложного к восприятию текста, то вот список ресурсов, где хорошо описаны ответы на вопросы выше:
Полезные выдержки вышеобозначенной книги вы можете найти тут и тут
Интересная презентация про разные подходы к классификации требований (по Вигерсу, ГОСТ34, SWEBOK, IEEE 830 и RUP)
Процесс разработки ПО
В основном тут достаточно рассказывать про свой опыт и про то, как организован процесс разработки на текущем месте работы. Но будет плюсом, если вы покажете эрудицию, рассказав про разные методологии и их использование.
Возможные вопросы:
Какие методологии вы знаете? Работали ли вы по Agile/Waterfall или любой другой методологии.
Расскажите про жизненный цикл разработки проекта: этапы, роли, артефакты.
Какую роль выполняет системный аналитик в проектах разработки ПО?
Какие обязанности закреплены за вами на вашем текущем месте работы?
Ресурсы для изучения:
Модели жизненного цикла, принципы и методологии разработки программного обеспечения (ПО), а можно и покороче
Про БА vs СА
Документация к системе и другие артефакты деятельности аналитика
Опять же, как и в предыдущем блоке в основном вопросы про ваш опыт, чтобы оценить насколько он релевантен тому, что вам предстоит делать.
Возможные вопросы:
Какую документацию вы пишете на текущем месте работы?
Что вы описываете в ТЗ на разработку?
Насколько детально вы описываете то, что требуется реализовать? Бизнесовым или техническим языком?
Какие артефакты остаются в итоге вашей работы и для чего они используются в дальнейшем?
Был ли опыт работы с ГОСТом 34/19?
Кто ставит задачи на разработку? В описании постановок на разработку придерживаетесь ли вы какого-то определенного формата? Какой уровень детализации ваших постановок?
Ресурсы для изучения:
Проектирование решения
Как показывает практика, далеко не каждый СА участвует в проектировании решения. Это связано с различиями в понимании роли СА в разных компаниях, а также с уровнем компетенции СА (достаточно ли у аналитика знаний и опыта, для влияния на выбор реализации решения или нет). Но, как минимум, аналитик всегда может облегчить задачу тем, кто занимается проектированием решения, предоставив им исчерпывающее, грамотно оформленное и понятное всем описание бизнес-задачи и ожидаемых функциональных возможностей системы.
Возможные вопросы:
Участвуете ли вы в проектировании решения? Если да, то каким образом?
Вопросы про работу с базами данных:
Что такое БД? Какие бывают БД (речь про классификацию по модели данных)? С какими БД работали?
Что такое СУБД? Основные функции СУБД? С какими СУБД работали? Какие клиенты для работы с СУБД использовали?
Чем отличаются SQL и NoSQL БД?
Что лежит в основе реляционных БД?
С какими нереляционными БД работали?
Какие типы ограничений в реляционных БД знаете (constraints)?
Что такое нормализация? Зачем она нужна?
Какие нормальные формы (НФ) вы знаете? Решить кейс с нормализацией данных.
Что такое ER-модель?
Умеете ли вы строить ER-диаграмму? Какие нотации знаете?
Есть ли у вас опыт проектирования БД?
Могут попросить спроектировать концептуальную/логическую модель данных для некоторой предметной области.
Есть ли у вас опыт написания запросов на SQL? Уровень запросов? Далее уточняющие вопросы по уровню знаний SQL:
Какие подмножества SQL вы знаете? (речь идет про DDL, DQL, DML и DCL). Расшифровать аббревиатуры и привести примеры операторов для каждого подмножества.
Рассказать про самые популярные операторы, зачастую это:
JOIN
UNION
ORDER BY
GROUP BY
HAVING
Различные агрегатные функции
Могут попросить написать простенький запрос или же рассказать про логику построения запроса для какого-то кейса.
Работали ли вы с индексами? Что это и для чего они нужны? Вопрос для знатоков, но на паре собеседований он у меня встречался. Важно для вакансий, где особое внимание уделено работе с БД.
Какие нотации моделирования бизнес-процессов знаете (зачастую подразумевается BPMN и UML)?
СА все таки чаще используют UML. Соответственно вопросы такие:
Какие диаграммы вы использовали в своей работе?
Для чего используют диаграмму деятельности (Activity diagram)/диаграмму состояний (Statechart diagram)/диаграмму вариантов использования (UseCase diagram)/диаграмму последовательности (Sequence diagram)?
Описывали ли вы варианты использования в табличном формате?
Ресурсы для изучения:
Интеграции
С этой темой надо быть аккуратнее. Есть ситуации, когда лучше сказать хоть что-то чем не сказать ничего, но здесь работает ровно противоположное. Если вы не уверены в том, что достаточно разбираетесь в теме, лучше не утверждать ничего, что вызовет дополнительные вопросы на понимание.
Возможные вопросы:
Какие способы интеграции систем вы знаете?
Чем отличаются синхронное и асинхронное взаимодействия?
Что знаете про очереди сообщений? Для чего их используют?
Проектировали ли вы API? Каким образом описывали спецификации?
Тестировали ли вы сами API? Какое ПО использовали?
HTTP:
Какие основные HTTP методы знаете?
Расскажите про HTTP сообщения. Какую структуру имеет запрос? Какую структуру имеет ответ? Какие коды состояния (status code) знаете и что они означают?
Чем отличается POST от PUT от PATCH?
Что знаете про концепцию CRUD?
Что такое JSON? Для чего используется?
REST:
Что такое REST?
Какие основные принципы REST знаете?
SOAP:
Что такое SOAP? В каком формате передаются сообщения?
Какая структура у сообщения SOAP?
Работали ли с XML? Что это?
Что такое XSD? Проектировали ли вы XSD схемы?
Для чего используется XSLT? Приходилось ли вам писать XSLT преобразование?
Ресурсы для изучения:
Поверхностно про REST API, а заодно и HTTP, SOAP и JSON - это все есть в статье
Про сообщения HTTP
Подробнее про REST, HTTP и SOAP и все связанное с этими темами можно почитать как минимум в википедии и этого на мой взгляд уже будет достаточно для большинства интервьюеров (при условии, что вы понимаете о чем говорите, конечно)
Важно понимать
Мало знания теории по той или иной теме, нужны и навыки практического применения этих знаний. Важно уметь погружаться в предметную область, раскапывать все до мелочей, анализировать добытую информацию и делать на основе нее корректные и полезные выводы. Любое развитие предполагает решение задач по выбранной тематике и наработку опыта. Поэтому изучайте реальные кейсы, пытайтесь продумать как бы вы решали подобные задачи, анализируйте чужой опыт, старайтесь найти альтернативные пути, узкие места, потенциальные ошибки в знакомых вам системах, ищите общее в подходах к проектированию систем. В общем, тренируйте свою “нейросеть” мыслить аналитически :)
На мой взгляд, сейчас идеальное время для вхождения в профессию и развития в ней. Рынок предлагает огромное число вакансий для аналитиков с очень достойной оплатой труда и возможностью удаленной работы (к слову, для тех, кто находится в поиске – у нас в компании вакансий тоже много).
А какие из вопросов встречались на собеседовании у вас? Возможно какие-то вопросы вам кажутся неуместными для СА?
Иллюстрации: Михаил Голев
