​​🏕️ Выступил на ИТ-кэмпе 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, но там кроме десертов и кофе больше ничего не было, поэтому все равно приходилось привыкать к традиционной китайской еде.

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

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