Всем привет!

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

Список тем и вопросов к ним:

1. Методологии разработки ПО и жизненный цикл разработки ПО.

   1. Какие методологии разработки вы знаете? (Тут нужно рассказать про эджайл, водопад хотя бы. Можно и про остальные упомянуть, но обычно не требуется).

   2. В чем отличия между ними? Какие у них есть особенности?

   3. Расскажите про жизненный цикл разработки ПО. Какие этапы проходит задача\продукт до выхода в прод? (Лучше рассказывать своими словами, просто как понимаете)

   4. Расскажите про состав команды разработки - какие есть позиции и какие функции выполняет каждая из них? Какую роль выполняет системный аналитик? (Кстати, очень "забавно", но когда собесил людей на стажировку СА и даже некоторых джунов - много кто не смог толком ответить на последний вопрос. Т.е. люди банально даже не погуглили хоть чуть-чуть и не проходили по первым ссылкам гугла, чтобы немного подготовиться к собесу и понять куда они вообще идут. Про какую уж тут позицию СА можно говорить - не надо так)

2. Требования.

   1. Самый частый задаваемый вопрос для джунов (потому что, ну а что еще спрашивать?) - расскажите про виды требований, которые знаете. Приведите примеры таких требований.

   2. Какие качества требований вы знаете? Приведите пример требования, которое удовлетворяет всем качествам.

   3. Какие методологии сбора требований вы знаете? Какими из них пользовались?

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

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

   6. Какими инструментами для фиксирования требований вы пользовались? Какие в принципе существуют? (Тут есть достаточное разнообразие инструментов - от ворда и согласований ТЗ по почте до связки asciidoc + git. Дефолт - это jira\confluence)

   7. Как определить, что задача успешно вышла в прод? (Тут просто на рассуждение. Можно сказать, что признаки успешности - отсутствие инцидентов на проде, положительные фидбеки от пользователей, стабильность работы системы и вот это всё)

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

3. Диаграммы.

   1. Какие нотации вы знаете? (UML\BPMN\IDEF0 и вот это всё)

   2. Какие виды UML-диаграмм вы знаете? Для чего они предназначены? (Тут тонкий момент, что если вас начнут спрашивать, а какие вы знаете типы стрелочек и когда какую применять - имхо это уже эребор и не нужно это знать наизусть. Я, например, не знаю, хотя регулярно это использую и обучаю - всегда можно за 30 секунду загуглить это. Но общую теорию по типам диаграмм надо знать)

   3. Что вы знаете о BPMN, для чего эта нотация нужна? Приходилось ли использовать на практике?

   4. В чем отличия между этими нотациями? Какие у них преимущества?

   5. Могут показать, как вариант, какую-нибудь схему и спросить что на ней нарисовано. Такой подход мне нравится.

4. UC\US.

   1. Что такое пользовательские истории? Приведите шаблон, по которому они составляются и пару произвольных примеров.

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

5. Любые задачи, которые только можно придумать на сбор требования\моделирование каких-либо ситуаций\игра в аналитика-заказчика - насколько хватит фантазии и желания у интервьюера.

Почти на все эти вопросы вы можете найти ответы в этой серии постов.

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

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

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

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

В следующей части перейдем к списку вопросов уже по хард-скиллам.

P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.

P.P.S.: Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть и хардовая информация (асинхронные, синхронные интеграции, примеры ТЗ\шаблонов написания микросервисов), так и более софтовая - см. закрепленный дайджест.