SA | Собеседования

А точно ли рынок джунов мёртв ?

📢 [#РазборПолётов@sa_sobes] - Вкатун с ChatGPT

Вакансия: Системный аналитик
Жалование: 90к (Запрошено)
Сфера: Аутстафф (Проект телеком)

📝 Секция «Общие вопросы»:

🔵Расскажите о себе и вашем опыте. (Классика)
🔵Из кого состоит ваша текущая команда. (Классика)
🔵В каком виде вам поступают задачи. (Классика)

🖥 Секция «Базы данных»:

🔵Зачем нужен SQL. (Неожиданно)
🔵Left join vs Right join. (Классика)
🔵Какие НФ есть и зачем нужна нормализация. (Классика)
🔵Для чего нужна денормализация БД. (Классика)
🔵Опредление 3 НФ. (Редко явно так задают вопрос)

👣 Секция «API/HTTP/Интеграции»:

🔵Зачем нужны HTTP заголовки. (Классика)
🔵Зачем нужны query параметры. (Бывает)
🔵В каких случаях можно использовать заголовки вместо query параметров. (Первый раз)
🔵Что такое REST и чем он характеризуется. (Классика)
🔵Можно ли через PATCH принудительно создать запись. (Первый раз)
🔵Что такое идемпотентность и какие HTTP методы идемпотенты. (Классика)
🔵Как сделать POST идемпотентным. (Часто последнее время)
🔵REST синхронный или асинхронный. (Бывает)
🔵Можно ли REST API сделать асинхронным. (Бывает)
🔵Kafka vs RabbitMQ. (Классика)
🔵Чем шина данных отличается от брокера. (Бывает)

🔴Задача 1: В команде есть дизайнер. Дизайнер дизайнит все экранные формы. Прежде чем передать дизайн в разработку. Нужно ли нам что-то помимо макетов передать в разработку.

Ответ кандидата:

- Нужно поставить созвон чтобы убедиться, что все окей.
- Я бы закинул им ТЗ. В ТЗ были бы скрины макетов.
- Если нужно будет внесу коррективы.

Комментарий редактора: Тут GPT не справился и выдал странный ответ. На самом деле все легко, как минимум можно предоставить описание этих самых экранных форм, где были бы указаны требования к заполнению полей (обязательность заполнения, как пример) и поведение элементов интерфейса (Активность кнопок в том или ином случае).

🔴Задача 1: Как можно сделать описание интеграции в Confluence. Интересует структура статьи.

Ответ кандидата:

- Описать зачем нужен тот или иной поток.
- Указать источники/типы данных/формат.
- Описать валидацию.
- Примеры запросов и ответов/Описание ошибок.

Комментарий редактора: Вот тут GTP неплохо справился.

🔨 Итог: Первый раз делаю обзор вкатунского собеса, где кандидат параллельно вбивает вопросы в chatGTP и зачитывает ответы в первозданном виде. К слову кандидат получил оффер на 90к и интервьюеру по словам HR очень понравился собес. Но есть нюанс - на большую часть вопросов не было дано прямого ответа или ответы были неправильные. Слушая такое собеседование и видя pdf с оффером от кандидата я прихожу к мысли, что есть 2 мира - джуны в чатах СА, которые пишут, что рынок мертв и никого не зовут на собесы и кандидаты у которых все ок, которые без опыта с неправильными ответами на собесе залетают на работу.

Вывод к слову небеспочвенный - у кандидата на руках сейчас 5 офферов из 7 пройденных собесов.

❔ Если ты вкатун/джун, напиши в комментариях насколько тебе сейчас сложно найти работу. ❔

💩 Читатели, ваш вердикт:

😐 — Окак.

😭 — Радуюсь за кандидата, но не от всего сердца.

Подписывайтесь на:
❤@sa_sobes

Доброе утро, коллеги 🚶‍♂️

[#РазборПолётов@sa_sobes] - Душевно поболтали

Вакансия: Системный аналитик
Жалование: 370 000 (На руки получено)
Сфера: Финтех/Банк
Мысли редакции: Немного хаотично, но в остальном все достойно.
Мнение соискателя: Приятный собес. Душевно поболтали.

📝 Секция «Общие вопросы»:

🔵Расскажи про свой опыт.
Как часто: Классика
Зачем: Интерес интервьюера/оценить экспертность/разрядить обстановку, начав с простого вопроса.

🔵 На последнем месте сколько было аналитиков в команде и как вы делили работу.
Как часто: Бывает
Зачем: Оценить конфиг текущей команды, понять как происходит распределение задач/ответственности/шэринг экспертизы.

🔵Какие ожидания от нового места работы. Что для тебя важно.
Как часто: Часто
Зачем: Оценить насколько команда может подойти или нет кандидату.

🔵Для тебя нормально долго вести один продукт или хочется переключаться.
Как часто: Бывает
Зачем: Аналогично вопросу выше.

🔵Факапил(ошибался) ли ты на работе.
Как часто: Редко
Зачем: Оценить уровень честности ибо все мы ошибаемся. Также для оценки способности выкручиваться из подобных ситуаций.

🔵Стакан наполовину пуст или полон.
Зачем: Чтобы было или проверка на шиза и в принципе оценка настроение кандидата.

🔵Как ты перешёл из системных администраторов в системные аналитики.
Как часто: Только если вы были сис-админом.

🔵Ты в основном работал с монолитом или с микросервисами.
Как часто: Часто.
Зачем: Оценка опыта кандидата.

🔵Что ты будешь делать с заказчикам, который компостирует тебе мозг.
Как часто: Часто.
Зачем: Оценка уровня терпения и стрессоустойчивости.

📝 Секция «Требования и Нотации»:

🔵На диаграмме последовательности надо показать параллельные запросы — как отрисуешь. (Бывает)
🔵Как отобразить прерывание/завершение процесса на sequence диаграмме. (Первый раз. p.s. - крестик на конце стрелки)
🔵На BPMN-схеме что означает закрашенный конвертик в квадрате. (Первый раз)
🔵Нужно описать API-спецификацию. Из каких разделов она должна состоять. (Классика)
🔵Опыт описания REST API в формате OpenAPI. (Часто)

🔴Задача: Есть чайник, надо интегрировать с телефоном. Какие требования соберёшь и какие артефакты подготовишь.
Ответ кандидата:

Нужно выяснить зачем нам интегрировать эти 2 устройства. После выяснения причины мы должны выяснить а какие данные должны передаваться. Определяем доступные интерфейсы. Проектируем контракты. Описал бы арх. схему, US, UC, API.

🖥 Секция «Базы данных»:

🔵Как у тебя с SQL. (Классика)
🔵Перечисли основные принципы реляционных БД. (Бывает)
🔵Объясни, что такое нормализация данных и зачем она нужна. (Часто)
🔵Чем отличаются DELETE, TRUNCATE и DROP TABLE. Равнозначны ли операции. (Бывает)
🔵Нужен быстрый кэш — выберешь реляционную, графовую или In-Memory БД. (Бывает)

👣 Секция «API/HTTP/Интеграции»:

🔵Есть две системы. Какие виды интеграций бывают и как выбрать подходящий. (Классика)
🔵С какими брокерами сообщений работал. (Классика)
🔵Был ли опыт работы с SOAP/WSDL. (Бывает)
🔵Чем SOAP принципиально отличается от REST. (Классика)
🔵При передаче большого объёма данных в REST что выбрать JSON или XML. (Первый раз)
🔵Чем POST отличается от GET. Что такое идемпотентность. (Классика)

⚙️ Секция «Иные вопросы технического характера»:

🔵Чем отличаются оркестрация от хореографии. (Очень редко)
🔵Что можешь рассказать про SAML/SSO.(Очень редко)

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

🚀 Запись собеседования доступна по ссылке на Boosty 🚀

💩 Читатели, ваш вердикт:

👍 — Ровный собес.

😭 — Мой стакан наполовину пуст из-за постоянных отказов HR.

Доброе утро, коллеги 🚶‍♂️

Сегодня нечастый кейс на моем канале - собеседование в предприятие из производственного сектора, а еще и в обновленном формате (спасибо читателям за классную мысль ❤️), где помимо частоты вопроса я расскажу с какой целью вам его могут задавать 🗒

[#РазборПолётов@sa_sobes] - Кандидату задают странные вопросы.

Вакансия: Системный аналитик
Жалование: 400 000 (Запрошено на руки)
Сфера: Производственный сектор
Мысли редакции: Разделяю.
Мнение соискателя с цензурой:

***ня какая-та, если честно. будто не СА искали, а сис админа какого-то или фронт разработчика (да-да , там по js были вопросы).

📝 Секция «Общие вопросы»:

🔵Расскажи про свой опыт.
Как часто: Классика
Зачем: Интерес интервьюера/оценить экспертность/разрядить обстановку, начав с простого вопроса.

🔵Что тебе ближе: системный или бизнес анализ.
Как часто: Часто
Зачем: Для оценки того, можно ли вам передать анализ фичи под ключ, начиная от общения с бизнесом, заканчивая написанием требований.

🔵Откуда интерес к CCNA и зачем вообще его сдавала. (Встретитесь с таким вопросом только если у вас в резюме указано наличие сертификата CCNA)
Как часто: Никогда. Встретитесь с таким вопросом только если у вас в резюме указано наличие сертификата CCNA.

🔵Как делите ответственность по архитектуре между тобой или техлидом.
Как часто: Бывает
Зачем: Для оценки того, есть ли у аналитика самостоятельный опыт проектирования или он подобные задачи скидывает на тех.лида.

🔵Из кого состоит команда. Сколько человек какие роли.
Как часто: Часто
Зачем: Оценить в насколько похожих условиях вы работали. Прикинуть насколько легко может пройти адаптация (я во всяком случае с этой целью задаю этот вопрос + мне просто интересно)

🔵Всегда ли отдаешь требования на ревью своему лиду или сразу передаешь в разработку.
Как часто: Бывает
Зачем: Оценить насколько сильно аналитик попадает в целевую реализацию и как часто приходится рефакторить требования перед передачей в разработку.

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

🔵Какие артефакты ты генерируешь как СА.
Как часто: Классика
Зачем: Оценивают инструменты, нотаций, типы/виды/степень погружения СА в технику.

🔵Насколько ты готова работать в роли выделенного БА.

👣 Секция «API/Сеть»:

🔵TCP. Как работает. Этапы установки TCP соединения. (Бывает)
🔵TCP vs UDP. (Раньше часто задавали)
🔵HTTP. Методы и коды ответов. Жизненный цикл HTTP запроса. (Классикус)

🌐 Секция «Браузер»:

🔵Где в браузере выполняется JavaScript. (Первый раз)
🔵Любимые вкладки в DevTools. (Первый раз)
🔵Время загрузки страницы. Как оно считается. Как понять, что страница загрузилась полностью. (Первый раз)
🔵В каком порядке подтягиваются ресурсы (CSS, изображения и прочее). (Первый раз)

❤️‍🔥 Секция «Задачи»:

🔴Задача 1: Опиши как бы ты реализовала корпоративный чат с нуля. Как будешь масштабировать систему при росте нагрузки до 10к RPS.

Ответ кандидата (тезисно):

- Я бы первично уточнила требования: Как должен выглядеть чат, кто с кем может общаться в этом чате. Как глубина хранения сообщения...
- В качестве транспортного протокола можно использовать WS.
- Для хранения переписок использовала бы NoSQL БД.
- Из требований предоставила бы разработчикам: Спецификацию API, Модель БД, НФТ, требования к интерфейсу.
- Предусмотрела бы возможность горизонтального и вертикального масштабирования в случае роста нагрузки.

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

🚀 Запись собеседования доступна по ссылке на Boosty 🚀

💩 Читатели, ваш вердикт:

👍 — Ровный собес.

🌐 — Слишком много вопросов про браузер.

👍 — Новый формат текстового обзора просто пушка!

Продолжение важнейшей новости этой недели

Запускаю старт продаж платного ресурса.

🚀 Подписка Boosty - Собес Starter Pack (1200 руб 900 мес, скидка 25% 4 дня)

🔴Помимо обзоров в основном TG канале + 2 дополнительных обзора собеседования в текстовом формате.
🔴2 видео или аудио записи интервью с опытными кандидатами — учитесь на чужом опыте, экономя своё время.
🔴Бонусный контент, а также контент на интересующие вас темы сделанный исходя из ваших вопросов/пожеланий в закрытом сообществе.

🚀Подписка Boosty - Собес Pro Pack (1600 руб. мес)

🔴Все что входит в уровень "Собес (Starter Pack)".
🔴Без NDA - Названия компаний и реальные офферы, куда кандидат проходит собеседование.
🔴+ от 3 дополнительных аудио-видео записей собеседований (Итого минимум 5 записей в месяц).
🔴К записям собеседований по возможности будет приложена статистика вопросов от кандидатов, которые собеседовались в обозреваемую компанию.
🔴Реакт-видео на собеседования, где я с опытными коллегами: Системными аналитиками, архами и разработчиками обсуждаем ответы кандидата, подмечая его сильные и слабые стороны.

Дисклеймеры:

Первый...

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

и второй...

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

❔ Как всегда отвечу на ваши вопросы в комментариях ❔

Важнейшая новость этой недели

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

На этой неделе я запущу закрытый ресурс для тех, кто хочет увидеть:

🔴Записи реальных собеседований. С ответами опытных кандидатов. (Мне удалось уломать как раз таких, чтобы они дали возможность выкладывать именно записи, в противном случае это не имело бы смысла)
🔴Названия компаний и статистику по вопросам в этих компаниях.
🔴Более частый выход постов нежели на основном ТГ канале.

🚬 Это лишь верхушка айсберга. Остальная информация будет доступна в день старта продаж.

Сразу предвижу следующие вопросы:

Будет ли на основном канале меньше контента чем сейчас ? Или он вообще перестанет выходить?

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

Каким образом тебе удалось договориться с кандидатами и получить их согласие на публикацию собеседований?

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

Насколько актуальны записи собеседований? Может там вообще есть записи за прошлые года с вопросами, которые никто уже не задает.

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

❔ Всех вопросов я конечно же не предвижу, вас уже почти 4000, так что милости прошу не стесняться и задавать вопросы в комментариях ❔

Доброе утро, коллеги 🚶‍♂️

Продолжаю раскрывать ваши финансовые 🤑 чакры и презентую долгожданный обзор собеса на позицию архитектора за 650к.

[#РазборПолётов@sa_sobes] - Бизнес кейс с разбитой банкой огурцов.

Вакансия: Архитектор
Жалование: 650 000 (На руки)
Сфера: Видеохостинги
Мысли редакции: Разделяю мнение соискателя.
Мнение соискателя:

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

⚙️ Секция «System-Design»:

🔴Задача: Спроектировать систему сервиса доставки товаров из dark-strore. Система должна позволять:

🔵Пользователю: Просматривать каталог продукции, добавлять товары в корзину, оплачивать заказ.
🔵Сборщику заказов: Получить заказ на сборку, передать его курьеру.
🔵Нагрузка: 1 город, 500 точек нашего магазина, средняя нагрузка 20 заказов в час на каждую точку, в пике 50 заказов в час, ожидаемый средний объем корзины 10 товаров, в каталоге 200 позиций (общие на все сторы), на совершение 1 заказа уходит 50 кликов
🔵Ограничение: Сами сторы являются клиентами по отношению к нашей системе и работают удаленно с сервером в ЦОД.

Уточняющие вопросы кандидата (К) и ответы интервьюера (И):

К: Dark-store = склад без витрины, верно?
И: Да, только доставка, без самовывоза. Аналоги "Самокат" или "Яндекс лавка".

К: Курьерка своя или внешняя?
И: Только своя, без интеграций.

К: Какие клиенты и интерфейсы?
И: Курьер — моб. приложение, сборщик — web, покупатель — web+mobile.

К: Нужна ли возможность редактировать заказ после оплаты?
И: Пока опустим, чтобы не усложнять.

К: Складской учёт — пополнений и перемещений нет?
И: Только списываем остаток, без адресного хранения.

К: Оплата — стандартный эквайринг, холд/списание?
И: Да, внешний шлюз, сперва hold, финальное списание позже.

К: Каталог общий, но наличие по точкам?
И: Номенклатура единая, наличия разные.

... далее кандидат начал рисовать ...

⚠️ В файле в комментариях к посту будет приложена арх. схема + для упрощения понимания накидал табличку со слов кандидата c описанием каждого сервиса ⚠️

... далее пошли уточняющие вопросы, вот часть из них:

К: Зачем нам нужен API-Gateway и отдельный балансер?
И: Да, пожалуй в этом нет смысла.

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

К: Смоделируем процесс. Я как покупатель открываю МП. Формирую заказ и оплачиваю. В магазине, который осуществляет сборку, одна из позиций представлена в единственном экземпляре. Что произойдет, если это к примеру стеклянная банка огурцов ? И в момент сбора заказа она выскалзивает из рук сборщика и трагически падает на бетонный пол?

И: Collect-service помечает позицию «утрачена» и кидает событие _order_item_removed_ в топик «жизненный цикл заказа». Cart-Order-service ловит событие, перечитывает заказ, пересчитывает общую сумму. Payment-gateway делает частичный возврат на сумму утраченной позиции. Notification-gateway отправляет покупателю пуш / SMS о-том, что товар исключён и сумма изменилась.

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

🔨 Итог: Действительно классное задание, но к сожалению на него было дано достаточно мало времени. Если бы интервью длилось не 1 час, то можно было бы и по верхам описать ключевые контракты, модель данных. Но есть здесь и проблема (как мне кажется), кандидат совсем не затронул тему с кэшированием, статикой, а об авторизации упомянул вскользь.

❤️ Ставь реакцию, если хочешь видеть на канале еще больше архитекторских собеседований. ❤️

💩 Читатели, ваш вердикт:

💳 — Чакра баблоида раскрыта. Хочу лутать столько же! Пошел готовиться к System Design.

🗒 — Я бы ответил лучше. Кандидат много чего не осветил. Пойду писать как надо в комментарии.

👍 — Ровный собес.

Доброе утро, коллеги 🚶‍♂️

[#РазборПолётов@sa_sobes] - Бич собес.

❤️‍🔥 P.S. Для тех, кто не смотрел последний сторис - анонсировал обзор собеседования на позицию архитектора в понедельник.

Вакансия: Системный аналитик
Жалование: 150 000 (На руки)
Сфера: Telecom
Уровень: Middle -
Мысли редакции: Разделяю мысли кандидата, интервьюер учтивый, вежливый. Но спросить могли куда больше конечно же 🚬
Мнение соискателя:

Меня спросили вообще всё. Я так волновался, но собеседование было комфортным.

📝 Секция «Общие вопросы»:

🔵Расскажи про свой опыт работы. (Классика)
🔵Что нравится/не нравится на текущем месте работы. (Классика)
🔵По каким методологиям доводилось работать Waterfall, Agile или иные. (Часто)
🔵Твоя зона ответственности как системного аналитика. (Классика)
🔵А зачем вообще нужен системный аналитик. (А ведь хороший вопрос 🤔)

📝 Секция «Требования и Нотации»:

🔵Требования без заказчика. Что делать, когда не у кого уточнить требования. (Первый раз)
🔵Что должно быть написано в требованиях, чтобы разработчик не задавал дополнительных вопросов. (Первый раз)
🔵Какими критериями должно обладать "хорошее требование". (Бывает)
🔵Трассировка требований. Что это, зачем нужно и как реализуешь на практике. (Редко)
🔵Как документируешь требования. Диаграммы и форматы, в каких случаях что выбираешь. (Часто)
🔵С какими нотациями приходилось сталкиваться на практике. (Часто)
🔵Приходилось ли писать спецификации OpenAPI с нуля. (Бывает)
🔵Кейс: Интеграция двух систем по API. Что включить в требования. (Бывает)
🔵Критерии приемки. Кто пишет, дополняет. (Редко)

🖥 Секция «Базы данных»:

🔵Какие СУБД использовали в работе. (Классика)
🔵Виды СУБД. (Классика)
🔵Уровни моделирования данных. (Бывает)
🔵Преимущества и недостатки при использовании индексов. (Классика)
🔵Кейс: В одной таблице 1 млн записей, в другой, 10 тыс, при написании запроса к какой таблице будешь обращаться FROM, а к какую объединять?

Комментарий редактора: Поясните пожалуйста, кто понял за последний вопрос из секции БД в комментариях.

🖥 Секция «Брокеры»:

🔵Topic vs очередь. (Редко)
🔵В каких случаях желательно использовать брокер, нежели синхронный тип интеграции. (Часто)
🔵Для чего нужен ZooKeeper. (Редко ...)

👣 Секция «REST/HTTP»:

🔵HTTP методы и их различия. (Классика)
🔵Что такое идемпотентность. (Классика)
🔵При запросе в адресной строке какой метод используется. (Редко, GET если что)
🔵Кто виноват если сервер вернул 4xx/5xx ошибку. (Часто)

🔨 Итог: Классический выдержанный собес на СА из 2к21. Местами даже есть интересные вопросы, спрашивали все по списку, на фоне было слышно как проставляют балы/отмечают правильно ответил кандидат или нет.

❔ Вот вроде собес классический, а как будто бы некоторые вопросы странные или мне кажется ❔

💩 Читатели, ваш вердикт:

😭 — Я не могу соотнести задаваемые вопросы с уровнем жалованья. Мне больно.

👍 — Ровный собес.

🔫 — Жду обзор на собес архитектора в понедельник!

Доброе утро, коллеги 🚶‍♂️

[#РазборПолётов@sa_sobes] - Бабло-ориентированный собес

Вакансия: Системный аналитик
Жалование: 440 000 (На руки)
Сфера: Финтех
Уровень: Senior
Мысли редакции: Разделяю мнение соискателя.
Мнение соискателя:

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

📝 Секция «Общие вопросы»:

🔵Опиши процесс: от кого и в каком виде получал задачу как системный аналитик. (Классика)
🔵Как описываешь требования? В виде user-story или иначе. (Классика)
🔴Задача: Разработка озвучила срок реализации фичи исходя из прочитанного ТЗ аналитика. Заказчика не устраивает срок в 6 недель. Как можно его сократить.

Ответ кандидата:

- Можно разделить ТЗ на этапы. Реализовать основной функционал. А дополнительный/не столь приоритетный оставить на потом или вообще его не делать.
- Мы можем вместо самописных решений использовать готовые. Например вместо разработки своего собственного сервиса аутентификации/авторизации использовать KeyCloak.

📝 Секция «Требования и Нотации»:

🔵Какие виды требований ты знаешь. (Классика)
🔵Приведи пример формулировки нефункционального требования. (Бывает)
🔵Какие методологии сбора требований ты знаешь. (Классика)
🔵Какие нотации кроме BPMN ты знаешь для описания бизнес-процессов. (Редко)
🔵Какие инструменты используешь для создания UML диаграмм. (Часто)

👣 Секция «Интеграции»:

🔵Структура HTTP-запроса.(Классика)
🔵У всех методов REST есть body. (Бывает)
🔵Чем PUT отличается от PATCH. (Классика)
🔵Какие HTTP заголовки ты знаешь и что там можно передавать. (Бывает)
🔵Кроме Bearer какие варианты авторизации знаешь. (Бывает)
🔵Преимущества REST и SOAP. (Классика)
🔵Чем Kafka принципиально отличается от RabbitMQ. (Часто)

⚙️ Секция «System-Design»:

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

🔵Клиент должен мочь зайти на сайт, найти книгу по нескольким базовым атрибутам (название, автор, жанр и т. п.) и забронировать её.
🔵Клиент обработки брони пользователю приходит уведомление, что заказ готов к выдаче.
🔵Клиент приходит в лавку, оплачивает покупку на кассе и забирает книгу. Онлайн-оплаты, интеграции с платёжными шлюзами, службы доставок, маркетинг и другая тяжёлая e-commerce-логика не нужна.

Что нужно сделать:

🔵Нарисовать простую компонентную/структурную схему решения (квадратики + стрелки).
🔵Составить физическую модель БД: список таблиц с атрибутами и связями.
🔵Набор REST методов если успеем.

⚠️ Ответ кандидата: В прикрепленном файле в комментариях к посту.

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

❔ Посмотрите внимательно приложенный файл с ответом из секции System-Design. Что там не так?

⚠️ Я не знаю насколько вам было бы интересно, но если текущий пост набирает 150 реакций - сделаю в ближайшее время обзор на собес на позицию арха с жалованьем 650 000 рублей (на руки).

💩 Читатели, ваш вердикт:

👍 — Достойное собеседование.

🎮 — Сложный собес. Кандидату пришлось попотеть, но оно того стоило.

Как не надо проходить собеседования или как кандидата вынесли вперед ногами (ФиналОчка)

📝 Секция «Общие вопросы»(Продолжение):

🔵Почему ищешь новое место работы. (Классика)

Кандидат: Хочу заработать больше денег. Для этого мне нужно больше отвественности. Я считаю моих знаний достаточно, чтобы взять на себя больше ответственности. Также один британский писатель сказал "От работы без забав люди тупеют".

Комментарий редактора: Я клянусь, это не моя придумка. Но за цитату писателя лайк, первый раз такое вижу. А по поводу "Заработать больше денег" - спорно. Всем и так понятно, что ты не хочешь работать за бесплатно, но звучит и воспринимается это, увы, вульгарно. Или я не прав?

🔵А уточнял ли есть возможность развития на текущем месте работы. (Классика)

Кандидат (Далее К): Да, но они дали неясный ответ. И я подумал, что уже пора выходить на рынок.

🔵А есть что-то, что тебя не устраивает в текущей команде. (Классика)

К: Я бы хотел побольше работать с интеграциями и API.

🔵В % соотношении чем больше занимался бизнес или системным анализом. (Бывает)

К: 30 на 70 в пользу БА.

Редактора: Далее интервьюер долго рассказывает про проект, но походу дела задает вопрос.

🔵Ты как-то участвовал в ПСИ. Может быть кто-то другой принимал в этом участие. (Редко)

К: Участвовал архитектор.

🔵Функциональные vs Нефункциональные требования. (Классика)

К: Функциональные требования описывают то, что хочет клиент. Нефункциональные - как должна вести себя система.
Интервьюер (Далее И): А время ответа системы к чему можно отнести?
К: К нефункциональным.
И: А если требование "На UI не должно быть более 5 активных элементов"?
К: К нефункциональным.
И: Требования к СУБД?
К: К функциональным.
И: А как требования к СУБД влияют на функционал системы. Например, клиент мне говорит, что у меня есть лицензия Oracle, поэтому давайте использовать Oracle. Как это повлияет на функциональную часть.
К: К функциональным. Так как тут описывается то что хочет клиент.

🔵Синхронные vs Асинхронные вызовы. Kafka это синхрон или асинхрон. (Классика)

К: Асинхронное взаимодействие, так как не ждем ответа.

🔵Как через http выразить асинхронное взаимодействие.

К: Не знаю

🔵Критерии выбора синхронного или асинхронного взаимодействия.

К: Если нужно в отвечать в режиме реально времени, то синхронно.

🔵Что такое WebSocket и Webhook. (Часто)

К: Webhook это когда клиент отправляет данные на сервер, указывая url. Сервер отвечает на этот запрос, это WS.

🔵Какие форматы передачи данных тебе знакомы. (Часто)

К: JsonSchema

🔵Как ты описывал из чего должно состоять сообщение в Kafka. (Бывает)

К: JsonSchema в формате словаря.

🔵Если в таком сообщении есть поле email. Какие ограничения ты бы ввел на это поле. (Первый раз)

К: Пароль.

И: Нет, я имею ввиду типа количества символов.

К: Если превышает больше 2048, то это можно отправить в теле POST запроса.

И: Что-то я совсем запутался. Я имею ввиду, если у тебя например есть UI, там есть поле E-mail и там есть ограничение на количество символов или допустимые символы. Как мы опишем подобные ограничения.

К: Ну да, мы укажем максимальное количество символов.

Редактор: Интервьюер начал сворачивать лавочку и дал пару советов, что нужно подтянуть.

🔨 Итог: Кандидат подставил левую, правую щеку и свою задницу. Что же по итогу было не так:

🔴Кандидат не читал вопросы с собесов на моем канале (очевидно же 🤣)
🔴Кандидат не шарит за свою легенду.
🔴Кандидат слишком много просит за предлагаемый уровень хардов.
🔴и.т.д. (не хватает символов 😭)

Читая комментарии под последними постами я снова убедился в том, что подписчики моего канала - гигадачы. Я не первый день в IT, но для себя я периодически благодаря вам могу почерпнуть что-то новое. ❤️

❔ Понравилась рубрика с расширенными комментариями треш собесов - ставь реакции, у меня еще парочка таких есть в запасе😁

💩 Читатели, ваш вердикт:

🤔— Это не собес, это стресс тест интервьюера и проверка на выдержку.

🚑 — Ровный собес, всегда так отвечаю.

🤣 — А не дох***и 200к за такое просить?!

Подписывайтесь на:
❤@sa_sobes

Как не надо проходить собеседования или как кандидата вынесли вперед ногами (Часть 2)

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

🔵Продолжение диалога кандидата и интервьюера в рамках секции «Общие вопросы»:

И: А насколько у тебя были детальные требования?
К: Очень детально. Например, клиент подает заявку, там стоит API-gateway, он проверяет пользователь авторизован или нет. Если нет, то отправляет в кейклок, если да то отправляет в сервис заявок. Четко и детально я писал.
Комментарий редактора: 🤦‍♂️🤦‍♂️🤦‍♂️. Очень слабый уровень детализации. Непонятно при чем тут кейклок, если речь про внешних пользователей, которые взаимодействуют по факту с МП разработкой которого наш главный герой вроде как не занимается. Вообще первый раз вижу, что МП, где сидят внешние пользователи (клиенты банка) имеет прямой доступ к бекофисной системе и даже не через свой собственный Backend мобильного приложения.

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

И: А протокол какой?
К: https.

И: Что являлось подтверждением доступа к сервису?
К: Там были приватные и публичные ключи.
Комментарий редактора: Первый раз такое вижу, хотя может быть чего-то не понимаю. Видел или использование JWT или basic auth.

И: Коллеги из Rusprofile добавляли ваш приватный ключ к себе или как?
К: Получается так, да. У них хранились приватные ключи, отправлялись публичные ключи. Чтобы мы уже дешифровали с нашим ключом.
Комментарий редактора: 🤔🤔🤔. Я честно говоря вообще не понял о чем тут речь, как и интервьюер так и сам кандидат.

И: Ну, окей. Получается у вас в качестве фронта было реализовано веб-приложение. А это веб-приложение доступно всем клиентам в сети интернет?
К: Нет, оно развернуто в Active Directory. Там 3 роли: Бизнес администратор, Риск-андеррайтер, руководитель Риск-андеррайтера.

И: А как приходят сами клиенты, которые заявки на кредит оставляют?
К: Есть мобильное приложение и сайт.

И: То есть клиент через мобилку формирует заявку и дальше она уже отправляется к вам в систему. А ты как-то описывал требования к этому приложению.
К: Да, я когда общался со стейкхолдерами я описывал требования к интерфейсу мобильного приложения.
Комментарий редактора: Что-то очень странное, кандидат ведь заявлял изначально, что он был в команде, которая отвечала за разработку CRM, а не клиентской мобилки банка.

И: А Мобильное приложение по какому протоколу общалось с вашим Backend?
К: Web-socket

И: А сайт?
K: По REST-API.
Комментарий редактора: Опять-таки непонятно а зачем нужно использовать 2 разных протокола для общения с одной и той же системой, при том что суть взаимодействия одинаковая, просто платформы разные. В одном случае мы создаем заявку (да, опустим тот факт, что МП приложения для внешних пользователей имеет прямой доступ к системе, которая находится в бек-офисе), а дальше специалисты банка уже рассматривают ее (GET) и выносят по ней решение (PATCH).

И: А почему разные протоколы?
К: Ну, так было принято.
Комментарий редактора: Подобные ответы дискредитируют специалиста, если задается базовый вопрос на тему того как работала система, где он сейчас занимает позицию системного аналитика.

🔨 Итог: Подведу в финальной части.

❔ А какие советы вы бы дали нашему кандидату? Что он сделал не так в этой части собеседования?

💩 Читатели, ваш вердикт:

🤔— Это не собес, это стресс тест интервьюера и проверка на выдержку.

🚑 — Ровный собес, всегда так отвечаю.

🤣 — А не дох***и 200к за такое просить?!

Подписывайтесь на:
❤@sa_sobes

Как не надо проходить собеседования или как кандидата вынесли вперед ногами (Часть 1)

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

Вакансия: Системный аналитик
Жалование: 200 000 (На руки)
Требуемый уровень: Middle
Фактический уровень кандидата: Вкатун

📝 Секция «Общие вопросы»:

🔵Расскажи о себе. На каком проекте сейчас работаешь. Что входит в твои обязанности. (Классика)

Ответ кандидата (Выжимка):

.. Я принимал участие в разработке CRM системы для обработки кредитных заявок и оценки риска. До создания CRM системы заявки отправлялись в табличном виде по почте. Это было неудобно, запутанно, мы создали для этого CRM систему, где риск-андерайтер, руководитель риск-андерайтера могут увидеть, ну, свои действия, события и чем они занимаются...
... В процессе работы я активно взаимодействовал со смежными подразделениями для проработки интеграций. Чем больше четких данных, тем лучше работает интеграция.
... Внедрили Keycloak и JSON Web Token для управления доступами. То есть только авторизованные пользователи могут получить доступ к системе. Back на Java, Front на React. Состав команды: 2 БА, 2 СА, 3 QA, 2 FE, 2 BE, 1 PO, 1 системный дизайнер...

Комментарий редактора: Пока все относительно ок. Но:

🔴В русско-язычном комьюнити СА используется термин не "Системный дизайнер", а архитектор.
🔴Подача в целом сильно хромает, например "Это было неудобно, запутанно". А что это значит? Почему неудобно? Можно сказать: "Целевое решение позволило вести учет кредитных заявок на оценку риска, пользователи (риск-андеррайтеры) получили возможность удобного поиска/фильтрации заявок в системе, вместо поиска по идентификатору заявки/Наименованию контр агента в почте".
🔴"Чем больше четких данных, тем лучше работает интеграция" - тоже не понял.

Из хорошего:

🔴Описан состав команды.
🔴Рассказал про стек.

Далее у интервьюера закрались мысли, что происходит какая-то ху*** 🤔, привожу их дальнейший диалог со своими комментариями:

И: В каком инструменте рисовали sequence диаграммы ?
K: Ну в конфлюенс есть же плагин plantUml

И: А с другими видами диаграмм знаком?
К: Столкнулся с BPMN, UML и ER диаграммой.

Комментарий редактора: Из контекста понятно, что вопрос именно про диаграммы, которые в UML можно нарисовать. BPMN тут явно лишний, тем более что это нотация.

И: Нет, вот именно из UML что-то использовал?
К: Нет, только sequence диаграмму

И: А где вели задачи?
К: В Jira

И: А какие-то еще протоколы использовались в интеграции?
К: https и REST-API. И шифрование данных.

Комментарий редактора: REST - Архитектурный стиль. А шифрование тут при чем вообще?

И: Был ли шаблон требований или в свободном формате описывали.
К: Там был шаблон.

И: Кто занимался описанием структурой БД?
К: Я это обсуждал с системным дизайнером.

И: А это кто ?
К: Это тот, кто полностью отвечает за систему.
Комментарий редактора: Солидная должность у этого системного дизайнера. Настоящий решала из мира IT.

И: А у вас был архитектор?
К: Это как раз он и есть
Комментарий редактора: А, ну теперь понятно.

И: С кем согласовывал требования?
К: С бизнес оунерами, ну, продукт оунерами, стейкхолдерами.
Комментарий редактора: "Классический" СА, который ходит к CEO для согласования API и моделей данных.

И: В том числе и технические требования?
К: Да
Комментарий редактора: Все, фаталити. Интервьюер уже вцепился в нашего кандидата.

И: То есть у вас такой уровень у бизнеса, что он может понимать технические требования?
К: Да

❔ А какие советы вы бы дали нашему кандидату? Что он сделал не так?

⚠️ Как только пост собирает 120 реакций - выкладываю следующую часть треш собеса.

💩 Читатели, ваш вердикт:

🤔— Это не собес, это стресс тест интервьюера и проверка на выдержку.

🚑 — Ровный собес, всегда так отвечаю.

🤣 — А не дох***и 200к за такое просить?!

Подписывайтесь на:
❤@sa_sobes

Всем доброго дня ☀️

P.S. А работягам отдельные соболезнования, завтра опять выходим на завод 😭

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

Вакансия: Системный аналитик
Жалование: 310 000 (На руки)
Уровень: Senior
Мысли редакции: Приятный интервьюер, местами даже есть интересные вопросы. Но в остальном банально.
Мнение соискателя:

Скучно как-то, ребята даже не знаю куда и кого ищут.

📝 Секция «Общие вопросы»:

🔵Почему хотите сменить текущее место работы. (Классика)
🔵Какие типы проектов / доменные области вам интересны, а от каких готовы отказаться. (Часто)
🔵Опыт лида: приходилось ли руководить другими аналитиками, помогать «растить» лида. (Бывает)
🔵Долгие (3-летние+) водопадные госконтракты — комфортно ли работать в таком формате. (Редко)
🔵Есть ли в вашей практике единые шаблоны задач, ритуалов, форматов документов. (Не часто, в основном только в разрезе документации такое спрашивают)
🔵Приходилось ли полностью писать документацию по ГОСТ-34. Как к этому относитесь. (Редко, специфика гос/около-гос проектов)
🔵Формат работы: офис/удалёнка/гибрид — что приемлемо, что нет. (Редко)

📝 Секция «Требования и Нотации»:

🔵С какими нотациями работали. (Классика)
🔵Используемые инструменты для моделирования. (Классика)
🔵Используемые техники сбора требований. (Классика)
🔵Какие артефакты передаете разработчикам. (Классика)
🔵Как сокращаете риски, если заказчик не подтверждает документы или не принимает решения. (Первый раз)
🔵Способы взаимодействия с проблемными заказчиками. (Очень редко)

👣 Секция «Интеграции»:

🔵Какие способы интеграции приходилось реализовывать на практике: REST/SOAP/Брокеры или иные. (Часто)
🔵Способы документирования интеграций. (Часто)
🔵Опыт работы с Kafka и кейсы применения. (Часто)
🔵Синхронное vs асинхронное взаимодействие. (Часто)

🖥 Секция «Базы данных»:

🔵Какие СУБД использовали в работе. (Классика)
🔵С какими SQL операторами/функциями доводилось работать. (Часто)
🔵LEFT vs RIGHT JOIN. (Классика)
🔵ACID: что произойдёт при откате после частичного выполнения. (Бывает)
🔵Нормализация БД. Для чего нужна. (Классика)
🔵Денормализация БД. Для чего нужна. (Редко)

🔨 Итог: Радует открытость интервьюера. Сразу задает правильные вопросы и дает понять, что проект проблемный в части взаимодействия с заказчиками и специфичный в части написания документации. Были уточнения, что придется работать с нормоконтролерами, а это не самая тривиальная задача для тех, кто не работал ранее с ГОСТами, скажу я вам.

💩 Читатели, ваш вердикт:

👍 — Ровный собес.

🤔— Не хочется возиться с ГОСТами. Тот еще головняк.

😭 — Я депрессую, завтра опять на завод.

Подписывайтесь на:
❤@sa_sobes

Всем доброе утро ☀️

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

[#РазборПолётов@sa_sobes] - Ровный собес.

Вакансия: Системный аналитик
Жалование: 380 000 (На руки)
Уровень: Senior
Мысли редакции: Ровно и ненапряжно. Разделяем мнение соискателя.
Мнение соискателя:

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

📝 Секция «Общие вопросы»:

🔵Почему ищешь новое место работы.
🔵Видишь ли свое развитие как лида СА.
🔵Критерий выбора новой команды.
🔵Что является для тебя красными флагами при выборе команды.
🔵Были ли ситуации, когда ты предлагала улучшить текущие процессы в команде, что это были за процессы и улучшения.

📝Секция «Нотации и моделирование»:

🔵Опыт работы с PlantUml.
🔵Опыт работы с Camunda.
🔵Насколько сложные BPMN схемы доводилось рисовать. Какие типы шлюзов там использовались.
🔵Уровень владения OpenAPI.

🖥 Секция «Базы данных»:

🔵Отличие реляционной БД от нереляционной.
🔵Что такое нормализация данных и зачем она нужна. Какие НФ ты знаешь.
🔵Уровень владения SQL.
🔵Приходилось ли работать с миграциями и хранимыми процедурами.
🔵Почему нельзя хранить массивы в БД.

👩‍💻 Секция «Архитектура и интеграции»:

🔵Микросервисная vs Монолитная архитектура.
🔵Как работает контейнерезация. Как поднимаются кластеры K8S, из чего они состоят.
🔵Насколько хорошо знаком с архитектурными паттернами и какие доводилось применять на практике.
🔵SSE vs WebSocket.
🔵Что такое GRPc и для чего он нужен.
🔵По каким критериям ты поймешь какой тип интеграции реализовать - асинхронный или синхронный.

⚙️ Секция «Проектирование»:

🔴Задача: Есть информационная система библиотеки. Учет книг уже автоматизирован.
Пришла задача: Реализовать возможность бронирования книг. Что нам нужно будет доработать чтобы реализовать эту фичу. На текущий момент сайт библиотеки представляет из себя сайт визитку.

Ответ:

Кандидат (Далее К): Есть ли сейчас взаимодействие между сайтом библиотеки и информационной системой библиотеки?
Интервьюер (Далее И): Нет.

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

К: Как аналитик, я бы изучила сайты конкурентов, чтобы изучить, как у них реализована фича бронирования книг. Также лендингу необходимо получать список книг. Для этого необходимо реализовать GET метод с фильтрами для удобства работы с поиском. Рядом с каждой позицией в каталоге расположим кнопку "Забронировать книгу". Как бизнес видит функционал бронирования? Необходимо ли предусмотреть оплату.
И: Не предусматриваем.

⚠️ Продолжение в комментариях, слишком много текста.

🔨 Итог: Практико- ориентированный собес, достойное жалованье. По теории видно, что местами требуется аналитик, который глубоко погружен в технологии (для аналитика) + на собеседовании был уточняющий вопрос на эту тему.

💩 Читатели, ваш вердикт:

👍 — Ровный собес.

💰 — Наконец-то настоящий баблоидский собес. Прошлая неделя нищих обзоров едва ли не загнала меня в депрессию.

😭 — Верни каноничный формат с указанием частотности вопросов.

Подписывайтесь на:
❤@sa_sobes

Всем доброе утро ☀️

📢 И снова нищий обзор на собес ниже рынка.

[#РазборПолётов@sa_sobes] - Кандидата дурят.

Вакансия: Системный аналитик
Жалование: 170 000 (На руки)
Уровень: Middle
Мысли редакции: Много практики, что не может не радовать. Ровный и приятный интервьюер.
Мнение соискателя: Мне понравилось, чилловый собес, достаточно простое задание.

📝 Секция «Общие вопросы»:

🔵Расскажи про свой опыт. (Классика)

📝 Секция «Требования и Техничка»:

🔴Задача: Есть ЛК пользователя банка. Бизнес хочет новую фичу "История транзакций пользователя". Нужно описать UseCase и API. Можно задавать вопросы интервьюеру для выявления требований.

Кандидат (Далее К): Функционал реализуем на отдельной вкладке ?
Интервьюер (Далее И): Да

К: Каким образом пользователь должен мочь фильтровать, сортировать перечень транзакций ?
И: По времени (Последний день, месяц, год или за указанный период), по типу транзакций (пополнения, переводы и.т.д), по сумме. Сортировка только по дате и времени.

К: Необходимо предусмотреть пагинацию. Сколько записей будем отображать на 1 странице.
И: 10 записей при переходе на вкладку. Стратегия пагинации "Infinite scroll".

К: По умолчанию отображаем самые свежие транзакции ?
И: Да

К: Какие данные отображать по каждой транзакции в списке.
И: Дата, сумма, тип транзакции, данные по кешбеку, категория. При переводе можно отобразить кому перевели.

К: За какой период будем хранить транзакции.
И: За все время.

К: Откуда берем транзакции. Сторонняя система или наша БД.
И: Есть мастер-система, которая по запросу с нашего Backend'a будет отдавать перечень транзакций согласно указанным фильтрам. У себя локально данные не прихраниваем.

UseCase: Картинку приложил к посту.

🖥 Описание метода API для получения списка транзакций:

🔴Запрос:

Метод: GET
Path параметр: userId | Идентификатор пользователя | string (uuid)
Query параметры:

🔵dateFrom | Дата от которой запрашивать транзакции | string (date-time)
🔵dateTo | Дата до которой запрашивать транзакции | string (date-time)
🔵transactionType | Тип транзакции | (ENUM: WITHDRAWAL, DEPOSIT, TRANSFER)
🔵amountFrom | Сумма операции От | string
🔵amountTo | Сумма операции До | string
🔵limit | Количество загружаемых транзакций | Int
🔵offset | Сдвиг | Int

🔴Успешный ответ на примере одной транзакции:

🔵transactionId | Идентификатор транзакции | string (uuid)
🔵amount | Сумма операции | string
🔵transactionType | Тип транзакции | (ENUM: WITHDRAWAL, DEPOSIT, TRANSFER)
🔵transactionDateTime | Дата и время транзакции | string (date-time)

Доп вопросы:

🔵Что делать если пользователь выбрал слишком большой период, например, 2 года и у него 5000 транзакций за этот период.
🔵А если у пользователя за последний месяц 5000 транзакций.
🔵Какой SQL запрос будет вызываться при вызове описанного выше метода API.
🔵Какую СУБД ты будешь использовать для хранения транзакций.
🔵Пользователи начали жаловаться, что долго грузится раздел с историей транзакций. Как можно было бы решить эту проблему.

🔨 Итог: Кандидат с отличием прошел собес и получил положительную обратную связь сразу на интервью. Собес классный так как в нем вообще не было теории и с кандидат на протяжении собеса в режиме диалога решал +- реальную задачу.
Но ... по итогам собеседования кандидату пришел оффер ниже озвученной суммы перед собеседованием суммы.

💩 Читатели, ваш вердикт:

🤡 — Захотелось порвать всех причастных за несправедливую просадку по зп.

👍 — Ровный собес.

😭 — Почему так сложно.

Подписывайтесь на:
❤@sa_sobes

Всем доброе утро ☀️

📢 И снова собеседование. Наконец-то +- народное на позицию Middle.

[#РазборПолётов@sa_sobes] - Слегка претенциозный интервьюер.

Вакансия: Системный аналитик
Жалование: 220 000 (На руки)
Уровень: Middle
Мысли редакции: Пойдет
Мнение соискателя: Сам собес довольно интересный
а интервьюер чсв конечно.

📝 Секция «Общие вопросы»:

🔵Было ли у вас совмещение ролей. (Бывает)

👩‍💻 Секция «Архитектура»:

🔵Микросервисы VS монолит. (Классика)

👣 Секция «Интеграции»:

🔵Что такое REST и какие у него особенности. (Классика)
🔵Принципы Restfull. (Бывает)
🔵HTTP методы и их отличие/назначение/примеры использования. (Классика)
🔵Какие типы данных есть в JSON. (Редко, вопрос с приколом кстати)
🔵Что такое SOAP и зачем он нужен. (Классика)
🔵Что такое Kafka и зачем она нужна. (Часто)
🔵Гарантии доставки в Kafka. (Бывает)
🔵Что такое RabbitMQ и зачем он нужен. (Бывает, чаще про Kafka все таки спрашивают)

📝 Секция «Документация»:

🔵Предположим вы проектируете сервис, далее передаете сервис в сопровождение со всей необходимой документацией. Что было бы полезно команде сопровождения в этой документации. (Редко, хороший вопрос)
🔵Какие артефакты вы генерировали как системный аналитик. (Классика)
🔵Зачем нужен BPMN. Из каких элементов состоит. (Часто, но про элементы реже спрашивают)
🔵Зачем нужен UML. Из каких элементов состоит. (Часто, но про элементы реже спрашивают)
🔵Зачем нужна ERD. Из каких элементов состоит. (Часто, но про элементы реже спрашивают)

🖥 Секция «Базы данных»:

🔵По каким критериям можно определить, что БД реляционная. (Хороший вопрос, редко)
🔵Что такое нормализация БД и расскажите про первые 3 НФ. (Классика)
🔵Что делает оператор DROP. (Бывает)
🔵Что делает INNER JOIN. (Бывает)
🔵Как работает LEFT JOIN. (Часто)
🔵Что делает UNION. (Редко)
🔵Как создать таблицу. (Редко)
🔵Что такое агрегатная функция. (Часто)

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

Ответ кандидата: Сделать SELECT DISTINCT по полю, где хранится хобби пользователя.

🔴Задача: Есть БД страховой компании. В компании страхуются разные клиенты (корп, физ). При регистрации пользователи обязательно указывают почту. Возникла задача сделать рассылку с акционным предложением именно сотрудникам. Как можно выудить из БД сотрудников.

Ответ кандидата: Сделать Select указав в условии like и искать по почтовому домену компании:

SELECT email
FROM users
WHERE email LIKE '%@companyexample.com';

🔴Задача: Для неких целей было создано 2 таблицы. 1 таблица - длина моркови, 2 таблица - виды пуговиц. Связи между таблицами нет и не предвидится. Можно ли в данном случае считать что БД реляционная.

Мнение редактора: Мне крайне интересно, как бы вы ответили на этот вопрос, так что пишите ваши ответа в комментариях.

🔨 Итог: Вот тут есть один важный нюанс. Кандидат слишком умный, поэтому на большинство вопросов отвечал фактически предугадывая следующие. В частности это касается секции про Интеграции и Брокеры. Там кандидат блеснул ультимативными знаниями в области понимания принципов работы HTTP и архитектуры Kafka.

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

💩 Читатели, ваш вердикт:

👍 — Ровный собес.

😭 — Жалованье зажмотили. Вопросы сложные. Интервьюера забанить.

Подписывайтесь на:
❤@sa_sobes

Всем доброе утро ☀️

📢 Продолжаем рубрику разборов собеседований. Сегодня на обзоре самый простой собес с жалованьем больше 300к, который я видел за последнее время.

[#РазборПолётов@sa_sobes] - Проще некуда.

Вакансия: Системный аналитик
Жалование: 330 000 (на руки)
Уровень: Senior
Мысли редакции: Слишком просто
Мнение соискателя:
Прикольные ребята, легкость в общении, знают и понимаю что хотят. Возможно, интервьюер недостаточно глубоко копает и мало требует от аналитика.

📝 Секция «Общие вопросы»:

🔵Зачем пошел в аналитику. (Бывает)
🔵Зона ответственности на текущем проекте. (Классика)
🔵Предпочтения к будущей команде/проекту. (Классика)
🔵С кем из команды ты взаимодействуешь по мере написания документации. (Бывает)

📝 Секция «Документация»:

🔵Из каких разделов состоит Use Case. (Бывает)
🔵Как ты описываешь требования к API. (Классика)
🔵Как ты описываешь требования к моделям данных. (Классика)

🔴Задача: Необходимо реализовать сервис по управлению услугами каршеринга B2B. Сервис будет доступен менеджерам. Менеджер от лица своей компании может подключать/отключать услуги и настраивать лимиты для каждого конкретного сотрудника своей организации. Сервис должен быть автономен (хранить все необходимые данные для успешного функционирования)

Вопрос: Как ты будешь выполнять эту задачу? Какие артефакты нужны для успешной разработки.

Ответ кандидата:
- Декомпозируем эту задачу на более мелкие подзадачи.
- Сбор требований с автора задачи.
- Выявить реального стейкхолдера/заинтересованный лиц.
- US, UC, Описание API, ER-диаграмма, прототипы/макеты.

👣 Секция «HTTP/REST»:

🔵HTTP коды ответов. (Классика)
🔵HTTP методы и кейсы использования. (Классика)

🖥 Секция «Базы данных»:

🔴Задача: Есть сущность products c атрибутами: 'id','sku','prod_name','prod_price'. Необходимо получить название и артикул всех товаров, где цена = 3.

Ответ кандидата:

SELECT sku, prod_name
FROM products
WHERE prod_price = 3;


🔨 Итог: Периодически натыкаюсь на сообщения в тематических СА чатах и получаю инфу от своих менти, что рынок уже не тот и говорят, что работу намного тяжелее найти нежели 1-2 года назад. Как раз в то время я активно ходил на собесы и я не помню на своей практике столь простое собеседование за столь приятное жалованье (250к на руки в то время). А что думаете вы и насколько вам тяжело/легко сейчас искать работу? Поделитесь вашими историями/мнением в комментариях.

💩 Читатели, ваш вердикт:

👍 — Найс жалованье за такие простые вопросы.

🤔 — Рынок уже не тот, собесы все сложнее и сложнее.

Подписывайтесь на:
❤@sa_sobes

Всем доброе утро ☀️

📢 Продолжаем рубрику разборов собеседований. Сегодня на обзоре простой собес и одаренный кандидат.

[#РазборПолётов@sa_sobes] - Умный кандидат и простые вопросы.

Вакансия: Системный аналитик
Жалование: 400 000 (на руки)
Уровень: Senior
Мысли редакции: Стандартный +- собес за исключением пары, с отличным окладом.
Мнение соискателя:
ощущения комфортные, вопросы стандартные, была задача интересная из опыта интервьера, быстро получилось решить
📝 Секция «Общие вопросы»:

🔵Расскажите о вашем опыте в роли системного аналитика (классика)
🔵Какие роли в твоей текущей команде представлены. С кем приходилось взаимодействовать и как. (Классика)
🔵Флоу выполнения задачи. (Классика)
🔵Часто ли приходилось взаимодействовать с стейкхолдерами. (Классика)
🔵Какие методы сбора требований вы знаете. (Часто)
🔵Какие методы использовали метод для сбора требований кроме интервью. (Бывает)
🔵Какие артефакты являются/являлись результатом твоей работы. (Классика)
🔵Пример нефункциональных требований. (Часто)

📝Секция «Нотации и моделирование»:

🔵Основные элементы в BPMN нотации. (Для СА редко)
🔵Виды шлюзов в BPMN. (Для СА редко)

👣 Секция «Интеграции»:

🔵Виды интеграций. (Классика)
🔵Что такое REST. Принципы REST. (Бывает)
🔵Методы HTTP. Что такое идемпотентность. Коды ответов. (Классика)
🔵Как сделать метод POST идемпотентным. (Редко)
🔵REST vs GRPC. (Бывает)
🔵GraphQL vs REST. (Редко)
🔵SSE vs WebSocket. (Первый раз)

🖥 Секция «Брокеры»:

🔵Kafka vs RabbitMQ. (Часто)
🔵Флоу отправки и чтения сообщения конечным consumer в случае нескольких партиций в одном топике. (Первый раз)

🖥 Секция «Базы данных»:

🔵Виды и типы БД. (Классика)
🔵Что такое реляционная БД. (Классика)
🔵Для чего нужна нормализация БД. (Классика)
🔵Суть первых 3-х нормальных форм. (Бывает)
🔵Опыт написания SQL запросов. Какими JOIN и SQL операторами пользовались. (Часто)
🔵RIGHT JOIN vs LEFT JOIN. (Раньше было часто, навеяло ностальгией)
🔵Для чего нужен HAVING. (Бывает)

❤️‍🔥 Секция «Задачи»:

🔴Задача #1: Есть банковское приложение. Пользователь после успешной авторизации попадает на стартовую страницу, где отображается информация по счетам/предложениям и прочему. Для отображения этой информации BE нашего МП должен получить информацию по идентификатору пользователя у смежных систем. Необходимо: Интегрироваться с системой отдела безопасности. От них мы должны получать факт наличие у пользователя доступа к приложению или его блокировки.

Ответ кандидата:
Необходимо хранить информацию на стороне нашего BE так как наше приложение высоконагруженное и в случае недоступности систем отдела ИБ необходимо иметь актуальные данные на нашей стороне, чтобы не блокировать процесс авторизации пользователя в нашем МП. Информация от отдела ИБ будет поступать через Kafka. У нас будет 2 топика: Snapshot топик использовался бы для получения всего пула исторических данных по пользователям, данные по которым мы можем сразу записать в БД. Incremental топик для получения обновлений. Таким образом в нашей БД были бы представлены данные по всем пользователям и они были бы всегда актуальны.

🔴Задача #2: Описать какие могут быть поля в сущности users для для хранения данных о пользователе. Желательно использовать как можно больше разных типов данных и описать как будет выглядеть JSON с такими данными.

Ответ кандидата по описанию сущности:
- id | uuid | PK | Идентификатор пользователя
- name | varchar | Имя
- email | varchar | E-mail
- birth_date | date | Дата рождения
- is_blocked | boolean | Является ли пользователь заблокированным
- registered_at | timestamp | Дата и время регистрации пользователя

Ответ кандидата по описанию JSON:

"id": "e559975f-ddc9-4501-b21e-5b7a96039800",
"name": "Ivan",
"email": "ivan@mail.ru",
"birthDate": "2000-01-01"
"isBlocked": false,
"registeredAt": "2017-01-01"


💩 Читатели, ваш вердикт:

👍 — Найс жалованье за такие простые вопросы.

🤔 — Чувствуется подвох, как будто бы проект проблемный.

Подписывайтесь на:
❤@sa_sobes