📖 System Design: как выжить на собеседовании? Обзор книги Алекса Сюя

О чем книга?

Аналитик при подготовке к грейду Senior наверняка столкнется с System Design на собесе. Это стрессовое проектирование какой-либо системы прямо на интервью онлайн без регистрации и смс🔞. Однако задание многое говорит о кандидате, его hard и soft skills, а также умении принимать решения.

Автор разбирает по косточкам Google, YouTube, WhatsApp – и дает пошаговый метод проектирования подобных систем на собесе.

Что понравилось

➕ Просто и коротко. 300 страниц с картинками можно осилить за 2-3 вечера.
➕ Фокус на архитектуру. Учимся думать не только про функции, но и про прозводительность, масштабируемость (что, если пользователей станет 1 млн?)
➕ Проектирование популярных систем. YouTube пока спроектировать не готов, но понимаю, что под капотом

Что не понравилось

⚠ Не все системы удастся понять. Я работал с мессенджерами и системой уведомлений, поэтому книга дополнила мои знания. А вот хранилище типа «ключ-значение» и согласованное хэширование остались темным лесом🤷‍♂️
⚠ Местами не хватает деталей и цифр. Хотелось бы больше конкретики

Кому бы порекомендовал?

Системным аналитикам (да и не только) уровня middle и middle+, у которых за плечами хотя бы несколько проектов. Для расширения кругозора или, внезапно, для подготовки к интервью по System Design.

Общее впечатление

⭐ Книга понравилась. Легко читается, дает фундаментальное понимание систем. Некоторые разделы давались тяжело – но если столкнусь с подобным в работе, вернусь к этим главам

⬇А вы проходили интервью по System Design? Оставляйте комментарии о своем опыте, а я в будущих постах я расскажу о своем

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

🟡 Цвет настроения желтый: как я проходил собеседование в Т-Банк

Эйчары Т-Банка писали мне чаще, чем отец – даже с закрытым резюме🗽. Решил залететь на Weekend Offer: все этапы за один день -> в итоге оффер или отказ

📌 Мой бэкграунд на тот момент:
– Middle SA с 2 годами опыта
– Знания далеко не блестящие – не знал про архитектуру, паттерны проектирования, GraphQL, и прочие фетиши СА

😑Подготовка к собесу

Ее не было, но у них крутой лендинг по подготовке: есть не только банальные советы по-типу наденьте рубашку перед созвоном, но и список литературы и статей, а также подробности по каждой секции. Это реально круто

🤸Что было на собесе

Тут аж три этапа: общение с HR, теория и практика

Для кого-то это круги ада, но по мне классическая модель, в которой нет ничего отталкивающего

1⃣ Звонок с HR обычный – знакомство, технический скрининг. HR довольно вежливая, тактичная, взаимодействие понравилось

2⃣ Второй этап проходил один на один с техническим специалистом, который довольно плотно спрашивает по теории с щепоткой практики. Блоки классические – Требования, Интеграции, Базы данных, Архитектура

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

Единственное, на чем я запнулся – это практика по SQL-запросам🔥. Спрашивают везде, а по факту ни на одной работе я не писал даже банального SELECT *

3⃣На третий этап пропустят, если прошел второй, а фидбек я получил уже спустя 15 минут. Вероятно, собеседующими я был оценен как Senior, поэтому на третьем этапе меня ждал босс в виде System Design🤯 с уже другим специалистом

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

Я не был готов к этому, поэтому блуждал по системе как ежик в тумане, а результат получился поверхностным😓

На этом Weekend Offer был закончен

4⃣ Итог

Я был уверен, что завалил второй этап, но HR вернулась с положительным фидбеком

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

Несмотря на это, я отклонил оффер, так как не планировал уходить со своей компании. Однако собес в Т-Банк мне понравился✔

🛑 Но это еще не все...

Интересно, что спустя время моя супруга проходила собес туда же, но уже не в рамках Weekend Offer. И ее опыт был полной противоположностью моему: HR взаимодействовал довольно вяло, на самом собесе половина вопросов с системного анализа (а она тестировщица), а с обратной связью так и не пришли, прикрывшись «мы еще ищем тебе проект» ❌

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

📌 Выводы и советы
✔️ Weekend Offer – эффективно, но хаотично.
✔️ Готовьте SQL и System Design – спрашивают даже у Middle.
✔️ Не повезет с HR и собеседующим – будет испорчен весь опыт.

——————

А есть ли у вас опыт прохождения собесов в Т-Банк? Делитесь им в комментариях, будет интересно почитать

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

Так ли плох аутстафф? 🤔

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

📌 Но для начала – что такое аутстафф?

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

Это как работать на дядю в квадрате – компания-аутстафф нанимает специалиста в свой штат, а другая фирма «арендует» его себе на время. Forbes говорит, что 70% компаний из РБК-500 используют аутстафф (в основном банки)

👿 6 причин моей ненависти

Впервые с аутстафф я столкнулся в 2023 году, едва окончив курс по системному анализу. Находился в поиске работы, так как с предыдущего ада нужно было срочно бежать (💡это достойно отдельного поста), поэтому согласился, не глядя и не зная, что это. И зря. Вот 6 причин почему:

1️⃣ В компании не было корпоративной культуры, от слова совсем. Тогда я нуждался в сообществе, обмене опытом, сильном наставнике. Коммуникация была через сообщения в Telegram. Никаких созвонов, поддержки. Меня определили на проект, и связь на этом с аутстафф-компанией почти прервалась. Смысл тогда работать на посредника?

2️⃣ Отчетность на две стороны. Каждую неделю приходилось сводить отчеты для двух компаний – это выматывало

3️⃣ Чувствуешь себя чужим в команде. У них свои тусовки, посиделки на кухне, дни рождения, корпоративы. Тебе хочется быть с этими ребятами, но из-за опасения, что завтра проект будет другой, не получается

4️⃣ Отсутствие бенефитов. Твоя команда получит премию, а ты нет

5️⃣ Непрозрачная система развития. Ни грейдов, ни системы оценки, ни вилок по зарплате. Ни-че-го

6️⃣ Неудобная система выплат. Зарплата приходила раз в месяц, и это крайне неудобно, когда у тебя съемная квартира и семья. Но это скорее исключение из правил

Чувствуя, что компания мне не помогает, я уволился через несколько месяцев 💥

📈 Что изменилось во второй компании?

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

Опасения, что предыдущий опыт повторится, не оправдались, но некоторые минусы все же остались. Что изменилось?

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

➕ Понятная система развития – при приеме твой грейд оценивают, и далее ты повышаешь его после ежегодного пересмотра. Все прозрачно.

➕ Появилось чувство собственного достоинства. Тебя ценят как специалиста, ты получаешь волну мотивации для саморазвития. Тебе не страшно подсветить проблемы на проекте, обсудить все честно с руководителем.

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

⚠️ Некоторые минусы аутстаффа остались. По-прежнему приходится отчитываться на две стороны, ты с неохотой вливаешься в чужой коллектив. Смотришь на ребят, которые радуются пришедшей премии, и думаешь: «Рад за вас, но не от всего сердца». Но с этим уже можно жить

Идти или не идти в аутстафф?

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

Еще аутстафф подойдет начинающим специалистам, так как можно поработать на 2-3 проектах за год и довольно быстро набрать опыт

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

Я поругался с разработчиком и его уволили 😲

Расскажу про свой первый (и пока что единственный) конфликт в IT: что случилось, какие последствия и какие уроки вынес

📌Предыстория

Осенью 2023 я работал в небольшой команде на проекте со сжатыми сроками в несколько месяцев. На счету был каждый день: я прорабатывал ТЗ для фронта и бэка, а разработчики буквально дышали в затылок 👨‍💻

Среди бэкенд-разрабов было два человека. Второй, назовем его N, подключился к проекту позже, так как функциональность у него была небольшая. N еще до ссоры вызывал вопросы: работал по 10 часов в день без результата, не спешил разобраться в контексте проекта и почему-то не мог неделю получить доступ к внутренней Confluence❓. Чем ты занимаешься тогда?

👊 Что случилось?

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

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

Дальше было веселее: оказалось, что разработчик вопросы все же имел, но оставлял их не в личке, а в... тикетах на доске задач. Никак не уведомляя о них. Мини-чат в тикетах, как вам такое? Ожидаемо, что я даже не знал об этих комментариях🤨

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

😵 Последствия

Позже выяснилось, что для N это далеко не первый конфликт. В ходе разбора полетов в репозитории обнаружился говнокод, а доступ к Confluence был с самого начала. Он не просто работал 10 часов без результата, а мастерски имитировал бурную деятельность😱

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

👨‍🏫 Ошибки и уроки

1⃣ Дал волю эмоциям на публичном созвоне, дошло до перехода на личности. Это неконструктивное поведение: в любом конфликте важно сохранять трезвую голову и привлекать третью сторону – это и есть решение. Позже я изучил тему конструктивной конфронтации, где был описан не только этот кейс, но и множество других. Рекомендую тоже почитать об этом на досуге

Если бы я или N написали в общий чат "Эй, давай согласуем контракты", конфликта бы не было

2⃣ Спешка. Отдавать куски доки тоже было некорректно. Стал относиться к своим артефактам более ответственно

3⃣ Третья ошибка более личная и связана с мягкостью. Я хоть и видел некоторые странности поведения, но в силу своей «доброты» даже местами защищал N, подсвечивая свои ошибки

➡Итог

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

——————
⬇ А были ли у вас конфликты на работе? Как решали? Делитесь в комментах

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

Как я сходил на собес в Магнит Tech

Третьи майские в самом разгаре, и в перерыве между сном и шашлыками решил рассказать про собес в Магнит Tech 🧲, где было все не так гладко, как в Т-Банке

📌 Я на тот момент:
– Ранний middle с 1 годом опыта
– Оценивал свои знания как хорошие для текущего опыта

Согласно вакансии им требовался middle с классическими функциями, такими как интеграции, БД, UML, BPMN и так далее. Выглядело вкусно. Да и компания у всех на слуху, даже в нашем доме есть Магнит – почему бы и нет? Может, получу скидки на продукты. В общем, нацелился туда.

👨‍💻 Тестовое: день впустую

Но прежде, чем покупать дошик со скидкой, мне нужно было выполнить тестовое и пройти сам собес. Объемное тестовое состояло из трех задач:

1. Есть некая компания, нужно описать процессы AS IS и TO BE, сформулировать проблемы
2. Нарисовать ER-диаграмму для банка
3. Определить связи между 4 таблицами и написать SQL-запросы

Итог: 8 страниц текста, куча схем, один день жизни. Тогда я не заметил подвоха, но сейчас по тестовому его вижу😏. Догадаетесь, какой? Спойлер: почти все задания по бизнес-анализу

⚡️ Собеседование

Этап всего один. Я ожидал, что это будет техническое интервью один на один, но буквально за 8 минут до начала HR предупредила, что там будут «еще ребята из команды» ❓. Этими ребятами оказались дяди и тети 40+: было ощущение, что я зашел не в ту дверь

Начался собес с вопросов по бизнес-анализу по типу «Как будете готовить доклад по своему решению», «Боитесь ли выступать на публику». Ладно, это начало, думал я. Но вопросы не заканчивались. Позже я понял, что попал в классическую ловушку Джокера из мира IT для СА – собес по бизнес-анализу

Я так и не дождался ни интересных мне вопросов, ни обсуждения тестового. Вместо этого – ненавистные логические задачки по типу «Человек спускается с 16 этажа, а поднимается только на 12. Почему?». Всегда теряюсь на таких, поэтому мой ответ: «Человек ходит в любовнице на 12 этаже»😁

Атмосфера тоже была не из приятных. Ощущалось напряжение, эти 4 пар глаз словно выжигали меня сквозь экран. Когда все это закончилось, я понял, что сюда не пойду❌

✏️ Итог

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

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

Тогда я и начал судить компанию по собеседованию. Если собес - фигня и не соответствует вакансии, то это red flag 🚩

⬇️ А вы попадали на собес на бизнес-аналитика, хотя шли на системного? Уверен, это нередкий кейс. Пишите в комменты, если тоже было

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

Реплицирование vs Партиционирование vs Шардирование

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

➡ Реплицирование

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

В терминах БД это репликация – процесс создания копий (реплик) базы данных и поддержка их актуальности на разных серверах

Не путать с бэкапами! Бэкап означает создание копий до определенного момента и хранение их для аварийного восстановления, но без поддержки в актуальном состоянии

Цель: повышение отказоустойчивости и доступности. Если потеряем одну БД, то будем уверены, что где-то есть актуальная копия🎉

➡ Партиционирование

Снова пример из жизни: у нас дома есть большой шкаф👕, вплотную забитый носками. Представим, их там 1200. Чтобы освободить место, мы разгребаем вещи и складываем 300 носков в комод, 300 в тумбочку, 300 куда-нибудь еще, а 300 оставляем в шкафу

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

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

📌 Пример: у нас есть табличка Users, в которой 1 млн пользователей. Если использовать один из методов партиционирования, то таблица Users разделится на две, в одной будут юзеры с id от 1 до 500 тыс, во второй от 500 тыс до 1 млн

➡ Шардирование

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

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

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

➡ Когда что использовать?

– Реплицирование — если нужны отказоустойчивость и читаемая масштабируемость. Данные на разных серверах
– Партиционирование — если таблица очень большая, но сервер один. Данные хранятся на одном сервере, но в разных разделах/партициях
– Шардирование — если данных слишком много для одного сервера. Данные лежат на разных серверах

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

—————

Этот пост не раскрывает особенности каждого из методов: в следующих расскажу о каждом отдельно

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

2 навыка, которые помогли мне стать middle SA за 9 месяцев

Рассказываю, как мой неочевидный жизненный опыт помог быстро освоиться в профессии СА 📣

⌨️ Копирайтинг

С детства я мечтал зарабатывать деньги. Я из небольшого городка на юге Якутии❄, поэтому возможностей подработки для подростка почти не было. Но у меня был интернет👨‍💻

Я перепробовал многие способы заработка – тыкал по рекламе, писал отзывы, комментарии. За месяц написания отзывов я получил всего 500 рублей. Звучит как пустая трата времени, но я понял, что в интернете можно зарабатывать🤑

А затем наткнулся на копирайтинг, на чем и остановился лет на 9-10. Копирайтинг научил меня писать без воды, без повторов, канцеляризмов и мусора. Я безупречно писал сочинения в школе, мне легко дался диплом в универе, а в работе СА с энтузиазмом подхожу к документации любого объема и формата

👩‍💻 Базовые навыки программирования

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

Начиная с 3 курса нас преследовало программирование, причем каждые полгода почему-то менялся язык 👨‍💻. Мой максимум до этого этапа – это школьный курс по Паскалю и проект с черепашкой. Мне было тяжело, но накостылять говнокод все же смог. На магистратуре я уже целенаправленно выбрал C++, выпускной проект был полностью на этом языке

Может показаться, что я тру прогер, но нет – в C++ я дошел максимум до ООП включительно, а указатели и списки так и не понял. Код выпускного проекта тоже лучше никому не показывать😁. Зато в профессии СА мне пригодились знания базовых алгоритмов и структур данных: знал все эти ваши стринги и варчары, умею читать код

❓ Технарь или гуманитарий?

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

💡 Но как только я узнал, что СА это грань между технарем и гуманитарием, я понял, что это мое. И о своем прошлом опыте я не жалею: неотточенные навыки заиграли новыми красками на работе в IT. И благодаря им я довольно быстро стал middle

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

—————

⬇ А какие неочевидные навыки пригодились вам в IT? Пишите в комментариях

P.s. на фото я пытаюсь работать инженером-электроником, продержался две недели 😁

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