Как получить +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

​На прошедших выходных в Ульяновске прошла юбилейная 15-я «Стачка». Для меня это уже 3-й раз когда я выступаю в роли спикера и в этом году на конференции увидел три ключевых тренда: усиление роли ИИ, рост интереса к System Design и размывание границ между ролями разработчиков. Интересный факт - в программе было заявлено сразу 2 доклада про System Design, один мой, а второй про проектирование систем для аналитиков. Это еще раз подтверждает интерес к этой теме среди аудитории.

📌Поделюсь самыми интересными идеями и докладами, которые удалось посетить после выступления:

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

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

Путь инди-хакера или как заработать на своем пет проекте.

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

Работа мобильного приложения с экзоскелетом.

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

Что изменилось: ключевые тренды. Который год замечаю, что докладов про мобильную разработку стало меньше. Очень много было про ИИ, а мобильная разработка уже давно сформировалась. Под любую задачу есть решение, читай документацию и делай. Поэтому все больше разработчиков комбинируют подходы начиная от BDUI и заканчивая AI агентами и автоматизациями.Быть просто Android-разработчиком уже недостаточно. Нужно иметь продуктовое мышление и уметь проектировать системы целиком, чтобы поручить ИИ реализацию рутины.

🙌 Стачка остаётся одной из самых «ламповых» конференций. Это сложно формализовать, но разница со столичными событиями ощущается сразу: здесь больше живого общения, открытости и желания делиться опытом. Именно за этим хочется возвращаться.

Запись моего доклада на тему Mobile System Design c конференции Стачки 2026

Организаторы поделились записью моего доклада, а я делюсь с вами.

В докладе на основе своего опыта рассказал:

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

Будет актуально всем разработчикам, ставьте лайки, подписывайтесь на канал
https://www.youtube.com/watch?v=xeNIDQcw_Eg&t=115s

Как работать с изображениями эффективно.

На этой неделе занимались с командой избыточным потреблением памяти bitmap'ами.

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

Что сделали:

• пересмотрели логику выбора размеров изображений при загрузке;
• добавили допуск при подборе размера ресурса, чтобы избежать загрузки более тяжелых вариантов без реального выигрыша в качестве;
• для ряда кейсов начали явно ограничивать размер bitmap'ов в памяти через override;
• изменили fallback-логику: если размер View неизвестен, больше не загружаем максимально крупный вариант изображения;
• оптимизировали декодирование некоторых часто используемых обложек и баннеров.

Результат после полного прохода по основным экранам приложения:

📉 Потребление памяти на отдельных экранах уменьшилось на -34,6%
📉 Размер отдельных bitmap'ов получилось значительно уменьшить: 7 МБ → 0,8 МБ (-89%)

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

Для понимания масштаба проблемы:

Bitmap 1000×1000 в ARGB_8888 ≈ 4 МБ памяти.
Bitmap 600×600 ≈ 1.4 МБ.
Bitmap 300×300 ≈ 0.34 МБ.
Разница между xlarge и small может составлять более 10 раз по памяти на одном изображении.

Во многих проектах Glide/Coil уже используются, но это не гарантирует эффективного потребления памяти. Если приложение активно работает с изображениями, рекомендую периодически проверять:

— какие Bitmap занимают память;
— какого они размера;
— соответствуют ли размеры bitmap реальному размеру View;
— правильно ли работает ваша стратегия image loading.

Полезные материалы по теме:

🔹 Android Developers — Loading Large Bitmaps Efficiently
https://developer.android.com/topic/performance/graphics/load-bitmap

🔹 Android Developers — Managing Bitmap Memory
https://developer.android.com/topic/performance/graphics/manage-memory

🔹 Android Developers — Optimizing Bitmap Images
https://developer.android.com/develop/ui/compose/graphics/images/optimization

7 собеседований и оффер выше рынка в Германии. Что помогло пройти самый сложный этап?

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

Процесс оказался совсем не простым.
Всего было 7 интервью, объединённых в четыре этапа:

• HR Screen
• Hiring Manager
• Technical Interview
• Финальный этап сразу из четырёх интервью:
— Behavioral
— Behavioral
— Mobile System Design
— AI Interview (про это расскажу отдельно)

Именно System Design вызывал у него больше всего вопросов.
Не потому что не хватало Android-знаний. А потому что формат Mobile System Design — это совсем другой уровень. Здесь оценивают не знание API Android, а умение проектировать систему целиком и объяснять архитектурные решения.

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

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

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

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

Параллельно кандидат проходил мой курс по Mobile System Design, чтобы закрыть теорию: как структурировать интервью, обсуждать trade-offs, проектировать API, базы данных, offline-first архитектуру и объяснять свои решения.
Спустя некоторое время получил такое сообщение:

«Мне дали оффер 🙂
Спасибо большое за курс и за мок-собеседование. Думаю, что это повлияло на получение оффера.»

А чуть позже — полноценный отзыв:

Я проходил интервью в одну компанию, и одним из этапов был Mobile System Design интервью. В таком формате собеседований у меня не было большого опыта, поэтому я хотел, чтобы мне кто-нибудь провел мок-собеседование, на котором я бы мог потренироваться перед реальным интервью. Я нашел Михаила на GetMentor и связался с ним. Он написал мне довольно быстро, и мы договорились о встрече на следующей неделе. Также Михаил заранее поделился полезными ссылками на материалы для изучения в качестве подготовки к собеседованию.

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

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

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

Такие истории особенно радуют. Жалко только, что пока я не беру % с зарплаты, как другие менторы 😀. Я убеждён, что хороший mock — это не набор случайных вопросов.
Это возможность заранее оказаться в условиях, максимально близких к тем, что будут ждать кандидата через неделю.

Если вы готовитесь к Senior или Lead интервью, особенно если впереди есть этап Mobile System Design, то рекомендую адаптированный под мобильную разработку авторский курс на Stepik. В связке с мок-собеседованием гарантированный результат 😉