Работа с метриками приложения: измеряем, анализируем, улучшаем производительноть приложения

Появилась запись моего доклада с конференции Merge 2025 в Иннополисе, где я поделился опытом внедрения метрик производительности в мобильное приложение Звук. В прошлом году мы уделили много времени именно качеству работы приложения и его производительности. В докладе рассказал, какие инструменты рассматривали для анализа, как в итоге разработали собственный Performance-tracer, и какие метрики получилось улучшить. Тут опишу основные тезисы:

📌Зачем собирать метрики производительности?
Стабильность – ловим баги до пользователей.
UX – ускоряем старт и рендеринг.
Ресурсы – экономим трафик и батарею.
Бизнес – рост конверсии и удержания.
Техдолг - проще анализировать и планировать работу

🛠 Из каких инструментов выбирали:
Firebase Crashlytics: Простота, детальные отчеты о сбоях
Firebase Performance: Удобные дашборды, автоматически собирается статистика о работе приложения. Но немного замедляет старт приложения и нет гибкой настройки.
Sentry: Мониторинг ошибок + перфоманс, из минусов дорого, сложная настройка self-hosted решения
OpenTelemetry: Гибкость, open-source. Но изначально это решение для backend-разработки, не нашел ни одного примера кто использовал бы в мобильных приложениях и нет документации для Android.
В итоге, мы как настоящие разработчики решили сделать свое кастомное решение на базе Redash + кастомные трейсы

📌 Какие метрики собирали?
Холодный/горячий старт
Отрисовка экранов
Скорость сетевых запросов
Парсинг JSON, инициализация DI
Бизнес-логика и воспроизведение контента

🚀 В итоге, используя все доступные инструменты для оптимизаций мы добились
Холодный старт: -20%
DI-инициализация: -15%
Inflate-методы: стали в 2-20 раз быстрее

Выводы:
1. Собирайте метрики до того как заметили проблемы в проде
2. Начинайте с бесплатных инструментов (Firebase, Profiler).
3. Дашборды – мощный аргумент для построения roadmap и инструмент тимлида для планирования работы с техдолгом.

​​🏕️ Выступил на ИТ-кэмпе Summer Merge 2025.
На прошлых выходных получилось совместить казалось бы абсолютно разные вещи: ИТ и отдых на природе. 2 насыщенных дня на берегу Волги на конференции Summer Merge пролетели незаметно. Утром: йога и сапсефринг, днем ИТ-доклады и полезный нетворкинг, а вечером кавер-группы и эндуро-покатушки на мотоциклах.

Мероприятие позиционировалось как антиконференция: палаточный городок, пляжный волейбол и вечерние дискотеки вперемешку с ИТ-докладами. Поэтому и требования к докладам соотвествующие: не сильно сложно, но в то же время интересно и практично. Я рассказал о том, как мобильному разработчику развивать свои Pet-проекты, почему это важно, а также поделился собственным опытом релиза нескольких своих мобильных приложений, как искал первых пользователей и внедрял монетизацию. Если интересно - накидайте огоньков, попробую как-нибудь рассказать здесь об этом.

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

​​Список литературы на лето для Android-разработчика

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

Карьера Software Engineering Manager. Эффективное управление командой разработчиков. Лидом я работаю уже давно, часть описанных идей для меня не были новыми, однако всегда полезно структурировать то, что уже есть и подметить известные решения с новой стороны. Очень понравилось, что повествование книги выстроено как в симуляторе. В каждой главе рассматривается какой-то отдельный аспект менеджера команды, описывается типичная ситуация и ты уже представляешь себя в этой ситуации и начинаешь думать как поступил бы. Считаю что обучение на каких-то типовых ситуациях приближенных к реальной жизни самое эффективное. Можно смело брать и читать. Будет полезно тем, кто хочет вырасти из senior в лида.

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

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

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

Наглядные примеры работы Kotlin Flow операторов

Кто работал с RxJava, возможно, помнит интерактивные Marble-диаграммы, для более наглядного понимания работы операторов.
Было бы круто что-то похожее увидеть и для Kotlin Flow для наглядности работы.

Нашел классную статью с крутыми анимациями с пиксельной графикой, которые автор создал для объяснения работы популярных операторов в Kotlin Flow. Ощущается, как будто играешь в какую-то игру на Nintendo.

​​LRU-кэш: Как сделать историю поиска за 3 строки кода (и пройти собеседование)

Мы в Звуке уже давно используем System Design для проверки знаний и умений кандидата. И часто, задача состоит в том, чтобы спроектировать 1-2 экрана похожих на те, что реализованы в приложении. Обычно это поиск + лента. И тут можно до бесконечности обсуждать способы реализации: пагинации списков, эффективного поиска, офлайн-кэширования и так далее. В этом и сложность этого этапа.

Так вот, один из таких вопросов это: "Как реализовать историю поиска и показывать пользователю последние запросы, а старые удалять?" Очень часто, кандидаты предлагают решение на базе HashMap. Предлагают хранить кол-во запросов/дату запроса и потом сортировать их от наиболее свежего до старого. Такой подход будет работать, но можно предложить более эффективное решение. Называется такой подход LRU-кэш.

LRU (Least Recently Used) — это алгоритм кэширования, который автоматически удаляет редко используемые данные, чтобы освободить место для новых.

Какие плюсы от LRU-кэша в данной задаче:

1. Автоматически удаляет старые элементы
Если пользователь искал много запросов, LRU удалит самые старые, оставив только последние (или N самых свежих).
Например, можно ограничить кэш 10 последними запросами.

2. Быстрый доступ к недавним элементам
LRU хранит элементы в порядке их использования, поэтому получить список недавних запросов можно за O(1).

3. Простота реализации
Во многих языках есть готовые реализации (например, LinkedHashMap в Java,

LinkedHashMap часто используется для реализации LRU-кэша, потому что эта структура данных сочетает в себе преимущества хеш-таблицы и связанного списка. Например с помощью accessOrder = true при любом обращении (вставка/чтение) элемент перемещается в конец. А метод removeEldestEntry() позволяет автоматически удалять самый старый элемент при превышении размера.

Вот так знание патерна LRU позволит вам не изобретать велосипед, а просто и эффективно решить такого рода задачу. Такие задачи - частый вопрос на собеседованиях (например, в Яндексе, Тинькофф, VK). И на практике, в android - проектах такие задачи постоянно встречаются. Например, библиотека Glide для кэширования ресурсов также использует LRU. Эти и другие эффективные подходы мы разбираем на курсе по System Design

Как получить +30% к зарплате?
Анонс курса по подготовке к Mobile System Design.

Друзья, 5 августа стартует интенсивный тренинг по подготовке к мобильному System Design. Таким образом, к осени, когда компании начинают сезон найма вы будете уже готовы! Почему стоит пройти этот курс:

1️⃣ Максимально приближенные к реальным кейсы из BigTech. Разберем типовые кейсы, которые спрашивают в Avito, Yandex и т.д. А на Mock-собеседовании потренируемся.

2️⃣ Хватит рассказывать про Load Balancer и рисовать общие диаграммы с репозиториями! На курсе мы разберем ошибки, из-за которых вы не получаете хороший оффер.

3️⃣ Это хороший способ систематизировать уже имеющиеся знания, и начать расти в сторону архитектора. Мы разберем различные инструменты кэширования, backoff policy, обсудим плюсы/минусы разных форматов передачи данных - в общем те темы, которые часто нужны на более высоком грейде.

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

Отзыв с Mock-собеседования по System Design.

Главная цель — не просто обучить участников навыкам, но и помочь им достичь поставленных целей. Это может быть систематизация знаний или получение оффера в крупную компанию. Именно второй цели достигла Юля. После Mock-интервью, собеседование по System Design в Яндекс она прошла без проблем, и уже работает в команде инфры.

Проходила мок-сосбес по System design. Понравилась атмосфера проведения, в процессе выписала для себя 3 страницы того, что нужно улучшить перед реальным собеседованием. После интервью получила развернутый фидбек. Что было хорошо, что нужно подтянуть. Причем фидбек был не абстрактный, а детализированный. Какие подходы/фреймворки стоит покопать, что стоит упоминать, и чего делать не надо. В общем, получила план развития, который, я уверена, приведет меня к моей цели!

А я напоминаю, что сегодня, последний день до повышения цены! Посмотреть отзывы и программу можно тут

​​Как спроектировать новостную ленту. Mobile System Design

Написал на хабре первую часть статьи-разбора как спроектировать мобильное приложение по типу новостной ленты. В первой части затронул такие важные этапы как сбор требований и проектирование коммуникации с Backend и проектирование API. Так мне в комментариях написали, что это не относится к мобильной разработке, ну что ж. Идея заключается в том, что чем сложнее и больше у вас проект, тем больше разработчик должен разбираться в смежных системах и инструментах.

Например мы в платформе когда делали свой инструмент для сбора performance-метрик задействовали Python для визуализации трейсов, Redash для бэкенда и еще сами писали SQL-запросы для Data-аналитиков. Так и на собеседовании по System Design, вас вряд ли спросят как сверстать кнопку. У меня как-то был кейс когда пришлось рассказывать про Message Queue на бэке и выбирать между Kafka и RabbitMQ.

А еще во многих компаниях (у нас в том числе) проходят так называемые защиты архитектуры той или иной фичи. И мобильные разработчики вправе выбрать и спроектировать такой API который будет удобен именно им и часто общаются с Backend-командой. Так что это тоже очень важный скил.

Закончился курс по System Design Interview

В августе я анонсировал курс по подготовке к System Design, и совсем недавно он завершился.

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

Я всегда собираю обратную связь в конце, и оценка NPS курса составила 9.33 (из 10) 🔥

Вот что говорили участники, когда пришли на курс:

Чувствую, что мне не хватает знаний по архитектуре, чтобы в современном подходе написать приложение с нуля.Планирую собеседоваться в крупные компании, где могут быть этапы по System Design, ранее только отдельные вопросы или небольшие блоки его касающиеся были на собеседованиях и я "плыла", в том, что сама не делала.

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

Хотел бы структурировать знания по архитектуре мобильных приложений и приобрести навыки по прохождению system design собесов.

Судя по опросу, все цели курса были достигнуты.
Теперь ребята уверенно себя чувствуют в контексте System Design и смело выходят на непростой рынок ИТ.

✅ Могут спроектировать архитектуру сервиса,
✅ Подсветить edge-кейсы и выбрать наиболее подходящий стек,
✅ И самое главное — уложить это всё в 50 минут, которые обычно отводятся на system design собеседования.

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

Не успеваю написать пост, батарея садится или про анализ энергопотребления Android-приложений.

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

Анатомия энергопотребления
Анализ энергопотребления

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

🚗 Внедрили Звук в 2GIS - самый сложный проект этого года. Теперь вы можете слушать любимую музыку сразу в приложении 2GIS в режиме навигации. Вот где навыки System Design пригодились и прокачались. С точки зрения архитектуры и взаимодействия было очень интересно и нетривиально, необходимо было выделить в отдельный SDK логику для проигрывания, а также разделить дизайн-систему с минимум зависимостей так как у таких проектов обычно очень жесткие требования на размер и кол-во зависимостей. Кстати именно этот проект получил награду Релиз года от CEO.

⌚Разработали приложение для Huawei Watch GT 6 и 6 Pro - можно слушать музыку теперь и во время пробежек.

🚅 Множество рефакторингов и оптимизаций. Внедрили Baseline Profiles, а также распилили Shared Preferences на множество независимых DataSource-ов, в сумме ускорили старт приложения до 40%!

🦾 Одни из первых в команде внедрили AI-based code review в пайплайны (ну куда ж без AI), сократив время код-ревью, а также множество проверок для качества приложения: чекаем размер apk, делаем замеры энергопотребления.

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

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

А вы подводите итоги работы в своей компании?

​​Сейчас в соц. сетях модно вспоминать 2016 год и делиться фотографиями тех лет. Как раз примерно в те года я получил оффер и присоединился к работе над проектом Lazada и работал в штаб-квартире Alibaba в Китае.

Lazada - это крупнейший маркетплейс. Те из подписчиков, кто путешествовал по Юго-Восточной Азии, например, Тайланд или Бали, думаю точно слышали про этот проект. Я работал в команде Search, наша команда отвечала за все, что связано с поиском товаров, фильтрами, категориями и так далее. Особенно "весело" было во времена распродаж, например 11.11, приходилось очень много выполнять оптимизаций и кэширования чтобы поддерживать работу в пиковые нагрузки, а еще помню ночные дежурства всей команды.

Посетив штаб-квартиру Alibaba в Ханчжоу 🇨🇳 был удивлен некоторой аскетичностью офиса, по сравнению со многими ИТ-компаниями РФ. Даже в нынешние времена массажные кресла, собственный бариста и спортзал в офисе считается чуть ли не обязательными атрибутами любой крупной ИТ-компании. В Alibaba же было все просто и без излишеств, но при этом все необходимое для комфортной работы. Зато был мощнейший инженерный фокус: минимум лишнего, максимум результата.

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

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

Я начал смотреть на приложения не как на набор экранов, а как на распределённые системы: с узкими местами, SLA, деградациями и компромиссами. Именно это потом больше всего помогало мне на сложных собеседованиях и в проектировании архитектуры. Так что я всем рекомендую пробовать разные проекты, чтобы повышать ту самую насмотренность и выявлять лучшие практики. Сейчас я часто вижу, как Android-разработчики годами не могут пробиться в крупные компании именно из-за system design и архитектуры. Во многом — потому что у них не было опыта вроде этого.

Ставьте реакции, если интересно, в следующих постах покажу фото офиса Alibaba и расскажу о процессе собеседования.

​​Офис Alibaba и собеседование в Lazada

По реакциям на прошлый пост (спасибо всем, кто отметился 🙌) вижу, что тема собеседований и опыта работы в Китае действительно откликается, поэтому продолжаем.

Я проходил собеседование именно в Lazada, которая входит в экосистему Alibaba. Возможно, процесс в самой Alibaba немного отличается, но по уровню требований вряд ли кардинально. У меня было 3 этапа собеседования:

1️⃣ Проверка знания Android SDK
Классический этап: жизненный цикл, работа с UI, многопоточность, базовые вещи. Здесь, как правило, проблем ни у кого не возникает.

2️⃣ System Design. И вот тут начинается самое интересное.
System Design был максимально приближен к реальному продукту. Учитывая, что Lazada — крупнейший e-commerce в Юго-Восточной Азии с сотнями миллионов пользователей, задача была не "нарисовать экран", а спроектировать устойчивую систему поиска.

Нужно было:
1) Спроектировать экран поиска с подсказками и категориями
2) Продумать кэширование запросов и локальную историю поиска
3) Предусмотреть debounce и обработку ошибок сети

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

1) Зачем нужен API Rate Limiter
2) Как работает балансировщик нагрузки
3) Что будет при всплеске трафика

И вот тут на собеседованиях валятся даже сильные кандидаты.

3️⃣ Алгоритмы. Вишенкой на торте были 2 задачи уровня Leetcode easy / medium. В те годы я, если честно, даже не знал, что такое Leetcode. Зато у меня была книга Роберта Лафоре «Структуры данных и алгоритмы в Java», которую я активно перечитывал за неделю до собеседования. Всем рекомендую кстати.
Одну из задач помню до сих пор — проверка корректности строки со скобками, классическая задача на стек.

Все эти этапы были не зря: спустя пару дней я получил офер. А уже потом узнал, что команда мобильной разработки летит работать в штаб-квартиру Alibaba в Ханчжоу 🇨🇳

Главный вывод, который я тогда сделал: большие компании ищут не Android-разработчиков, а инженеров, которые понимают, как работает вся система целиком. Компании ищут не верстальщиков интерфейсов, а именно инженеров способных выйти из своей зоны ответственности и при необходимости участвовать в проектировании API или процессе сбора продуктовой аналитики.

Именно поэтому сегодня я так много внимания уделяю system design и архитектуре в работе с Android-разработчиками — это самый частый пробел на собеседованиях в крупные компании.

В следующем посте покажу офис штабы-квартиры и расскажу почему я все таки не остался работать в Китае. P.S. На фото с коллегами в кампусе Alibaba.

​​Офис Alibaba и график работы 9-9-6.
Спустя пару дней после финального этапа мне прислали офер!

Честно — в тот момент я уже был морально готов к отказу. System Design был непростой, вопросы копали глубже, чем я ожидал. Но именно это, как оказалось, и сыграло в плюс — интервьюеры видели не заученные ответы, а ход мыслей.

А дальше началось самое интересное.
Через некоторое время я узнаю, что мобильная команда летит работать в штаб-квартиру Alibaba в Ханчжоу. Для меня это был первый настолько масштабный международный опыт. Когда я впервые приехал в кампус Alibaba в Ханчжоу 🇨🇳, ожидал увидеть что-то в духе «кремниевой долины» — футуристичный кампус, глянцевые офисы, сплошные лаунж-зоны.

Реальность оказалась другой.
Офис был довольно аскетичным. Никакого избыточного пафоса. Всё очень функционально и по-деловому. Минимум отвлекающих факторов — максимум фокуса на продукте.
Все работают в openspace, есть отдельные переговорки и маркерные доски рядом со столами для обсуждений. Не скажу, что было просторно, но, по крайней мере у разработчиков, довольно тихо и спокойно, в отличие от тех. поддержки.

Что меня больше всего впечатлило, после обеда китайцы любят вздремнуть, у многих есть подушки, маски, видел даже отдельно стоящие раскладушки. Но это и не удивительно. Начинают работать обычно все с 9 утра, и задерживаются до 9. Там, я впервые узнал про 996 - график работы, популярный в китайских технологических компаниях, это не миф, многие действительно так работают. У нас как раз был такой негласный график работы, потому что проект был срочный, необходимо было реализовать огромную часть функционала и перевести на новый стек технологий.

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

Ну и пару слов про еду. Думаю, кто хоть раз бывал в Азии, согласится, что азиатская еда на любителя. Все очень острое и жирное. Европейская еда есть - но она в 2-3 раза дороже. Столовые в кампусе довольно простые, но и еда на наши деньги стоила рублей 100-200 максимум. Больше всего мне нравились фреши из фруктов за 60 рублей. Кроме столовой на территории кампуса есть и кафе по типу Starbucks или Costa Coffe, но там кроме десертов и кофе больше ничего не было, поэтому все равно приходилось привыкать к традиционной китайской еде.

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

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

ИТ-Рынок в Европе be like. Вот вам и валютные удаленки 😁

Менти получил офер в Revolut на €95 000.

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

Мы быстро определили план подготовки. Основной фокус сделали на двух вещах:

— System Design и архитектура высоконагруженных систем
— безопасность мобильных приложений (HTTPS, SSL pinning, MITM)

Провели несколько Mock System Design интервью. Я подготовил кейс с учетом специфики финтех-приложений: как проектировать систему, где учитывать безопасность, какие узкие места появляются при росте нагрузки.
На интервью такие вещи часто решают исход — кандидата смотрят не только на код, но и на то, как он думает об архитектуре системы.

В процессе разбирали:
— как структурировать System Design интервью
— какие trade-offs обсуждать
— где обычно кандидаты допускают ошибки

Через несколько недель менти написал:
«Получил офер. Спасибо за подготовку».

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

Оффер — €95 000 и релокация в Европу.
По моим ощущениям, рынок сейчас постепенно оживает. Компании снова активнее нанимают, но System Design интервью по-прежнему остаются одним из самых сложных этапов.
Если готовитесь к интервью в продуктовые компании — могу помочь разобрать ваш кейс и помочь подготовиться.

Как не упустить выгодный оффер в 2026 году? Многие разработчики отлично пишут код, но сыпятся, когда на собеседовании просят спроектировать архитектуру приложения и теряют офферы уровня Middle+ и Senior в BigTech.

Я запустил первый в Рунете курс по Mobile System Design, который полностью посвящён подготовке к System Design именно для мобильных разработчиков.

В прошлом году я провёл несколько интенсивов, собрал реальные кейсы с собеседований и доработал материал. Теперь курс доступен в записи на Stepik - можно проходить в удобном темпе.

Внутри:

• 4 часа концентрированного контента - как структурно отвечать на System Design вопросы
• практические кейсы из реальных собеседований
• около 80 тестов для закрепления материала

В курсе разбираются реальные вопросы из мобильного System Design интервью:

• как спроектировать offline-first архитектуру
• как работает синхронизация данных
• чем отличается offset пагинация от cursor-based
• как решать конфликты данных

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

Если ты планируешь менять работу или идти на повышение в ближайшие месяцы - сейчас лучшее время подготовиться https://stepik.org/a/262641

Mobile System Design за 5 минут

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

Именно на этой секции валятся ребята, которые по хардам отвечают на 9 из 10. Человек знает, как устроены корутины, работает GC, а потом начинается System Design и все.

Поэтому я собрал краткую шпаргалку, если собес поставили уже на завтра:

1) Сбор требований (10-15 мин)
Самая частая ошибка. Человек понял по-своему задачу и сразу начал рисовать диаграмму.

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

Функциональные требования отвечают на вопрос: «что пользователь может сделать?» - выбери ТОП-3, не больше. Длинный список - минус, не плюс. Интервьюер оценивает умение приоритизировать

Нефункциональные: доступность, масштаб, локализация

2) Проектирование API и модели данных (10-15 мин)
Проектируем ленту постов? User, Post, UserReaction. Тут же можно продумать какой типа пагинации будет использоваться (да их несколько). Не забываем про идемпотентность

GET /v1/posts/:id -> Post
GET /v1/feed -> Post[]

3) Высокоуровневая архитектура (10-15 мин)
Вот тут основная работа. Архитектура клиента (Clean, MVI, MVVM, repository) API, рисуем сервисы, БД, показываем offline-first - подход, CDN, Message Queue, LRU-кэш

4) Углубление в реализацию (10 мин)
А вот тут ты показываешь глубину:

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


📹 Видеокурс для закрепления с примерами и упражнениями

Если ты планируешь менять работу или идти на повышение в ближайшие месяцы - сейчас лучшее время подготовиться.
P.s. Используйте только эту ссылку, иначе Stepik берет конскую (почти половину) комиссию
https://stepik.org/a/262641

10 апреля уже в 3-ий раз выступлю на конференции Стачка в Ульяновске. Буду рассказывать как раз про System Design для мобильных разработчиков в формате воркшопа, тема оказалась довольно интересной и сразу несколько конференций одобрили мою заявку, пришлось выбирать.

В докладе разберём:

— как именно мобильному разработчику подходить к System Design
— на какие аспекты обращают внимание интервьюеры
— типичные ошибки, которые могут стоить оффера
— реальный кейс из Big Tech (разберём вместе)

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

Если кто-то будет на конференции буду рад увидеться и пообщаться после выступления 🙌
https://ul.nastachku.ru/lp/ul26/speeches/osobennosti-prokhozhdeniya-system-design-interview-dlya-mobilnogo-razrabotchika-1