Всем привет!

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

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

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

А дальше будем отталкиваться от поступающих запросов.

Подписывайтесь и добро пожаловать!

За хлестким дизайном как обычно к Сереге https://news.1rj.ru/str/baztruman

Процесс собеседования

Итак, вы решили найти/сменить работу, что дальше? Поиск и попадание на техническое интервью - это свой процесс, который можно разбирать отдельно. Давайте представим, что рекрутер вам уже написал.

Перед тем, как вступать в долгую переписку уточните три основных момента: предполагается ли у вакансии удаленный формат работы, сколько этапов отбора и какая вилка у вакансии. Ведь пройдя несколько этапов, будет очень неприятно узнать, что работать можно только в Москве, а после первого технического вас ждет ещё практика, системный дизайн, поведенческое, знакомство с командой и бабушкой технического директора. Предлагают же за это удовольствие 100к денег до выплаты налогов.

Кстати, на вопрос о вилке рекрутеры часто отвечают что-то в духе: «Мы не можем сказать, какие у вас ожидания?» Пожалуйста, не юлите и прямо называйте ту сумму, которую вы хотите. Во-первых вы сэкономите время, а во-вторых, если собеседование пройдет удачно, всегда можно поднять зп на этапе переговоров. Есть вероятность продешевить, но чтобы этого избежать, всегда изучайте рынок, и указываете желаемую зп чуть больше.

От компании к компании количество и продолжительность этапов интервью может отличаться, но чаще всего встречаются следующие:
⁃ Скрининг. Короткое знакомство с рекрутером и ответы на базовые вопросы. Этакая проверка на адекватность. Как правило не занимает более получаса.
⁃ Техническое интервью. На нем проверяют «харды», вопросы по бизнес и системному анализу, задачи и все что компания считает важным. Продолжительность от часа до полутора. Технических может быть от одного и до бесконечности.
⁃ Знакомство с командой/СТО. Формальная встреча, на которой редко спрашивают что-то техническое. Скорее как завершающий этап перед получением оффера.
⁃ Тестовое задание - только для джунов. Нет, предлагать его могут всем, но я не вижу смысла делать тестовое специалистам выше миддла. Спрос на аналитиков в РФ гигантский, скорее найдете компанию, где смогут проверить ваши скиллы без тестового (например, только на техе). Дают, как правило, после скрининга, но могут и после технического.

Отдельно хочу выделить скрининг. Подготовьте ответы на все банальные вопросы: почему решил сменить место работы? Какие сильные и слабые стороны? Кем видишь себя через пять лет (шучу, такое перестали спрашивать). Здесь очень важно правильно ответить на 2 вопроса: активно ли ищете работу и есть ли офферы на руках? Работу вы ВСЕГДА ищите активно, и офферы ВСЕГДА есть. Ответив так, рекрутеры будут понимать, что лучше лишний раз не затягивать и сразу назначать вам следующие этапы. Ведь хороших специалистов терять совсем не хочется. Ну и не забываете задать свои вопросы, но больше по организации. На что-то глубокое вам вряд ли ответят.

Техническое собеседование разберем в следующих постах отдельно. Если остались вопросы, прошу в комментарии.

#база

Дайджест полезного #1

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

1) Видео на тему «Кто такой бизнес-аналитик». Подойдет для тех, кто только познает профессию и не может понять разницу между бизнес, системным, BI, аналитиком данных и т.д. Ролик в целом дает верное представление по всем темам, кроме зп – сейчас на системных аналитиков вилки выше.

2) Статья «Как мы используем Camunda в Банке ДОМ.РФ». Построение архитектуры с использованием одного из самых известных оркестраторов. В интеграционных задачах с кучей сервисов – мастхэв. Когда интеграционный адаптер только преобразует данные, а вся бизнес-логика (последовательность вызовов, частота повторов и т.д.) крутится в Camunda. На моей работе юзаем ее похожим образом.

3) CORS для чайников: история возникновения, как устроен и оптимальные методы работы. Здесь уже фронт часть, и как работают «корсы». Собственно, если вы аналитик фронтовой команды, то разбираться в принципах работы cross-origin запросов стоит. Сам столкнулся с проблемой, когда внутренний портал компании на все запросы отвечал внутренней ошибкой. Оказалось, «корсы», сменил браузер (с хрома) и все заработало.

4) 600к в секунду - Как не растратить все айтишные деньги. Набор мнений по работе с популярными финансовыми инструментами. Для тех, кто в финансовой грамотности понимает постольку поскольку, и остаток денег предпочитает скидывать на счет – самое то. В качестве одного из спикеров выступает Алексей Марков, автор книги «Хулиномика».

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

Один день системного аналитика

В качестве ретроспективы выкладываю пост, который писал для канала «Один день ITшника», где рассказывал чем занимаюсь на работе. Для тех, кто только вкатывается в профессию, должно быть полезно. За прошедший год подход к работе не поменялся, а вот инструментарий расширился – теперь ведем доку в Git, используя AsciiDoc, PlantUML и OpenAPI. Если будет интересно, расскажу об этом отдельно.

Работаю через галеру, проект финтех, команда интеграций. Состав команды: лид, менеджер, 5 Java разработчиков, 2 QA, 3 SA, 2 Support, DevOps. Работаем по Agile, хотя спринтов нет. Каждый день дейли, 2 раза в неделю груминг, примерно раз в месяц ретро. Раз в 2 недели проводится встреча аналитиков из всех команд, где рассказываем, что было сделано и какие проблемы, делимся опытом.

Команда занимается разработкой интеграций с партнерами (банками). Те присылают API, а мы уже перекладываем на свой процесс. Большинство интеграций укладываются в рамки стандартного процесса, и доработка не требуется (то есть расширять модель данных на прием новых полей, нестандартную обработку существующих не требуется). Но бывают исключения. Вся разработка ведется по техническим спецификациям, которые как раз составляет системный аналитик.

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

Техдолг: самые простые задачи, функционал был реализован когда-то давно, но по нему нет документации. Первым делом иду в Git и смотрю, как функционал был реализован. Потом смотрю API партнера. Если какой-то инфы не хватает, запрашиваю у менеджера (взаимодействие с партнерами (бизнесом) осуществляется через менеджера). Когда получил всю инфу, начинаю составлять спецификацию. Под каждый метод создается отдельная статья в Confluence. У команды есть шаблоны описания спеки, но они стандартные. Из чего состоит спека:
- пример сообщения, которое поступает в адаптер (XML);
- очередь, в которую помещается это сообщение;
- пример сообщения, которое будет отправлено партнеру (JSON);
- описание исходящего сообщения (поля, примеры, типы, обязательность, значение из модели данных);
- пример сообщение, которое получаем в ответ;
- описание входящего сообщения (поля, примеры, типы, обязательность, значение из модели данных);
- парсинг входящего сообщения;
- очередь, в которую входящее сообщение отправляется;
- тестовые и продуктивные урлы.
В процессе тестирую API партнера через Postman, чтобы удостовериться, что он реально работает так, как указано в их доке (чаще всего работает иначе). Если возникают вопросы, смотрю как реализована обработка того или иного сообщения в коде.

В конце составляю Sequence Diagram (диаграмму последовательности) вызовов каждого метода, чтобы можно было легко понять, как это вообще работает.

После выполнения задачи отдаю ее в тестирование. Тестировщик пишет тест-кейсы и на этом техдолг считается закрытым.

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

Разработка новой интеграции (с доработкой процесса): если интеграция требует доработки бизнес-процесса, например, партнер использует поля, которых нет в модели данных или методы, которые ранее у нас не использовались, и мы понимаем, что это не единичный случай, принимается решение о доработке с нашей стороны. Ставится задача на соседнюю команду, которая расширяет модель данных. Если изменяется бизнес-процесс, например, добавляется новый метод, то изменения вносятся в Camunda (оркестратор бизнес-процессов). Эти доработки делает соседняя команда, аналитики из нашей команды ставят им задачи.

Процесс собеседования. Самопрезентация

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

Итак, чего же ожидает интервьюер, задавая вопрос: «Расскажите о своем опыте?» Как ни странно, короткий, наполненный рассказ о решаемых задачах и ваших сильных сторонах. Подумайте над структурой, чтобы не прыгать от проекта к проекту, а логично изложить ключевые моменты. Если опыта и компаний слишком много, то лучше рассказать о последних двух местах работы максимум. Что там было раньше мало кого интересует.

Сам я придерживаюсь следующей структуры:
1) Приветствие. Представляюсь, говорю о том на каких проектах работал, и сколько у меня опыта.
2) Рассказываю об одном-двух проектах – что делал? по какой методологии работал? размер команды? какие артефакты оставил после себя? какие инструменты использовал? В этом блоке подсвечиваю все ключевые слова из вакансии: работали по SCRUM, архитектура микросервисная, интеграция рестовая, в качестве асинхронного взаимодействия использовали брокер и т.д. Все, что интервьюер хочет услышать, он получает здесь.
3) Отдельно выделяю какую-либо сложную задачу, которая выбивается из стандартной рутины. Рассказываю о ней как с точки зрения техники, так и с точки зрения влияния на бизнес.
4) Полирую эту красоту дополнительными фишками, которые выделяют меня на фоне остальных. Например, говорю о том, что активно менторю и веду тг-канал. Заканчиваю всегда фразой: «Если остались вопросы, готов обсудить»

Казалось бы, ничего сложного, но кандидаты часто допускают ряд ошибок, портящих общее впечатление:
1) Структура рассказа может совсем отсутствовать. Аналитик прыгает с темы на тему и теряет нить повествования. Как правило, такие кандидаты не пытаются ответить на вопрос, который видят впервые, а сразу говорят: «Я не знаю».
2) Рассказ слишком затянутый. Такое встречается у аналитиков с большим опытом, а также людей 35+ Они расскажут вам, как учились в университете в 90х, как в нулевых работали на заводе, ближе к десятым дошли в IT, а потом время интервью выйдет…. Справедливости ради, если окажетесь в роли интервьюера и попадаете на такого кандидата, ставьте вопрос точнее: «Расскажите о последнем месте работы аналитиком?»
3) Рассказ привязан к прошлому, специфичному опыту. Тут вроде слушаешь, и ТЗ они писали, и ФТ согласовывали и тендеры выигрывали и что только не делали. На деле, кандидат выполнял роль человека-оркестра где-нибудь в государственной компании, и с трудом представляет, как организована современная разработка.

Интересно узнать ваше мнение по поводу презентации себя, поэтому всех желающих прошу в комментарии.

#база

Дайджест полезного #2

Сегодняшний дайджест посвящен вопросам, которые задали моему менти на собесах в синюю компанию. Что интересно, за неделю он прошел 4 интервью на разные позиции, получил 2 оффера и завалил 2 собеседования. Вопросы попадались преимущественно разные, и как это может быть в рамках одной компании, конечно, загадка. Поэтому вот вам первый совет – не отчаивайтесь и проходите как можно больше собеседований, качайте навык и все получится. Итак, что меня удивило:

1) «В чем разница между партиционированием и шардированием». Да, вопросы по базам задают практически на всех интервью, но до масштабирования доходят редко. Тем не менее это важная штука, особенно для аналитиков бэка. Обратите внимание, что вопрос звучит нетипично, чаще можно услышать: «В чем разница между шардированием и репликацией». Тем не менее, вот ворох полезных материалов по теме: масштабирование баз данных через шардирование и партиционирование, партиционирование в PostgreSQL, шардирование vs репликация

2) «Что такое Long Polling?» Ответ гуглится за минуту, но, из описания становится понятно, что Long Polling имеется сходства с WebSocket, другой асинхронной технологией. И вот тут я немного потерялся: в чем разница между Long Polling и WebSocket и в каких ситуациях стоит применять эти технологии? Нашел хороший материал, объясняющий разницу. Вдогонку, статья о разнице WebSocket и gRPC, ведь они тоже похожи 😊

3) «Как скрыть headers и body от пользователя в браузере?» Не до конца понятно, для чего это знание системному аналитику, но допустим. Материал о том, как скрывать элементы страницы с помощью HTML атрибутов и CSS стилей. А если речь идет о скрытии заголовков запроса, то выполняется это в конфигах на сервере, почитать об этом можно тут

P.S. В качестве бонуса прикладываю тг-канал с популярными вопросами на собеседованиях СА в формате тестов.

Всем продуктивной недели)

@notsystemanalysis

«А вдруг я не смогу?» или синдром самозванца не дремлет

Примерно так звучит самое распространенное опасение моих менти. Ситуация: ты классный системный аналитик, получаешь Х денег и решаешь сменить работу. Читаешь вакансию на миддла – подходишь, читаешь вакансию на сеньора – тоже подходишь, но не откликаешься, потому что «там точно очень сложно, я не пройду». Или откликаешься, но просишь 1.5Х, хотя вакансия предполагает и 2Х и 2.5Х денег. Почему? Потому что «ну если я столько попрошу, это большие деньги, а вдруг я не справляюсь?»

Попробуйте следующее упражнение: посчитайте за год свой доход при зп 1.5Х (которую хотите просить) и при 2.5Х (которую дает компания и рынок). Сравните их и прикиньте, стоит ли страх или ложная скромность потери такой суммы?

Синдром самозванца очень распространенная и неприятная штука. С ним можно и нужно бороться. В случае, когда аналитик думает «я не смогу» мне видится 2 исхода и оба выигрышные:

1) Ты проходишь собеседование и получаешь кратно больше текущей зарплаты. Ты вливаешься в коллектив, успешно закрываешь испытательный срок и работаешь дальше. Значит твой страх «а вдруг я не справлюсь» нерациональный. Ты попробовал и справился, ты красавчик и победил. Зачем же тогда было переживать?

2) Ты и правда не справляешься с темпом и объемом. Работаешь несколько месяцев и тебя увольняют с испытательного срока. За это время ты получаешь деньги, а еще опыт решения задач. Понимаешь, что было не так и что можно было улучшить, чтобы не попасть в такую ситуацию повторно. Выходишь на рынок и находишь вакансию еще лучше. Страшно? Да вроде не очень.

В качестве послесловия еще раз напомню, собеседования и работа – это два абсолютно разных процесса. На собеседовании аналитик продает себя, и чем дороже, тем лучше. Если получен оффер, значит компанию все устраивает, и она верит, что аналитик справится.

Почему же ты не веришь в себя?

#база

Истории успеха #1

Запускаем рубрику, в которой аналитики делятся своими историями успеха. Первый гость - Максим, он устроился на позицию системного аналитика с зарплатой 200к, имея 0 лет реального коммерческого опыта. Действительно мощный старт карьеры. Я задал Максиму несколько вопросов, чтобы лучше понять, как ему это удалось:

1) Чем занимался до аналитики?
У меня кмс по легкой атлетике, буквально жил спортом, плюс пытался подрабатывать и заканчивал быдловуз(строительный)

2) Системная аналитика - не самое популярное направление в ИТ, почему решил выбрать именно его?
Хотел стать продактом, нравилось программирование, ну и как-то так;)

3) Сколько и как обучался до выхода на собеседование?
Почти не выходил из дома, обучался по 8-10 часов с перерывами, с утра жесткая техничка, вечером пивные статьи (вышло где-то 2-3 месяца)

4) Сколько собеседований потребовалось для получения оффера?
7-8, в основном отсеивался из-за того, что дальше во мне хотели видеть больше БА

5) Что было самое сложное в процессе обучения?
Не знаешь, что надо знать, ментор кое-как исправлял этот недуг)

6) Когда опускались руки, что помогло не бросить и дойти до конца?
У меня в марте сгорела съемная квартира со всеми вещами, надо было закрывать диплом, деньгами меня никто не обеспечивал, дали общагу от вуза до июня, у меня не было права что-то бросать))

7) Какой совет ты дал бы сам себе в начале пути?
"Все люди когда-то были глупыми, не надо их бояться"

А какой была ваша первая зарплата в ИТ?

Дайджест полезного #3

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

1) «Как понять, что User Story составлена корректна? Есть ли какие-либо методологии?» Здесь либо не отвечают ничего, либо вывозят на опыте. Прикладываю хорошую статью, где подробно рассказали и о методологии INVEST и о критериях приемки.

2) «Какие паттерны реализации микросервисной архитектуры можешь назвать?» Задаю этот вопрос в блоке об архитектуре, очевидно, что при работе с микросервисами есть некий набор правил. Статья покрывает большинство популярных паттернов, от декомпозиции (DDD) и рефакторинга (Strangler) до развертывания и мониторинга.

3) «Можно ли использовать GET для создания ресурса, а POST для получения информации о ресурсе». Можно, но кандидаты теряются на этом вопросе. При таком подходе приложение не будет RESTFul, но технически ограничений нет. Не забываем, что в GET для передачи информации используются query параметры, а в POST полезная информация содержится в body. В этом материале доступно разбирают разницу между GET и POST.

Какой вопрос вызвал у вас затруднение на последнем интервью?

Какой понедельник без мема :)

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

Все, что вы любите!

@notsystemanalysis

Процесс собеседования. Бизнес анализ

Итак, с презентацией себя разобрались. Вы складно рассказали о своем опыте, произвели первое положительное впечатление, теперь настало время проверить харды. Вообще интервью делится на 2 типа: компания может спрашивать общую информацию по бизнес/системной аналитике (топ-100 вопросов на СА) или же задавать специфические вопросы по стеку, который используют. И если первый тип мы сегодня разберем, то ко второму подготовиться проблематично, потому что все, что у вас есть – это вакансия. Вы и без меня знаете, что ожидание и реальность сходятся достаточно редко. Ну да ладно, давайте к теме.

В блоке по бизнес-аналитике спрашивают классические вещи из «Разработки требований к программному обеспечению». От роли БА/СА на проектах и видов требований до документирования и моделирования. В последнее время на вопросы по бизнес-анализу выделяют не так много времени, зато активно спрашивают по системному, а конкретно интеграциям. Но это тема следующей статьи. Структурно блок БА делится на следующие части:

1) Общие вопросы о роли БА/СА
2) Жизненный цикл проекта и гибкие методологии
3) Работа с требованиями
4) Работа с документацией
5) Моделирование

И чем уровень кандидата ниже, тем больше теоретических вопросов он получит. Более опытные коллеги, могут избежать «базы», если подсветят ключевые слова в рассказе о себе. Вообще информация не секретная и лежит в открытых источниках, большинство теоретических вопросов спокойно заучиваются. Давайте рассмотрим каждую из частей блока БА подробнее:

Общие вопросы. Здесь спрашивают о том, чем вообще занимается бизнес/системный аналитик. Какого его роль и ценность в команде? Какие задачи он решает? В чем разница между бизнес и системным аналитиком? А может быть можно обойтись вообще без аналитика? Какие артефакты являются результатом работы аналитика? Какие инструменты он использует?

Жизненный цикл проекта и гибкие методологии. По жизненному циклу не так много вопросов, тут скорее важно понимать, какие этапы ЖЦ существуют и что на них делает аналитик. А вот по гибким методологиям спрашивают хорошо. Что такое SCRUM и Kanban? В чем разница между этими подходами? Какие роли и церемонии есть в SCRUM? Назови манифесты Agile. Исключительно теоретические знания, которые не применяются в работе, но почему-то спрашивают.

Работа с требованиями. Спрашивают вообще все что касается требований. Привести классификации требований. Какие методики сбора требований существуют? Какие применить в той или иной ситуации? Как управлять требованиями? Как валидировать и верифицировать их?

Работа с документацией. Все что касается документирования и фиксации требований, как традиционные виды (ТЗ), так и гибкие (Use Case/User Stories). Какие разделы бы включили в ТЗ и почему? Как составили бы интеграционную спецификацию? Знакомы ли с ГОСТ 34? Что такое Use Case и User Stories, приведите примеры?

Моделирование. Спрашивают знание основных нотаций. Что такое BPMN и какие элементы есть? Какими диаграммами UML пользуешься? Плюс конкретные вопросы по отдельным UML диаграммам, в духе – Какие виды связей на диаграмме классов можешь назвать?

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

Если есть необходимость разобрать практическую часть блока по бизнес-аналитике – пишите в комментарии, с удовольствием сделаю.

#база