👨‍💻 Вопрос, который мучает меня всю карьеру Системного Аналитика

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

При этом знаю других СА, особенно из области DWH, для которых SQL-запросы стали вторым языком после русского.
У меня это происходит так: практикуюсь с SQL либо перед собеседованием, либо для себя раз в полгода-год. Однако это как езда на велосипеде – если не практиковаться, то быстро забываешь

Но недавно нашел еще один способ поддержания этого навыка – читаю посты Дмитрия с канала Дима SQL-ит (Аналитика данных)

Дима — работает аналитиком данных в Wildberries 🛒

Пишет интересные посты про SQL с примерами таблиц и запросов:

🤍 SQL Ловушка: почему оператор NOT IN ломается, а EXISTS работает
🤍 Казалось бы, агрегатные функции в SQL (SUM, AVG, COUNT) просто считают значения — что тут сложного? Но есть скрытая ловушка: как они ведут себя с NULL?
🤍 Как работают конструкции ANY и ALL в SQL — объяснение на простых примерах

Также Дима не обходит стороной ИИ и их использование в работе и жизни — нашел для себя интересные варианты использования:

🤍Как за 400 рублей в год получить доступ к Claude, ChatGPT, Gemini и Grok через Perplexity и без использования VPN
🤍 Вайбкодинг — бесплатный аналог Cursor AI от Alibaba (Qoder)
🤍 Бесплатные нейросети для аналитики и кода
🤍 Бесплатная нейросеть от Google для работы с любыми материалами — NotebookLM

Но помимо этого Дима пишет не менее интересные посты про личную эффективность, выдержки из книг и просто личные мысли:

🤍Как за год стать в 37 раз лучше: конспект «Атомных привычек» - Джеймса Клира. Часть 1 и Часть 2
🤍10 идей для повышения эффективности, которые я усвоил из книги Максима Дорофеева (Джедайские Техники)
🤍Здоровье в IT: как я борюсь с сидячим образом жизни. Часть 1
🤍Мое понимание мира - прими неопределённость или почему истины нет, а есть только вероятность

Рекомендую подписаться: тут есть, о чем почитать

⬇️ А вы используете на работе SQL? Или эта тема вас также обходит стороной, как и меня? Пишите в комментариях

Обзор малоизвестного инструмента Structurizr + промт для ИИ 🛠

У кого ни спрошу, никто не знает про инструмент Structurizr. Пора это исправить

🤍Принцип работы

Structurizr – бесплатный инструмент для визуалиазации и документирования архитектуры в нотации C4. Используется код для отрисовки документации, как в PlantUML

Пример работы на картинке

🤍Как в нем работать

Сложность инструмента – в синтаксисе кода, который менее интуитивный, чем в PlantUML. Можете изучить его, или поступить проще и попросить ИИ сгенерировать код на промта (см. в комментах)

🤍 Переходим на сайт https://structurizr.com
🤍 Нажимаем на вкладку "Demo"
🤍 Генерируем код на основе промта в какой-нибудь ИИ
🤍 Вставляем код
🤍 Нажимаем кнопку "Render"
🤍 Вы великолепны!

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

🤍Особенности инструмента

🤍 Моделирование в нотации C4 – один из стандартов для архитектуры
🤍 Текстовая нотация – можно версионировать, легко менять, автоматизировать, поддерживать актуальность
🤍 Разные форматы экспорта – в PDF, PlantUML, Mermaid
🤍 Возможность совместной работы

⚠ Недостатки:
🤍 Сложный синтаксис
🤍 Зависимость от кода, что может отпугнуть
🤍 Ограниченная визуализация – нельзя править стрелки и прочие элементы
🤍 Некоторые функции (например, совместная работа) платные

🤍Когда и кому пригодится?

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

В своей работе использовал один раз на коммерческом проекте и один раз на обучении – однако благодаря инструменту это заняло меньше часа. Вручную C4, при этом, несложно рисовать, но если можно автоматизировать – почему нет?

————

➡ Если вы работает с архитектурой, или у вас задача отрисовать C4 – попробуйте Structurizr. Если не пригодится в работе – можно блеснуть знаниями на собеседовании. Уверен, оценят

Ставь 🔥, если было полезно и хочешь видеть обзоры других инструментов

#инструменты_системный_анализ
#промты_ИИ_системный_анализ

Версии HTTP – простой вопрос с собеседований 💡

Вопрос звучал так:

Какие есть версии HTTP и в чем их отличия?

Как СА я постоянно описываю интеграции, и не знал, что в первой версии HTTP был только метод GET, HTTP 1.1 используется более 15 лет, а HTTP 3 вышел недавно и активно внедряется 😱

Разберем версии HTTP на примере курьера

🤍 HTTP/0.9 (1991 г.)

Такого курьера вы бы не вызвали – он может привозить только одну вещь, и то без упаковки. После доставки сразу исчезает – и даже не предъявишь, если что-то пошло не так 😡

В базовой HTTP/0.9:
🤍Только метод GET
🤍Никаких заголовков, метаданных, кодов состояний
🤍По запросу приходил голый текст HTML
🤍Соединение сразу разрывалось

🤍 HTTP/1.0 (1996 г)

Этот курьер уже может передавать что-то другим лицам, а на посылках написано, от кого, кому, что внутри. Отправитель получит ответ, все ли ок, или что-то пошло не по плану

В HTTP/1.0:
🤍Появилась структура запросов и ответов
🤍Одиночество GET разбавили POST и HEAD
🤍Проблема – на один запрос одно соединение с клиентом, из-за чего сложные страницы грузятся долго

🤍 HTTP/1.1 (1997 г)

Уже через год наш курьер сильно подкачался 💪 – освоил новые методы работы, и не теряется после доставки товара, а остается на связи и может принести что-нибудь еще

В HTTP/1.1:
🤍Появились все известные нам методы (PUT, PATCH (2010), DELETE, OPTIONS, TRACE)
🤍Поддержка постоянного соединения

Эта основа веба используется по сей день

🤍 HTTP/2 (2015)

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

В HTTP/2:
🤍Синтаксис не изменился
🤍Появилось мультиплексирование – передача нескольких запросов и ответов в одном соединении TCP.

🤍HTTP/3 (2022)

Сын Яндекс.Доставки, курьер-супергерой, Сэм Бриджес. Вместо грузовой машины из прошлой версии этот гений использует мопеды, поэтому аварии ему не страшны 😼

В HTTP/3:
🤍Синтаксис не изменился
🤍Изменился транспорт: вместо традиционного TCP используется транспортный протокол QUIC поверх UDP, что улучшает производительность, делает потоки независимыми и ускоряет установку соединения

—————

Эта инфа поможет глубже понять REST, дать определение gRPC (который основан на HTTP 2), поразить собеседующего своими знаниями или просто станет интересным фактом

Забирай себе и ставь 🔥 , если узнал что-то новое

#полезное_системный_анализ
#собеседования_системный_анализ

Собесы раньше vs Собесы теперь 🙈

Вопросы на собесе раньше:
1. Как вас зовут?
2. Сколько вам лет?
3. Из какого вы города?
4. Что такое ФТ и НФТ?
5. Что такое REST API?
6. Что такое брокер сообщений?

Результат: поздравляем, вы приняты

Вопросы на собесе теперь:
1. Что такое Cherry Pick в GIT?
2. Делали ли rebase в GIT?
3. Проводили ли вы ревью кода?
4. Разворачивали ли микросервисы самостоятельно?
5. Реализовали ли API запросы в коде?
6. Был ли опыт с WebView, какие параметры передавали?
7. Какие знаешь алгоритмы работы с данными?
8. Что такое Сircuit Breaker и для чего используется в системе?
9. Какие сериалы посоветуете посмотреть?
10. Что такое CQRS?

Результат (даже если на все ответил): извините, нам нужен кандидат посильнее

—————

Утрировано, но по ощущениям сейчас именно так. Вторая часть – реальные вопросы с недавних собесов

При этом на часть сложных вопросов реально ответить (Webview, Circuit Breaker, CQRS, сериалы), другие же вызвали у меня ступор, но не по причине незнания – реально ли у них СА всем этим занимается?

⬇ Если вы как СА черепикаете 5 раз в неделю, разворачиваете микросервисы и сами пишете АПИшку (а разрабы смотрят в сторонке) – отмечайтесь в комментах. А также пишите о своих вопросах, которые вызвали ахуй застали вас врасплох

#собеседования_системный_анализ

Ныряем с аквалангом: как быстро заонбордиться на проект 📌

Процесс онбординга может затянуться на долгие недели, если не знать, как к нему подступиться. Держите пару советов, как его ускорить💡

🤍Список вопросов, которые я задаю

🤍 Есть ли документация и где ведется?
🤍 Есть ли работающая версия продукта и где ее можно посмотреть?
🤍 Как можно получить доступ к тестовой среде? (в целом спросите про доступы, какие есть и куда нужны)
🤍 Кто есть в команде, к кому можно обратиться по фронту/бэку/дизайну?
🤍 Как ведется коммуникация с заказчиком, нужно ли принимать нам участие в ней?
🤍 Есть ли демо на проекте, как проводятся?
🤍 Что ожидаете от системного аналитика на проекте?
🤍 Какой флоу работы?
🤍 Какие командные активности предусмотрены (дейли, ретро…)?
🤍🤍 Есть ли доска задач и как она ведется, кто ставит задачи?

🤍 Как я онбордюсь

Если документации нет – то процесс в любом случае затянется, так как придется:

🤍 Вдумчиво тыкать тестовую версию
🤍 Донимать вопросами коллег
🤍 Если вы аналитик, соответствующий требованиям 2025, изучать кодовую базу

Если документация есть, то тут попроще:

🤍 Я начинаю с архитектуры – какие есть компоненты системы и как взаимодействуют
🤍 Затем иду в БД – смотрю на сущности и реальные данные
🤍 После изучаю API-документацию (Swagger, Postman) – углубляется понимание системы
🤍 Потом все остальное (сценарии, ограничения, дизайн)

И параллельно изучаю тестовую версию (если мобилка – с Charles, если веб – с вебтулзами)

ОДНАКО! ⚠

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

В итоге я так и не понял полностью систему, особенно бэк часть – работала и ладно, я все равно фронтом занимался

————————

⬇ А как вы онбордитесь на проекты? Какие вопросы задаете?

#полезное_системный_анализ
#чек_лист_системный_анализ

Решаем рабочую задачу: Управление пуш-уведомлениями в мобильном приложении

Пробую новую рубрику – разбор реальных рабочих задач. Если интересно и хотите видеть другие задачи, поддержите и поставьте 🔥

Разбираем задачу, которая часто встречается в мобильных приложениях (и я тоже ее делал)

Постановка задачи 💡

Как пользователь, я хочу управлять настройками пуш-уведомлений, чтобы отключить/включить определенные уведомления

С чего начать? 💬

С чего начинается танец СА? Правильно – с вопросов:

🤍 Какие группы уведомлений будут? (новости, акции)
🤍 Какие уведомления входят в каждую группу?
🤍 Планируются ли добавлять новые группы и уведомления в будущем?
🤍 Как настройки заданы по умолчанию?
🤍 Синхронизировать настройки между устройствами?
🤍 Нужна ли кнопка «Включить/выключить ВСЕ»?
🤍 Где в приложении размещаем экран настроек?

В итоге получаем инфу для БД, API и дизайна

Прописываем сценарии ✍️

Дальше подумаем над возможными сценариями:

🤍 Система задает дефолтные настройки для нового пользователя
🤍 Пользователь получает свои настройки
🤍 Пользователь меняет одну настройку
🤍 Пользователь меняет все настройки разом

Получилось не так уж и много

Проектируем БД ✍️

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

🤍 notification_settings – основная таблица (user_id, notification_id, is_enabled)
🤍 notification_groups – справочник групп
🤍 notification_types – типы уведомлений и их привязка к группам

Так мы сможем легко добавлять новые уведомления и группы

Проектируем API-запросы ✍️

Прикинем, какие API-запросы между фронтом и бэком понадобятся

🤍 GET /setting/notifications – получить настройки
🤍 POST /setting/notification или PUT /setting/notification/{id} – изменить настройку
🤍 POST /setting/notification/all – включение/выключение всех настроек
🤍 POST /setting/notification/default – внутренний метод для установки настроек по умолчанию

А теперь – неочевидные моменты ⚠

🤍 Дефолтные настройки. Вместо синхронного API-запроса лучше использовать асинхронное сообщение в брокер (например, Kafka). Потому что API-запрос может не отработать, и нужно думать, что с этим делать – ибо пользователь словит ошибку из-за отсутствия данных

🤍 Реакция UI. Запрос может отрабатывать долго и не отработать в итоге, и что в это время происходит на экране? Пользователь блокируется лоадером? Это кажется избыточным для такого простого действия

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

—————

⬇ Сталкивались с такой задачей? Пишите в комментах, как решали 

#разбор_задач_системный_анализ

5 признаков, что компания – скам и вам пора бежать 🗑

Рассказываю реальную историю об одной из своих работ – какие тревожные звоночки были, и какие выводы из этого сделал

🤍 Локация – не гарантия

Та работа была в шикарном офисе в престижном бизнес-центре Москвы. Поначалу я был в восторге и офигевал от своей крутости

Но все это оказалось фальшивкой – по-моему мошенников и однодневок там столько же, сколько и везде. Просто у них больше денег на аренду 😁

Вывод: не верьте в красивую обертку – кинуть могут везде

🤍 Сомнительный проект

Бывало ли, что вы работаете над проектом, но не понимаете, откуда деньги и в чем прикол? Чувство, что продукт не решает реальные проблемы пользователей ❓

У нас было чувство, что команда не знает, для кого и зачем это делает. Хотя сам продукт был довольно прозрачным

Вывод:

работая над сомнительным продуктом, осознавайте риски и слушайте совесть

🤍 Миловидно-токсичное отношение

Руководство на публике – пушистые зайки, а при личной беседе – тираны и абьюзеры? Давление, манипуляции, навязывание своего мнения по личным вопросам – было немало неприятных историй. И часто они становились поводом для увольнений 🤬

Вывод:

если замечаете такое в коллективе – не думайте, что это вас не коснется

🤍 Внезапная текучка

За несколько месяцев до события Х мы заметили странное – коллеги из смежных отделов начали массово покидать компанию без видимых причин. Люди буквально испарялись 🤡

Вывод:

если замечаете резкие сокращения, будьте наготове и расчехляйте резюме

🤍 Задержки ЗП

Ну и вишенка на торте. Если это случается – сразу бегите. Теперь я не прощу задержки ЗП даже на один день

Было так – в день ЗП самой ЗП не произошло, потом каждодневные обещания выплаты. Задержки приобрели системный характер: обещания, частичные выплаты и снова задержки 😱

В таком режиме я продержался полтора месяца, и в итоге уволился. Кстати, деньги так и не выплатили

Вывод:

задержка ЗП – краснейший редфлаг

🚩

—————

Как-то смотрел с женой сериал "Разделение" – и был удивлен, насколько точно и правдоподобно авторы показали токсичную работу офиса, которая была точь в точь как у меня. У нас даже был свой Мистер Милчек 😅

⬇ А у вас были подобные истории? Делитесь в комментах

#истории_системный_анализ

Просто о Circuit Breaker 📌

Есть ли у вас друг, который вечно занят и редко соглашается на встречу? Сначала вы активно зовете его на кружку пива, а после нескольких неудачных попыток бросаете это гиблое дело 👀

Но спустя месяц кидаете мем в TG, слово за слово - и вот вы уже сидите в кафе и обмениваетесь новостями 🌾

На примере этой жизненной ситуации можно объяснить Circuit Breaker - паттерн МСА, который частенько стали спрашивать на собесе

🤍 Что такое Circuit Breaker
Circuit Breaker - это предохранитель, который реализуется на клиентской (вызывающей) стороне (на микросервисе или API Gateway)

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

Circuit Breaker понимает, что вызываемый сервис лежит, и прерывает последующие запросы, давая возможность восстановиться после нокаута 🤡. Через время делает тестовый вызов - если сервис поднялся, то общение возобновляется

🤍 Принцип работы
🤍Если все в порядке и вызываемый сервис отвечает, то Circuit Breaker находится в состоянии Closed и спокойно пропускает запросы
🤍Если сбои участились, Circuit Breaker переходит в состояние Open и блокирует вызовы
🤍Через время Circuit Breaker переключается на состояние Half Open и делает тестовые запросы, чтобы проверить, исправлен ли сбой

А как Circuit Breaker понимает, что сервис лежит? Все просто - задается некоторый порог сбоев. Если количество неудачных запросов в состоянии Closed превышает порог, на ринг выходит Circuit Breaker. Порог устанавливается в % - например, 50% неудачных запросов из последних 20 запросов

Время ожидания (timeout) в состоянии Open - тоже настраиваемая метрика. Например, 30-60 секунд

—————
В итоге Circuit Breaker - это как предохранитель в электрощитке, временно предотвращающий вызовы к проблемному сервису. Благодаря ему повышается отказоустойчивость, и пользователю не придется ждать 10-20 секунд, чтобы словить ошибку

➡️ Забирайте себе и уверенно отвечайте на собесе

#полезное_системный_анализ

🤍🤍🤍🤍🤍🤍

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

А пока что – небольшие размышления на тему путешествий ✈️

До недавнего времени о них даже не думал – даже когда жил во Владивостоке, не сгонял ни в Китай, ни в Японию, ни в Корею (а тогда билеты в одну сторону стоили 7500 😭, а до Китая доезжают на автобусе)

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

С тех пор выбираемся в другие страны, не так часто, как хотелось бы – были в Армении 🇦🇲, а сейчас решили вспомнить Турцию 🇹🇷. Хотелось бы путешествовать и в другие страны – но, к сожалению, сейчас это менее доступно

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

⬇ А вы путешествуете? Делитесь в комментах

Реально ли найти работу в 2025? Мой опыт

Отовсюду трубят, что рынок сильно изменился и устроиться на работу невозможно. Чтож, это вызов 🫡 - рассказываю, как недавно искал новую работу

Вводные 📌

Итак, обо мне:
🤍Техническая вышка
🤍3.5 лет в СА в аутсорс/аутстафф
🤍Опыт менторства
🤍Различные курсы, книги за плечами
🤍Нет опыта в биг техах/крупных компаниях (за исключением аутстафф)

Резюме разместил на трех площадках:
🤍HH
🤍GetMatch
🤍Habr

Начало поиска 🌚

15 сентября начал поиск, и неделю никто не писал - хотя два года назад, когда открыл едва мидловое резюме, в первую неделю было 5 собесов 🫥

Откликался сам, писал компаниям, знакомым - все безрезультатно. Беспощадные боты на HH отклоняют все отклики, другие игнорят, а другим компаниям, что звали работать, я уже не нужен (привет, Т-Банк)

Со второй недели HR начали писать сами. За все время поиска были следующие предложения:
🤍Аутстафф - 4
🤍Аутсор - 2
🤍Продукт (устройство в штат) - 4

Почти все писали с HH, лишь два рекрутера с Habr и... никто с GetMatch
Большая часть компаний - малоизвестные. Из крупняков только Альфа-Банк, WildBerries, Магнит Tech

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

Собесы 😁

За месяц было всего два технических собеса - не все предложения из вышеупомянутых мне понравились, и не всегда HR возвращались после скрининга

Собесы были... как обычные собесы - чуть повысилась сложность, но в целом ничего фантастичного и нового 🌾

О том, какие были практические задания и как их решал - в следующем посте

Единственное, что заметил - появились вопросы "на волчонка" 😏. Например, если у вас указана какая-то компания, могут спросить, что она делает и где расположена

О волчонках мне есть, что сказать - но эта тема достойна еще одного поста

Итог 😎

В итоге 12 октября получил оффер куда хотел: поиск работы суммарно занял месяц. И вот какие выводы на основе моего опыта:

🤍Работу найти можно, но теперь это занимает больше времени (иногда - значительно)
🤍HH так и остается основной платформой
🤍На одну вакансию - от 200 до 500 (а то и больше) откликов
🤍По ощущениям осенью найм активизировался
🤍Боты на HH и волчата - основные препятствия при поиске, специалисты с ненакрученным опытом теряются на фоне
🤍Бездумно откликаться самостоятельно бессмысленно - лучше писать сопроводительное письмо, или вовсе забить и ждать HR
🤍Собеседования по структуре особо не изменились - правда, некоторые вопросы стали сложнее и глубже

⬇️ А вы искали работу недавно или может быть ищете? С каким трудностями столкнулись? Какие изменения на рынке труда заметили? Делитесь, интересно почитать

Что спрашивают на собесах в 2025? + Практические кейсы 💡

Недавно я искал работу. Один из мифов, который удалось развеять для себя - то, что собесы стали очень сложными. Это не так (по крайней мере для грейда middle-senior)

Рассказываю об особенностях, которые отметил для себя

Теория 😴

В целом теоретические вопросы остались такими же - про требования, про различия БД, про интеграции, архитектуру. Все это вы уже наверняка читали и не раз. Из интересного немного:

🤍На каждом собесе спрашивали про кэширование, но не явно, а на примере кейса "Как оптимизировать/ускорить запрос от фронта к бэку".
🤍Глубже спрашивают про паттерны микросервисной архитектуры: BFF, API GateWay, Circuit Breaker, Saga, паттерны декомпозиции микросервисов. Советую изучить их, там нет ничего сверхъестественного

Практика 🤔

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

🤍Спроектировать REST API для определенного кейса
Классика - система заказов еды, любимая всеми онлайн-библиотека, что-то еще. Требуют спроектировать REST API запросы: метод, endpoint, какие-нибудь особенности (пагинация, фильтрация)

Например: GET /books?author="Достоевский"&page=1&limit=5 - получение книг Достоевского с учетом пагинации

🤍SQL-запросы
Стали чаще спрашивать. Теорию могут спросить на скрининге (в чем отличия WHERE и HAVING?), на собесе почти гарантированно будет задача. Как правило решение будет содержать JOIN: либо INNER JOIN, либо LEFT JOIN, и агрегатные функции. Все мои задачи решались через джоины

Пример задачи: определить, какое количество каждого товара было куплено в 2025 году. Тут понадобится LEFT JOIN, так как некоторые товары могли не купить

Никогда не любил их, но, чтобы преодолеть собес, за неделю вспомнил все на бесплатном курсе на Stepik - рекомендую его

🤍Спроектировать взаимодействие по процессу
А это было что-то новое. Собеседующий а-ля заказчик описывает процесс, а ты должен визуализировать его как угодно и предложить решение. Я выбрал UML Sequence и рисовал через PlantUML. А по другому и не знаю, как

🤍Найти ошибки в REST API
Тоже такой задачи не встречал, но она не стала сюрпризом

Приводят метод, заголовки и JSON с ошибками, надо их найти. Тут достаточно знать базу (отличия методов), основные заголовки (authorization, content-type) и синтаксис JSON

Например, "HEAD order?id=456 - частичное обновление данных"

—————

🚨

Еще несколько задачек в комментах

—————

В общем, собеседования особо не изменились - я ожидал везде гачимучи с System Design 🥵, а в итоге получал обычные собесы, где-то легче, где-то сложнее

⬇️ Пишите о самых запоминающихся практических задачках с собесов - возможно, они кому-то пригодятся при подготовке

А вы любите ужастики? 🎃

Сегодня Хэллоуин - не то чтобы праздник, но повод посмотреть фильмы ужасов и пощекотать себе нервишки 🫣

Давайте отвлечемся от этих айтишных дел и обсудим ужастики. Делюсь своим списком фильмов, которые меня впечатлили:

🤍Кошмар на улице Вязов
🤍Кладбище домашних животных (старенькие)
🤍Ночь живых мертвецов (1990)
🤍Оно (1990)
🤍Ведьма из Блэр: Курсовая с того света (1999)
🤍Спуск (1 часть)
🤍Паранормальное явление (1 часть)
🤍Искатели могил (1 часть)
🤍Зеркала (1 часть)
🤍Синистер (1 часть)
🤍Кровавая жатва
🤍Райское озеро
🤍Фильмы про Чаки
🤍Репортаж (1 часть)
🤍Мгла (2007)

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

—————

⬇️ А вы любите/смотрите ужастики? Какие самые любимые фильмы? Делитесь в комментах

КАСТДЕВ 🚨

Хочу провести каст-дев, для этого мне нужно 3 человека, готовых уделить 20-30 минут на созвон и пообщаться о канале, узнать какие темы и посты вам нравятся, и что нравится во мне как в авторе

Кто хочет - пишите в личку @bening_cloth или в комментарии

P.S не обязательно звонок - можно текстом

UPDATE: люди найдены, спасибо кто откликнулся

Самая лучшая книга из профессиональной литературы 📖

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

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

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

Скинул пару страниц в комментариях - убедитесь сами, насколько просто пишет автор

🤍Как устроена книга

Книга построена как история - начиная со времен, когда были созданы Азбука Морзе и шрифт Брайля, и заканчивая нашими днями. Вот основные посылы:

🤍 Все началось с банальной передачи информации путем… включения (1) и отключения (0) обычной лампочки. Да, люди тупо переключали лампочки на огромных расстояниях
🤍 Благодаря Азбуке Морзе и шрифту Брайля появились комбинации
🤍 Дальше добавили логические операции (И, ИЛИ, НЕ), что позволило создавать более сложные схемы, устройства и в конце концов процессор
🤍 По сути вся работа процессора – постоянные переключения с 0 на 1 и различные логические вычисления. Только это происходит миллионы раз в секунду, а раньше люди переключали лампочки руками (почувствуйте разницу)
🤍 Чем быстрее процессор (выше скорость переключений), тем больше операций он может сделать
🤍 Языки программирования придумали, чтобы мы говорили процессору, что делать

Что понравилось в книге:
➕ Первая половина – как экскурсия в прошлое
➕ Написана неожиданно простым языком, читаешь как худ. литературу
➕ Много картиночек с пояснениями (они еще и цветные!)

Что не понравилось:
⚠️ Вторая половина менее интересная и более тяжелая
⚠️ Много неточностей в русскоязычном переводе

Кому рекомендую почитать? 📌

Книга никак не усилит знания в системном анализе, но позволит понять устройство компьютера и информационных систем на уровне основ, что расширит ваш технический кругозор. Я наконец-то получил ответы на многие технические вопросы, которые остались еще со школы и универа

Поэтому ее я бы порекомендовал:

🤍 Разработчикам и архитекторам
🤍 Людям с технической вышкой, которым на учебе так и не объяснили устройство компьютера (или объяснили слишком сложно)
🤍 Всем любознательным

⬇️Итог

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

Ставь 🔥, если было полезно

#книги_системный_анализ

Что такое System Design интервью и как его пройти 🤔

Иногда на собеседовании СА попадает на System Design интервью - когда кандидат проектирует систему по заданному кейсу весь собес, а собеседующий спрашивает что-то по ходу 😎

Я был на трех таких - в Т-Банк, в Wildberries, третий не помню где. Везде прошел. Вот какие кейсы были:

🤍Агрегатор кинотеатров с возможностью брони и покупки билетов
🤍Система по бронированию и покупке билетов на рейсовые автобусы
🤍Система по доставке товаров

Как пройти такой собес? 📌

Есть хорошая книга на эту тему - System Design Алекса Сюй, о которой уже писал. Там есть общий план и примеры интервью на основе реальных систем (Google Диск, YouTube и так далее) - рекомендую почитать хотя бы пару глав.

План прохождения System Design интервью:

🤍 Сбор требований
Представьте, вам дали кейс из списка выше. Ничего же непонятно ❓ - какие кинотеатры, что должен увидеть пользователь, как осуществляется доставка, что написано в билете на автобус

Поэтому первый этап - классический сбор требований. Собираем функциональные и (ВАЖНО) нефункциональные - все это пригодится. Здесь СА должен чувствовать себя как рыба в воде

🤍 Расчеты
На основе нефункциональных требований можно посчитать нагрузку и трафик, что поможет при проектировании архитектуры:

Нагрузка: (Количество пользователей в день (DAU) * количество операций записи/чтения) / секунды в сутках. Например, 10 000 000 * 15 (количество запросов в сутки) / 86400 сек ~ 1500 запросов в сек (RPS)
Трафик: Нагрузка * количество байт * количество объектов в запись. Например, 1500 RPS * 200 Bytes * 1 = 300 KB/s

Чтобы узнать количество операций записи, спросите, сколько билетов продается в день. Чтобы посчитать передаваемые байты, прикиньте сущность и атрибуты (но почитайте, сколько байт занимают int или string)

🤍 Предварительное проектирование

В вольной нотации или в C4. Открываем редактор (например, Draw.io) и накидываем клиентские приложения, сервисы, шлюзы, внешние интеграции 🥵

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

🤍 Углубленное проектирование

Тут подключается собеседующий и предлагает углубиться в какой-нибудь сервис или часть системы: понять логику работы, нюансы, различные кейсы

Например, рассказать логику работы сервиса бронирований

Cправиться с этой частью поможет технический кругозор: опыт на работе, видео с YouTube, книги, курсы. Важно, чтобы вы не только понимали бизнес-логику, но и могли бы обосновать выбор типа БД или интеграции

🤍 Итог

Чаще всего в конце спрашивают про будущее системы: а что если мы захотим что-то изменить, или количество пользователей вырастет с 10 до 10000 🫥. Какие есть узкие места в системе, что с ними делать

Опять же, возвращаемся к техническому кругозору

—————

ВАЖНО: в таких собесах не нужно проявлять перфекционизм - цифры можно посчитать примерные, да и система не должна быть идеальной. Тут не требуют правильного ответа 🌾

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

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

➡️ Ставьте 🔥 и забирайте себе - пригодится на интервью по System Design

Мифы и правда про IT 😇

Наверняка вы слышали многое про IT - и про работу на пляже, и про 300к в наносек, и еще что-нибудь. Решил развеять/подтвердить некоторые мифы об IT на основе своего опыта

1 - Работа с ноутбуком на пляже

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

Я пробовал так работать - едва ли назовешь это приятным опытом. Куда комфортнее в отеле, а еще лучше дома с оборудованным рабочим местом и дополнительным монитором. Отпуск в отпуске, а работа дома 🌴

2 - В IT большие зарплаты

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

И вот ты вроде получаешь больше, чем если бы работал на заводе, но все равно чувствуешь себя среднячком - потому что уже не смотришь на цены в продуктовом, но и о квартире до сих пор мечтаешь

3 - В IT ты работаешь над чем-то особенным

Миф. В моей практике было куда больше неинтересных проектов чем интересных. Какие-то государственные внутренние решения, которыми пользуются 2,5 человека, неудачные стартапы, застойные сервисы, для которых эпик это сделать квадратную кнопку закругленнной 👾

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

4 - В IT только молодые

Миф. В IT я видел разных людей - и 20-летнего тимлида из древних легенд 🤨, и вполне взрослых людей 30-45 (и это не только разработчики, а люди на разных позициях)

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

5 - Нужна вышка, чтобы стать айтишником

Дискуссионный вопрос 🤔. Как правило она облегчает вход и адаптацию:

🤍Если у тебя профильная вышка по IT - думаю, будет намного легче
🤍Если техническая вышка (а у меня такая) - поможет на старте в некоторых моментах
🤍Если гуманитарная вышка - наверняка какие-то навыки тоже помогут, не лишними будут софты

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

6 - Айтишники всегда перерабатывают и не вылезают из дома

Миф. Я никогда не выходил на работу в субботу по просьбе начальства, крайне редко задерживаюсь после 18. Настроил для себя режим с 9 до 18, и существую в нем уже пару лет. А вне работы - прогулки, спорт, хобби, время с семьей 🌾

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

—————

⬇️ А что вы поняли, работая в IT? Делитесь в комментариях

На что обращают внимание собеседующие 😎

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

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

🤍Мотивация кандидата

Собесили парня - хорошо отвечал на теорию и справился с практикой. Но когда спрашивали его про то, читает ли он статьи, книги, смотрит ли что-нибудь по системному анализу, он отвечал сухо и без энтузиазма "Нет". Я не обратил внимания, но потом руководитель сказала, что не берем по причине низкой заинтересованности 🪲

И действительно: в IT нужно постоянно учиться и узнавать что-то новое, чтобы удержаться на плаву

➡️ Поэтому обязательно расскажите на собесе, что вы недавно узнали новое и интересное по своей профессии, может быть что-то читаете/смотрите. Плюсик в карму обеспечен

🤍 Читерство, ИИ, хитрость

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

Конечно, не все форс-мажоры должны попадать под подозрительное действие. Например, при собеседовании на текущее место у меня реально два раза отключили свет, и я пропадал на пару минут 🫣

➡️ Тут рекомендация: приходите с камерой, попытайтесь не стрессовать, не отвлекаться, отвечайте как есть и не пользуйтесь ИИ параллельно

Я бы лучше разложил листы А4 со шпорами по всему столу - пишу это и чувствую себя старым

🤍 Способность к размышлению, работа с неопределенностью, технический кругозор

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

Не бойтесь размышлять, задавать вопросы (часто слышу "я задам глупый вопрос...", хотя глупых вопросов НЕ БЫВАЕТ) и в целом постоянно говорить. Даже если размышления зашли не в ту степь, это все равно плюс для кандидата

➡️ Чтобы овладеть этим, расширяйте технический кругозор - книги, статьи, видео. Интересуйтесь плюсам и минусами технологий (одно дело знать виды реляционных БД, другое (и более интересное) почитать про их достоинства и недостатки). Смотрите System Design интервью - там как раз про выбор и обоснование решений

—————

⬇️ Если среди нас есть спецы, которым посчастливилось собеседовать внешних кандидатов - пишите в комментах, на что еще вы обращаете внимание. Давайте поможем ребятам, кто ищет работу, увереннее проходить собесы

Год в роли ментора: результаты

Утро пятницы начинается с публикации на Хабр - вышла моя первая статья. Открыто и честно рассказал про менторство, чем занимаюсь последний год 🥵

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

➡️ Читать статью

Буду рад обратной связи и поддержке 🔥

Как я понял, что засиделся на работе 🤔

Недавно я менял работу - осенью перешел в Альфа-Банк, а до этого работал в Umbrella IT аж 2.5 года (что стало рекордом для меня). К прошлому месту отношусь с огромным уважением, но в один момент понял, что засиделся - решил поделиться мыслями, почему все же решил уйти

🤍Аутсорс/аутстафф стал мне некомфортен

Основная причина, которая порождает все последующие

По началу это был драйвер роста: проекты менялись часто, были разные доменные области, разные заказчики. Успел и в гос. сектор заглянуть и написать кипу по ГОСТ-19, и поработать с более интенсивными проектами, и навыки интервью сильно выросли 🤭

Но, после бурного роста, наступило плато. И я уже посмотрел на эту модель с другой стороны:

🤍 После завершения проекта нет возможности развивать его
🤍 Если работаешь по аутстаффу, то у тебя не так много доступов, как у штатника - ко многим технологиям ты не можешь притронуться
🤍 В любой момент с аутстаффником могут попрощаться
🤍 Когда ты на аутстаффе, не получаешь льготы компании (твоя команда получила премию? рад, но не от всего сердца 🤬)
🤍 Непостоянство, сильная зависимость от рынка

Благо, именно на одном из аутстафф проектов я задержался почти на год и поработал в интересном продукте, и понял - это мне куда ближе

🤍Знания копились и пылились

Я люблю учиться - прохожу курсы, читаю книги, статьи. Но одно дело читать, другое - применять на практике. А в аутсорсе/аутстаффе далеко не всегда это получится 🤨

Например, до смены работы я никогда не видел нереляционных БД (Redis не в счет), очень мало работал с GIT и у меня почти не было опыта интеграций с внешними командами (потому что этих команд не было)

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

🤍Желание поработать в крупной компании

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

—————

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

➡️ А какие мысли на работе тяготят вас? Если бы меняли (или если меняли) работу, то почему? Делитесь в комментах

Отношения на работе - норм или стрем? 🥰

А вы видели, как коллеги заводят служебный роман на работе? А я это пережил - и в двух компаниях на это смотрели по разному

🤍Отношения - стрем

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

Но в один прекрасный момент нас вызвал на ковер начальник - и здорово так отчитал. Оказалось, что за руки держаться нельзя, смотреть друг на друга нельзя 🐈‍⬛. Это было ожидаемо: атмосфера на работе итак была токсичная

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

🤍Отношения - норм

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

Однако я увидел совершенно иное отношение к парочкам на работе - там не только некоторые люди находили друг друга, но и даже строили целые семьи 😁, и все к этому абсолютно нормально относились

Корпоративы тоже были семейные, и никто из этих пар даже подумать не мог, что на них кто-то косо посмотрит 🌾
—————
А что вы думаете про отношения на работе?

😇 - Отношусь нормально, главное чтобы не переходили границы
🤬 - Никаких отношений, на работу приходят работать, а не пару искать
💘 - Я сам нашел(-ла) вторую половинку на работе

Привет! Сегодня вышел мой пост на канале коллеги IT | Просто о сложном | Александр Турченко, в котором я рассказал просто о проксировании (прокси). Если задавались вопросом, а что это, самое время его закрыть

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