Астрологи объявили рабочую неделю.
Рекомендуют смотреть мемы для поднятия настроения!

@notsystemanalysis

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

Подобрались к самому вкусному. В рамках интервью блок системного анализа подразумевает проверку технических навыков кандидата. Реалии таковы, что это наиболее важный сегмент, показывающий ваш уровень. К теории подготовиться реально, хоть и немного сложнее, чем в бизнес анализе. А вот практика дастся легко, если уже работали с той или иной технологией. В ином случае, некоторые абстрактные концепции могут вызывать трудности. Глобально, секция системного анализа делится на три темы:

1) Архитектура ПО
2) Веб-сервисы
3) Базы данных

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

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

Веб-сервисы. За этой темой кроятся вопросы, затрагивающие интеграцию. Причем от верхнеуровневых, до конкретных. Какие виды интеграции можешь назвать? В чем разница между синхронной и асинхронной интеграциями? Что такое REST и SOAP? В чем разница между ними? Что такое ESB? В чем разница между брокером и ESB? Какие способы аутентификации можешь назвать?
На самом деле, тут копать и копать, можно выдергивать отдельную технологию и рассуждать о ней. Но наиболее часто и глубоко спрашивают про REST. Что такое RESTful принципы? Какие методы HTTP можешь назвать? Какие методы идемпотентны? Какие коды ответов знаешь?
Из интересного, меня однажды спросили: «Почему для реализации чата используется WebSocket, а не gRPC?» Как бы вы ответили на такой вопрос?)

Базы данных. Классика, которую спрашивают, как у бизнес, так и у системных аналитиков. Чаще всего просят решить простенькую задачу на SQL, с использованием JOIN, и агрегатных функций. Если говорить о теории, то я бы выделил следующие вопросы: В чем разница между SQL и noSQL базами данных? Что такое нормализация? Что такое транзакция? Какие способы масштабирования БД можешь назвать?

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

#база

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

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

1) Чем занималась до аналитики?
Работала в саппорте

2) Системная аналитика - не самое популярное направление в ИТ, почему решила выбрать именно его?
Знакомый вкатился на ба, а потом на са. Рассказал, что это реально и можно не просто тухнуть на обычных работах, я решила, что мне по духу ба проходит

3) Сколько и как обучалась до выхода на собеседование?
Сначала обучалась сама, смотрела всё что можно, потом обратилась к Андрею, и он помог уложить всё в голове, также разобрали bpmn и uml

4) Сколько собеседований потребовалось для получения оффера?
Я вкатывалась, поэтому мне понадобилось больше, чем людям с реальным опытом
Искала работу примерно месяц, проходя по 3-4 собеса в день. Короче без напряга

5) Что было самое сложное в процессе обучения?
Найти уверенность в себе и своих силах, наверное

6) Когда опускались руки, что помогло не бросить и дойти до конца?
Нехватка денег 🤣

7) Какой совет ты дал бы сам себе в начале пути?
Ссать и делать!

А что было самым сложным в обучении для вас?

Каналу месяц!

(Не)Системная аналитика появилась ровно месяц назад, 16 августа. За это время мы с вами плавно преодолели отметку в 150 человек! Для меня это огромная цифра, спасибо каждому кто подписался. Мы пилили посты и мемы, делились полезным и заряжались на успех. Я очень рад, что смог найти единомышленников среди вас, надеюсь, что вам интересно. Впереди большие планы, бэклог заполнен идеями, поэтому без контента вас не оставлю.

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

Еще раз спасибо, что подписаны на меня! Лучшая благодарность за контент – рассказать о канале знакомым аналитикам, вдруг им тоже понравится.

Обнял, приподнял,
Андрей

З.Ы. В комментариях принимаю идеи по улучшению канала. Чего не хватает, а что можно убрать?

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

ДИСКЛЕЙМЕР: Автор канала не является дипломированном психологом и предлагает решения, основываясь исключительно на житейском опыте. Если вы чувствуете проблемы, с которыми не можете справиться, обратитесь к специалистам.

Сегодняшняя подборка содержит статьи околоайтишной тематики. Проблема, которая наиболее часто встречается у ребят на консультациях – синдром самозванца. Кто-то сомневается в своих способностях и боится попробовать новое, а кто-то прямым текстом говорит: «Да, у меня синдром самозванца». Хотя никакого отношения к медицине «синдром» не имеет. Тем не менее ловите ссылки на три полезные статьи, еще раз убеждающие вас в том, что вы все сможете!

1) «Что такое синдром самозванца и почему необязательно с ним бороться». Статья нетологии, где детально расписываются признаки и разновидности синдрома, а также приводятся советы о том, как побороть свои страхи. Классифицируя виды «самозванцев» поймал себя на мысли, что во мне уживаются все из них.

2) «Синдром самозванца. Как обрести уверенность и начать действовать». Чуть более глубокое чтиво, раскрывающее такие понятия как «эксперт» и «псевдоэксперт». В статье рассматриваются популярные искажения, и возможные корни проблемы. После прочтения картинка в голове вырисовывается четче.

3) «Синдром самозванца в IT: почему возникает и как его преодолеть». Ну и доходим до профессии. Статья является компиляцией того, что описано в пунктах 1 и 2, только с уклоном в ИТ тематику. Поскольку нам отовсюду говорят, что квалифицированный специалист должен постоянно развиваться и прокачивать скилл, очень легко выгореть и загнаться. Не надо так!

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

Утречко!

Напоминаю, без ТЗ - результат ХЗ)

@notsystemanalysis

Процесс собеседования. Вопросы после технического интервью

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

1) «Чем мне предстоит заниматься ежедневно? Что входит в мои обязанности? Расскажи примерный день системного аналитика». Этой пачкой вопросов вы показываете заинтересованность, плюс сразу же более-менее понимаете фронт работ. Да, есть описание вакансии и рассказ рекрутера, но они, как правило, очень абстрактные. Здесь же, человек, который реально занят в компании, сможет рассказать о боевых задачах. Ответ в духе: «Ну, у нас вообще-то не было никогда системного аналитика, и мы его берем, потому что это круто и модно» - плохой. Если только позиция не предполагает выстраивание аналитики с нуля, но там и компенсация соответствующая.

2) «Каким образом выстроены рабочие процессы? По какой методологии работаете?» Нужны для представления о том, как будет проходить работа. Можно ли решать задачи в конвейерном режиме или же придется постоянно сидеть на звонках, обсуждая каждый чих. Четкий и описанный флоу, а также его понимание, сильно упрощает и ускоряет работу. Если вам ответят: «Каждая задача уникальна и требует тщательного обсуждения со всей командой», знайте, в таком месте лучше не работать.

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

4) Вопросы, которые волнуют вас по прошлому опыту. Например, переработки, KPI и прочее. Узнавайте обо всем, что доставляло неудобства ранее, дабы не нарваться на те же грабли. Например, на прошлом месте работы премиальная часть моей зп (аналитика) зависела от SLA тикетов поддержки. Естественно я первую очередь решал запросы пользователей, а не занимался тем, что мне действительно нравится.

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

В комментариях рассказывайте, какие интересные вопросы задаете вы?

#база

Ребята, привет)

Улетаю сегодня в отпуск, поэтому посты могут выходить нерегулярно. Мемов, само собой, накидал)
Вернусь в начале октября, не теряйте.

Обнял ❤️

Процесс собеседования. Что еще важно знать, чтобы быть эффективнее?

Итак, вы максимально подготовились к техническому интервью. Поболтали с HR, изучили бизнес и системный анализ, придумали пачку интересных вопросов и готовы побеждать. Как вдруг вас посещает мысль: «А может есть что-то еще, что я не учел?» Некие тайные знания, неочевидная информация, обладая которой можно стать лучшим кандидатом. Еще как есть! Делюсь с вами несколькими советами-напоминаниями, которые относятся к процессу интервью в целом.

1) Собеседования и реальная работа практически не имеют ничего общего. Запомните это. Большинство интервью проверяют теоретические знания, а практика отходит на второй план. Работа, в большинстве своей, предполагает решение конкретных, узких задач. Вы можете на автомате клепать синхронные интеграции по имеющейся документации, укладывая их в стандартные процессы. Но это не поможет, если на собеседовании вас спросят об аутентификации, асинхроне, нереляционных БД и тому подобное. Можно быть мощным практиком, но без базы и понимания, почему мы делаем так, а не иначе, собес не пройти. Из этого вытекает второй совет…

2) К собеседованиям нужно всегда готовиться. Теория спокойно улетучивается, когда не пользуешься ей постоянно. Время, потраченное на подготовку, конвертируется в лучший оффер. Будет очень досадно, если вы мастер юз кейсов, но забыли повторить виды требований по BABOK. Глобально это не поставит на вас крест, но точно даст работодателю повод предложить меньше денег. И даже со структурированной информацией в голове, опыт важно правильно подать. Поэтому стоит…

3) Научиться продавать себя как высококвалифицированного специалиста. На собеседовании обе стороны немного лукавят: компания может умолчать об устаревшем стеке или объеме техдолга, но и вы не должны говорить все как есть. Например, SQL вы используете раз в месяц, чтобы проверить наличие данных в базе. На вопрос работодателя: «Владеете ли вы SQL?» справедливо ответить: «Да, владею, использую в работе, строю отчеты». И тут два варианта событий: вам либо предложат решить задачу, которую вы осилите (ведь вы же готовились и повторили синткасис), либо ответят: «Ну, окэй» и пойдут дальше. Всегда подавайте себя чуточку лучше, чем вы есть на самом деле, если возникнут сомнения – вас тут же проверят. Не нужно закапывать самого себя. И наконец последний совет…

4) Всегда торгуйтесь за оффер. Получив долгожданное предложение о работе очень просто сказать: «Да, я на все согласен». Но подождите, есть вероятность, что работодатель сможет дать еще больше. Не бойтесь торговаться. Наиболее простой способ написать что-то в духе: «Спасибо за предложение, вы мне очень понравились, но у меня есть другое предложение, и я не могу выбрать, где мне будет лучше. Есть ли возможность улучшить условия?» Оффер не отзовут и на вас не посмотрят криво. В худшем случае скажут: «Извините, мы не можем изменить условия». Тогда просто примите как есть, и останетесь при своем. Лично мне удавалось за одно сообщение поднять предложение на 25к, как будто вам тоже стоит попробовать.

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

А какие советы по интервью можете дать вы?

#база

Проснулись, улыбнулись)

@notsystemanalysis

https://news.1rj.ru/str/notsystemanalysis?boost

Ну а вдруг)

Как правильно задавать вопросы?

Частенько ко мне на консультации приходят с запросом: «А как понять, что я хорошо работаю?» Казалось бы, ответ очевиден - если проходишь испытательный срок и тебе не подсвечивают очевидных проблем, значит все прекрасно. Но отсутствие обратной связи, где аналитику прямо говорят - «ты красавчик», сильно бьет по самооценке. Вообще, компании заинтересованы в сохранении сотрудников и должны сами выстраивать процессы таким образом, чтобы новичку было максимально комфортно. Правда, как обычно, в какой момент что-то идёт не так, и ты работаешь, работаешь, работаешь, а понимания того, все ли нормально, так и нет.

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

Другой страх: «Вдруг я спрошу вопрос, а он окажется глупый, все подумают что я не знаю эту технологию». Распространенная боль, причем как для джунов, так и для людей с опытом. Для себя я делю все вопросы на две группы: общие и относящиеся к конкретной компании. Общие - легко гуглятся и могут быть решены без привлечения помощи извне. Например, «Как работает постман?» или «Что такое user story?» Я бы не спрашивал такое, а искал ответ самостоятельно.

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

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

В моей практике я именно так и поступил, пришел к руководителю с запросом на one-to-one, ведь только недавно сменил работу и не понимал свой перфоманс. Каждые две недели мы созванивались и делились обратной связью друг с другом. Это очень успокаивает менталку. Вопросы тоже постоянно задаю, ведь многая информация хранится в головах отдельных сотрудников и нигде не отражена.

Не бойтесь общаться, никто не уволит вас за кривой вопрос. Лучше лишний раз спросить/предупредить, чем потратить кучу времени на поиски, промолчать и не успеть в срок.

#база

Как создать хорошую документацию к API?

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

Как обычно, все субъективно, но на мой взгляд в API документе содержатся следующие разделы:

1) История изменений
2) Оглавление
3) Системная информация
4) Алгоритм работы
5) Примеры

История изменений. Здесь все просто, ключевая цель раздела - найти того, кто создавал доку или вносил в нее какие-либо изменения. Обычно делаю в виде таблице с колонками: дата изменения, описание изменений, связанная задача, автор изменений. Если в компании используется Jira/Confluense, связка задачи и доки будет отражаться сразу в обоих местах.

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

Системная информация. Или «нефункциональные требования». Например, требования к аутентификации, порядок ретраев и таймаутов, тип входного и выходного объекта (если описываете адаптер, на вход может прийти XML, а на выходе JSON), название очереди. В общем указывается вся важная информация, которая не относится к алгоритму работы напрямую.

Алгоритм работы. Самое важное. По шагам расписываем, как работает тот или иной метод. Указываем откуда приходит сообщение (из очереди или из внешней системы или по триггеру и тд), прикладываем пример входящего сообщения. Далее описываем что мы делаем с этим сообщением: раскладываем в базу, преобразуем, формируем новый запрос и тд. Допустим, мы формируем новый запрос, тогда прикладываем его пример в формате curl, указываем метод HTTP и url, а также подробно описываем параметры запроса.

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

Затем описываем ответ, алгоритм тот же: прикладываем пример ответа и подробное описание параметров ответа.

Наконец, если требуется обработать ответ, то указываем, как мы его обрабатываем: записываем в поля таблицы или формируем новое сообщение или отправляем в очередь и тд.

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

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

В качестве бонуса, для технического описания API я бы не стал придумывать велосипед и просто использовать формат OpenAPI. Нашел ультимативный гайд, где подробно описано как документировать API.

Если наберем 25 реакций, скину пример своей документации из практики)

#база

Всем привет из Москвы!

@notsystemanalysis

Какой курс выбрать?

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

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

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

Наличие ментора. Ментор - тот человек, который направит и поможет разобраться. Тот, к кому можно обратиться в любой момент. Современные курсы предоставляют такие услуги, но чаще всего за одним человеком может быть закреплено более десяти кандидатов. Сами понимаете, в таком случае один ментор не сможет уделить проблеме достаточное время. Лучше уточнять этот момент заранее.

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

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

В качестве бонуса примеры хороших курсов:
https://getanalyst.ru/education
https://nextway.pro/
https://practicum.yandex.ru/systems-analyst/?from=catalog

И пример неудачного, здесь покрыты темы только бизнес анализа:
https://1.changellenge.com/business-analyst?utm_source=ip&utm_medium=noukash&utm_campaign=youtube240123#join

AI в работе системного аналитика

Думаю, каждый из вас слышал о нейронных сетях и, хотя бы раз пользовался ими. Генерить текст и картинки весело и просто, но удалось ли вам приспособить AI для повседневных задач? Сегодня рассказываю о сценариях использования, и как нейросети ускоряют мою работу.

На текущем проекте документация ведется по принципу Docs as a Code. В качестве текстового описания используется AsciiDoc, для генерации диаграмм PlantUML, а для апишек OpenAPI. На выходе у аналитика получается три артефакта: пошаговое описание процесса, диаграмма классов и Swagger. Теперь представьте, что в API содержится 50 параметров и все их нужно указать в Swagger. Реально, но очень скучно и долго. Для автоматизации этого удовольствия на помощь приходит ChatGPT.

Перед написанием спецификации я всегда тестирую запросы. Примеры прикладывает либо партнер, либо приходится формировать самостоятельно. Из примера запроса можно собрать целый OpenAPI всего одной командой. «Here is Json, convert it into OpenAPI schema». И документ в формате OpenAPI готов. Также ChatGPT можно попросить добавить описание и примеры параметров, но тут нужно быть осторожнее, чтобы не допустить несуразицу. Вложенность объектов, кстати, тоже учитывается.

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

Наконец, очень советую бесплатное расширение для IDEA Codeium, аналог GitHub Copilot. Незаменимая штука в работе аналитика, при создании того же OpenAPI. Плагин удерживает контекст и оперативно предлагает дополнения для документации, ускоряя работу.

А вы пользуетесь AI в работе? Расскажите об этом в комментариях.

Жиза в глаз попала

@notsystemanalysis

Щупаем Postman

Нашел необычный промо материал от команды Postman.

Комикс рассказывает о том, для чего нужны API, и какие возможности предоставляет Postman.

Внезапно, там не только отправка запросов, а, например, встроенный гит.

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

А вы знали, что в постмане можно импортировать и сохранять curl?
Или добавлять скрипты к запросам, например, для сохранения токена в переменную и использования ее в дальнейших запросах?

Наберем 25 реакций и я расскажу как это делать)

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

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

Задача на SQL. Наиболее популярное задание, проверяющее соответствующий скилл. Чаще всего аналитика просят написать SELECT с использованием JOIN из одной или нескольких таблиц, применив агрегатные функции и группировку. Пример реальной задачи: Выведи информацию о Supplier и Category по продуктам, у которых цена выше средней. Для выполнения использовать ресурс

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

Моделирование предметной области. Здесь чаще всего аналитика просят спроектировать какую-либо диаграмму, показав процесс или предметную область. Мне доставался и BPMN, и Sequence, и ER. В зависимости от уровня вакансии компания может вообще не привязываться к какой-либо нотации, а просто проверить системное мышление кандидата. Пример задачи на собеседовании в желтый банк звучит как: Спроектируй логическую модель данных для интернет-магазина по продаже книг. Или другой пример: Спроектируй Sequence диаграмму для процесса оплаты в банковском приложении.

Задача на работу с API. Здесь открывается пространство для творчества. Самая простая задача, найти ошибки в JSON или XML. Вопрос поинтереснее может звучать так: Спроектируй endpoint для интернет-магазина по продаже книг.

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

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

#база

Лайфхаки Postman

Прошлый пост вам зашел сильно! Поэтому, как и обещал, рассказываю о работе с curl и переменными в постмане.

1) Postman позволяет очень удобно работать с curl. Допустим у нас есть запрос:

curl --location --request POST 'https://example.ru/lead-api/lead/check-phone' \
--header 'Authorization: Bearer ***' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'phone=78005553535'

В боковом меню проходим по пути File—>Import и просто вставляем имеющийся curl. Запрос добавится целиком. Вам останется только отправить его.

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

2) Postman позволяет работать с переменным. Одним из сценариев использования является сохранение токена и обращение к нему в последующих запросах, без постоянного ctrl+C, ctrl+V. Для создания переменных тыкаем «Environments», затем «+» и создаем новое окружение, в котором будут храниться наши переменные. Наконец, внутри окружения задаем переменную.

Теперь в запросе переходим во вкладку «Tests» (не забываем предварительно изменить окружение на только что созданное) и пишем две строчки:
var jsonData=JSON.parse(responseBody) – парсим ответ
postman.setEnvironmentVariable("access_token", jsonData.access_token) – записываем параметр «access_token» в одноименную переменную.

Во всех последующих запросах обращаемся к переменной, на время действия токена она будет валидна.

В комментариях предлагаю делиться своими фишками, упрощающими работу с Postman.

P.S. В тему работы с API, недавно выходила статья о документации, заценить можно здесь.

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

@notsystemanalysis